Evolution of a User Story

Many Product Owners we work with find themselves struggling with when and how they should break their epics down into an actionable user story.  In this post, we’ll talk more about the “when” portion and how you can get into a regular cadence of evolving your backlog.  We will focus mainly on Scrum teams in this narrative, but the principles can easily be translated to other agile teams.

We have all been there…whether in a brainstorming session or while working on documenting a new product feature or initiative.  Ideas are flying and details are being documented.  Lots of time is spent detailing features and discussing what-if scenarios to make sure we do not forget anything.  We are an agile team so Product Owners are feverishly documenting the details into user stories.  Months later when the development team begins to work on the feature many of the assumptions we made have changed and now we have to re-work designs, acceptance criteria, and user stories to fit with our current situation.  Product Owners are defensive about the work and effort they put into the old user stories and development teams are saying they do not have enough information to proceed.

How can this be, we followed our agile training and created the user stories with detailed acceptance criteria, but our development team still says it’s not good enough?  In many cases, the key problem in this scenario is that the product owner and development team have not been collaborating enough on the stories leading up to this point and perhaps too much detail has been put into the story too early.

How can we fix it?

We recommend using regular Backlog Grooming and Stakeholder Backlog Review sessions as the drivers for collaboration and prioritization.  Let’s put definition and context around some of the terms we are using in this post.

Epic is the inception of a new feature or product.  There is more uncertainty at this level and we usually want to keep details non-prescriptive.  At this level we will start adding some notes and information from our discussions with the team.

Feature stories are the breakdown of epics into smaller sized chunks of work.  These typically are the smallest definition of releasable value from a customer perspective.  Here we want to see acceptance criteria and make sure the team understands the story.

Sprint-sized stories are the breakdown of feature stories (or epics) that are small enough to fit into a sprint yet still deliver incremental value.  Typically the Product Owner (PO) has to partner with the team to determine how to breakdown a feature story into incremental stories.

Backlog Grooming sessions should be time-boxed and are typically held once per sprint with the following participants: PO, Scrum Master (SM), team, and User Experience (UX).  The major goals of the meeting are (your first session probably would be modified from this list to get bootstrapped):

  1. Make sure stories prioritized for the upcoming sprint are understood and dependencies and environments are handled (no surprises in sprint planning).
  2. Begin breaking down upcoming feature stories into sprint-sized stories (with estimates).
  3. Review near-term feature stories that are not quite close enough to start breaking down further.  We do this as new details may need to be captured.  Add or modify estimates where necessary.
  4. Estimate epics.  This item and the previous item are crucial to the success of the Stakeholder Backlog Review sessions so that items can be prioritized accordingly.

Stakeholder Backlog Review sessions will typically be held once per sprint, but this may vary depending on the volatility of priorities.  As the name implies the stakeholders should be involved with this meeting along with the PO.  Team members are optional. Major goals of this meeting include:

  • prioritizing new epics and feature stories against existing backlog
  • reviewing portfolio prioritization
  • identifying release scope

Example

Let’s follow an example to help illustrate.  Let’s start with an Epic being born in a brainstorming session for an imaginary online shopping website.  Most of you are probably familiar with a similar site called Amazon.com.  In this case, let’s pretend we are adding a “wish list” type of feature to our site.

 
 

After the meeting, the product owner adds some notes to the card that were brought up in the brainstorming session.  We want to be careful here not to be too prescriptive to allow for later conversations:

In the next Backlog Grooming session, the team reviews the new epic and assigns it a point value of 40 since it is relatively large with uncertainties and seems to be at least an order of magnitude bigger than some 20 point stories already on the backlog.  During the next Stakeholder Backlog Review meeting the epic is prioritized into the existing portfolio backlog.  For the sake of the narrative let’s pretend this is a very high-value feature and it is targeted for an upcoming release.
At this point the PO makes an attempt at breaking our epic into feature stories:

 

During the next Backlog Grooming Session the PO reviews the feature stories with the team and gets story point estimates.  During this process, the team discusses each story for clarification and to identify questions.  Now, the PO will document new stories and acceptance criteria:
The PO can take the new, estimated stories to the Stakeholder Backlog Review meeting to be prioritized into the backlog replacing the epic story.  And again for the sake of the narrative, let’s pretend at least one of the features is near the top of the backlog.  The PO can begin engaging with UX and the team to start getting mock-ups of the feature.

At the next Backlog Grooming session, the PO can work with the team to break the feature down into sprint-sized stories with new story point estimates.  And the PO will prioritize the sprint-sized stories against the backlog.  In subsequent Backlog Grooming sessions, as the feature becomes closer to implementation, the team can begin making sure blockers and dependencies are handled.  And remaining questions and acceptance criteria can be dealt with prior to the story being picked up in a sprint.  And finally, the story can be picked up in a sprint for implementation.

Conclusion

In summary, you can see that we have followed one epic being broken down over the course of multiple Backlog Grooming & Stakeholder Backlog Review sessions to the point at which some piece of it will be picked up for implementation.  In reality, the example becomes more complex as there are typically many more stories and priorities involved with your backlog.  However, you will see if you can get into a regular cadence with your planning sessions everyone involved should be thankful as you will be focusing detailed efforts on the right things while keeping everyone in the loop and allowing for re-prioritization of the entire backlog.

Become a Certified Scrum Product Owner. 

The information provided in this content is meant for general informational purposes only and should not be regarded as professional guidance for specific business scenarios. Results may differ depending on your organization’s circumstances. It is recommended to consult with a qualified industry expert before acting on this information. The coaches at Agile Velocity are available to address any inquiries you may have.