User Stories

Handicap Indicator in Brazil


A common question is how user stories can be developed for legacy code or for problems that crop up in production.  The implication is that creating user stories is too hard when dealing with legacy code changes or too slow when dealing with production problems.  User stories are a core tenet for most agile approaches. User stories are a vehicle to capture nascent needs and wants in a brief container, a card.  Those needs require the parties to interact and converse in order to refine those needs into something so the need can be transformed, a conversation. During the conversation, as the understanding evolves, the team learns how they will prove that they meet the need, confirmation. In our series “Agile, Where Agile Fears to Tread” we established how we can use agile techniques for both legacy (mainframe being used as a proxy for all legacy code bases) and for maintenance.  There are a lot of reasons why some practitioners resist user stories in these two are areas.

For example, determining who the user is for legacy functionality—especially backend functionality—might be difficult. The classic format of a user story is “persona, goal, benefit”.  The persona is the user; the person that will use the functionality. While everyone can and should write user stories, product owners are often solely tasked with the role and those serving legacy systems are often proxy product owners that are not close to the business. This arrangement leads legacy teams to need to lean on more classic requirements documents and use cases with reviews and signoffs to ensure a conversation. Legacy applications often are core to the organization’s mission and are often large. The list of work required to add and enhance new features is long. Long backlogs tend to be hard to groom and prioritize, meaning that the backlog is a place for ideas to die or a place to entice people to jump the queue.

The reasons user stories are difficult for maintenance are both similar and very different than for legacy applications.  The most often quoted reasons why user stories don’t fit into the maintenance flow of work is the belief that framing the problem by identifying who is affected, what they want to be fixed and why they want it fixed takes to long.  I will let that statement just sit there. Maintenance is often different from legacy work, especially correcting defects because the user is often the one that reported the problem. In large organizations, the backlog of maintenance work and small enhancements (often masquerading as bugs) can be long and fall prey to the same grooming and prioritization issue as legacy applications.  Finally, many firms outsource maintenance support and the people doing the work are removed from deep knowledge of the business and therefore have a difficult time framing user stories including acceptance criteria.

A common problem in both scenarios (but thankfully less often every year), is that legacy and maintenance personnel are required to follow structured, gated, waterfall or, worse, ad-hoc processes. Whether the reason is familiarity with these approaches, security or contractual reasons the staged or random approaches are less friendly to using user stories.  

My knee-jerk reaction to why user stories don’t fit is a retort with a barbed tongue.  This is where it is good that my mouth and lizard brain have a filter between them because it would be easy to ask whether the person asking wants to create a requirements document to sign off before getting any feedback or would just rather start to code before considering what the change should do.  Realistically, neither make sense and I am pretty sure that is not the intent of the question. Next, we explore ideas for making user stories fit.


Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 481 will feature our essay on the Life Cycle of A User Story.  A user story – a brief, simple requirement statement from the user’s perspective – tends to follow a loose life cycle.  That life often begins even before the word ‘user story’ gets mentioned and typically by people that don’t understand (or care to understand) the concept of a user story. We zoom in from 40,000 ft down to user stories in 500 or so words!  

Read other entries on user stories by following this link:

The second column this week is from Kim Pries, the Software Sensei, Kim discusses using the Extended Backus-Naur Form as a tool to extract information out of nebulous text.

Last but not least, Jeremy Berriault brings his QA Corner to the cast.  In this entry, Jeremy discusses why QAs/testers should be given space to manage their own workflow. Jeremy has recently moved the QA Corner to

Re-Read Saturday News (more…)

User stories tend to follow a hierarchy that follows the decomposition of a business need or idea into granular pieces of functionality.  That decomposition follows a basic workflow that starts when the story is voiced and ends when it is built. Along the way, each user story passes through different states that hopefully end with functionality being delivered and the story marked as done!

All three concepts are important in order to use the concept of user stories in a dynamic environment where agile and lean work is pursued.  An example is helpful to see how a user story hierarchy, flow, and states fit together.    In the following example, we will follow an automotive example to highlight the user story hierarchy, how the item impacts the user story flow, and which user story states apply to the hierarchy.  (more…)

The current is just below the surface!

Where do user stories come from and where do they go?  Agile or not, the requirements, needs, and nuances of users and customers need to be collected, written down, prioritized, and groomed.  Even though this process sounds linear it usually happens over and over again during the cycle of value delivery.  The of techniques for gathering requirements and translating those requirements into products, features, epics and user stories are varied, and we will explore them. However, first, we need to define the typical path.   We will pick the journey up after strategic definition/vision (described in our article on hierarchy)  has been identified just as or before product definition.  Here is the basic flow: (more…)

Differing definitions are a lot like swimming without a lifeguard!

A user story – a brief, simple requirement statement from the user’s perspective – tends to follow a loose life cycle.  That life often begins even before the word user story gets mentioned and typically by people that don’t understand (or care to understand) the concept of a user story.

The basic life cycle of a user story includes the following states: (more…)

Definition of done

Definition of done

In “User Stories Are For Technical, Operational and Risk Stories Too!” we made the case that user stories are not just for customer facing user interfaces.  But, we only partially answered the question:

“I would like to see some sample user stories in infrastructure projects such as network migration or upgrade, storage provisioning, or server provisioning.  I think storage provisioning would be a little bit complex due to hardening and other security requirements.”

The nuance in the question centers on the phrase “hardening and other security requirements.” There are two approaches that I often use for stories with nonfunctional requirements.  The first (and not my favorite) is through a final hardening sprint. The second approach is splitting the user stories into thin slices and then incorporating the nonfunctional requirements into the definition of done. (more…)

Proof First!

Iteration planning would be far simpler if every story was started and completed during a single iteration, if every story was independent, or deadlines did not pop up messing up carefully crafted prioritization routines.  Unfortunately, real life is a bit messier.  Having a strategy to handle variations from the best case makes life easier.  A few of the common planning glitches are: (more…)

Tom “The Brewdog” Pinternick

Tom “The Brewdog” Pinternick

The goal of all software centric projects is functional software that meets user needs and provides value. The often-trod path to functional software begins at a group of personas, then to scenarios and then to user stories before being translated into software or other technical requirements.

Personas: A persona represents one of the archetypical users that interacts with the system or product.

Scenarios: A scenario is a narrative that describes purpose-driven interactions between a persona(s) and the product or system.

User Stories: A user story is a brief, simple requirement statement from the user perspective.

In Personas, Scenarios and Stories, Part 2 we generated a simple scenario for the “Brewdog” Logo Glass Collection Application:

When visiting a microbrewery, Tom “Brewdog” Pinternick, notices that there are logo pint glasses on sale. The brewpub has several varieties. Tom can’t remember if he has collected all of the different glasses being offered. Recognizing a potential buying opportunity, Tom opens the Logo Pint Glass app and browses the glasses he has already collected for this brewpub and discovers one the glasses is new.

After a team accepts the narrative story contained in a scenario the team needs to mine the scenario for user stories. The typical format for a user story is <persona> <goal> <benefit>. Using the scenario above, the first user story that can be generated is:

Tom “Brewdog” Pinternick wants to browse his glass collection so that he does not buy the same glass twice.

Much of the activity of this scenario happens outside of the application and provides context for the developers. For example one inferred user story for the context might reflect that since many brewpubs have muted mood lighting, the application will need to be readable in low light scenarios. This is a non-functional requirement. A user story could be constructed to tackle this requirement.

Tom “Brewdog” Pinternick wants to be able to see the app in low light situations so that so that the application is usable in brewpubs with varied lighting schemes.

Other possible ways to tackle this (and other) non-functional requirement includes adding criteria to the definition of done or by adding specific acceptance criteria to all user interface related user stories. For example, the team could add “all screens must be readable in low light” to the definition of done or as acceptance criteria for screens.

In both cases, these proposed user stories would need to be groomed before a team accepts them into a sprint. Grooming will ensure that the story has acceptance criteria and fits the INVEST (independent, negotiable, valuable, estimable, small enough and testable) criteria we have suggested as a guide the development of quality of user stories. Once a story has been created and groomed, the team can convert the story into something of value (e.g. code, hardware or some other user facing deliverable).

I am occasionally ask why teams can’t immediately start working as soon as they think they know what they are expected to deliver. The simplest answer is that the risk of failure is too high. Unless teams spend the time and effort to begin to find out what their customers (whether a customer is internal or external is immaterial) want before they start building, the chances are they will incur failure or rework. Agile embraces change by building in mechanisms for accepting change into the backlog based on learning and feedback. Techniques like personas, scenarios and user stories provide Agile teams with a robust, repeatable process for generating and interpreting user needs.

Time for new shoes?

Time for new shoes?

I recently picked up a guide to a large conference that included a set of personas to help attendees decide which tracks would be of interest to them. The goal for the conference organizers was never the set of personas, but the guidance they provided to the attendees. The path from persona to the end goal in software development and maintenance often runs from persona to scenario then to user story.   Once a set of personas are established, the next step in the flow is to generate a set of scenarios. A scenario is a narrative that delineates purpose-driven interactions between a persona(s) and the product or system. Most projects require multiple scenarios to describe functionality that needs to be delivered.  An example of a very simple scenario follows:

As Tim Trackman completed his daily 10k, he found that the eyelet on his favorite running shoes had broken. He decided to order a new pair of the same shoes  so that he could continue training for his next half-marathon on his phone while he drank a cup of coffee in the hotel lobby.

The scenario includes a persona, rationale for the goal-driven behavior and the context in which the behavior will be accomplished. Unpacking the example:
Persona:  Tim Trackman
Goal-driven behavior: “order a new pair of the same shoes  so that he could continue training for his next half-marathon”
Context: “on his phone while he drank a cup of coffee in the hotel lobby”

Several other scenarios could be driven out of the same basic context, for example would Tim’s behavior be different if his favorite shoe style was not available? As with personas, a simple process flow provides a disciplined approach to generating scenarios.

  1. Familiarize the team with the goal of the product or system and the previously defined personas. This step sets the context for developing the persona. Typically the context is delivered by the product owner or someone from product management.
  2. Develop scenarios of the personas using the product or system. The scenarios are stories that explain how the persona interacts with system, their motivation and the how the interaction affects them.  I typically recommend using small sub-teams such as the Three Amigos to initially generate scenarios. In larger projects that will have multiple teams, I break the group into subgroups. The facilitator should use the context from step one to get the team to generate scenarios that fit the context.

    Remember when to write each scenario from the point of view of a specific persona. Stay away from glittering generalities. For example, if a story is written in which a persona sometimes does action, press the team to define the reason. The team must explore the motivation of the persona that would make them perform the action. For example in our running shoe scenario, if the scenario includes “sometimes Mr. Trackman searches for a shoe” the facilitator would need to push to get the team to define what the motivation for the behavior might be. These will generally require either additional scenarios or user stories later in the process.

  3. Consolidate duplicate scenarios. Carefully consider nuances in behavior before declaring two scenarios as duplicates. Nuances can be variants in behaviors can require nuances in code.
  4. Build a scenario map. Lay the scenarios out as an activity flow. Actions should flow from left to right. In our shoe scenario, Tim would buy shoes and then later get the shoes and perhaps even later return the shoes. Scenarios that involve the primary persona should be on the top row of the map (this can be used to define the minimum viable product) and tertiary personas at the bottom.
  5. Review the scenarios. Review the scenarios with the team(s). Use the review process to validate the scenarios and fill in gaps. The review process will generate conversation that can be used to add details to the scenarios. In larger projects the review process can be done as a single group (difficult to arrange) or through a number of reviews with smaller teams. The later will require a step to integrate all of the comments and feedback into the scenarios.

Coming back to our Logo Pint Glass example, a typical scenario for the “Brewdog would be:

When visiting a microbrewery, Tom “Brewdog” Pinternick, notices that there are logo pint glasses on sale. The brewpub has several varieties. Tom can’t remember if he has collected all of the different glasses being offered. Recognizing a potential buying opportunity, Tom opens the Logo Pint Glass app and browses the glasses he has already collected for this brewpub and discovers one the glasses is new.

In part 3 we will generate a set of user stories from our scenarios.

Two completely different personas using the same system simultaneously.

Two completely different personas using the same system simultaneously.

Personas are often used in software development to generate and group requirements. For example, one of the classic constructions of user stories is: <Persona> <Goal> <Benefit>. The use of personas has become nearly ubiquitous. A persona represents one of the archetypical users that interacts with the system or product. Every system or product will have at least one archetypical user that can be identified. The concept of personas was originally developed by Alan Cooper in his book The Inmates Are Running the Asylum. Personas represent different behaviors based on research into the jobs, lifestyles, spare time activities, attitudes, motivations, behaviors and social roles. I am often asked where a team should get a set of personas given the level of usage (as if they were a set of playing cards), and once a team gathers the data, how that data should be captured.

In most internal development enhancement and maintenance projects, personas are developed using some form of brainstorming process. Brainstorming with affinity diagraming is a great tool to develop personas. The Software Process and Measurement Blog has described the process of Affinity diagraming. The people involved in generating personas are critical. The team you use to generate personas needs to have a broad experiential base. It needs to be cross-functional and diverse. The team needs to be able to take systems views of who uses the systems or product, otherwise the list of personas and their definitions will be incomplete. Second, when generating ideas in the brainstorming session someone needs to act as a facilitator and provide seed questions to the team. The seed questions will help the team to uncover groups of users and potential users, their needs, behaviors, attitudes and both work and non-work activities. In the grouping portion of the affinity diagraming process, the team should first think about personas when grouping and then when naming the groups ask the team to give the groups persona names. A further twist on the tried and true affinity session mechanism that I have recently found to be effective is to have the team break up in to smaller sub-teams to review what was done and re-brainstorm entries that could fill the gaps after the grouping and naming exercise. I generally time box the second step to fifteen minutes, although time-boxing may constrain innovation. When the sub-teams return integrate the new entries into the affinity diagram. The named and grouped entries from the affinity diagram will form the basis for the documentation needed to capture the personas.

Documenting personas might be the most contentious part of the process of establishing and using personas. Documentation smacks of overhead to many in the development community. I have found that if you don’t take the time to document a persona, it is far less useful. Documenting personas does a number of things. First the act of documentation allows the team to flesh out their ideas and drive out gaps and inconsistencies. Second, documentation helps the team to establish collective memory. Third, fleshing out the nuances fleshed out and establishing institutional memory makes it more likely that the team will refer to the persona after development because the investment in time and effort generates a perception of value. When documenting personas, ensure that you keep the documentation to the absolute minimum. I use a single sheet of flip chart paper per persona; not only does the single sheet feel lean, it also allows teams to post the personas around the room. Templates are good to for maintaining repeatability.

In Agile Story Maps: Personas we discussed and referenced a template defined by Roman Pitchler. There are a wide variety of templates for capturing information about a persona. In general they all include the following information:

  1. Persona Name
  2. Picture: a picture gives the persona visual substance and personality.
  3. Job: What does a person in this archetypical group do for a living (as it relates to the product or system).
  4. Goal: A definition of why the persona would want to use the product or system. Support of the goal can be found in the more personality and lifestyle (often written as backstory) of the persona.
  5. Personality: How does the group that the persona represents think, act, or react. This attribute includes motivation, attitudes, behaviors and social roles.
  6. Lifestyle: How does the group that the persona represents actually act? What does the persona do both at work and in their spare time?

Every template that I have seen (or created) is nuanced based on the needs of the team and the project. For example, the personas generated to guide developing requirements for an enhancement to a data entry application would be different from the personas needed to plan a major Agile conference. In the latter case more emphasis might be needed around motivation and lifestyle which would influence the speakers that might be accepted, social events planned and when the speakers and events might be slotted in the schedule. Teams use personas to help them think conceptually about the problem they are trying to solve without getting bogged down by having to think about and address each individual that uses the system or product as a special, individual case.

Personas are a tool help teams to understand a class of users by creating an archetypical user. Personas need to be identifiable and have back-story that includes needs and goals. The use of fictional people allows the team to dissociate themselves from the large number of individuals in the user base so they don’t get trapped in paralyzing detail. Personas need to be written down or you will not remember the nuances of personalities and lifestyles that make any two personas different.

Next Page »