User Stories

This week we explore the impact of process (it really isn’t a bad word) problems in prioritization. Prioritization requires a steady hand and consistency. The process for prioritization should have more in common with a well-oiled basketball or futbol team than five-year-olds playing soccer in the schoolyard. How the moving parts work together is a process.

We also have a visit from Tony Timbol discussing freestyling user story formats in his To Tell A Story column.


Work entry, in its simplest form, is the steps needed for work to be triaged to ensure that it is the right work, that it is ready to be worked on, and the priority of the work. This week we talk about five common patterns. On Tuesday I will include the PDF in the feed to see if I can spur a discussion about other patterns.  

Play now

Tony Timbol of Agile Ready joins the Software Process and Measurement Cast this week. Tony and I have worked together in a past life, so we had a bit of fun poking at each other as we talked about user stories, Tony’s new product, Agile Ready, and entrepreneurship. Tony delivers a number of great tips, some of which I already have put to use.   


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…)

Next Page »