Many product managers struggle with getting the right level of detail in their backlog. If the backlog is too vaguely defined, then your team picks up stories that aren’t immediately actionable, which can slow them down. On the other hand, if the backlog is too well defined, then it becomes rigid and fails to evolve as your product takes shape. In fact, this rigidity can even stifle the creativity of the team as they try to find the best option for achieving each story’s desired outcome.
So how do you strike the right balance? Try thinking about the timeframe in which your team will need each of the stories in your backlog. For example, will your team need this story in their next iteration? Or is this story better suited to be tackled two to three iterations in the future? Or is this story not even slated for a specific iteration, but you just have a feeling that your team will need it some day?
Knowing when your team will need to pick up a certain story can help you better understand how refined that story needs to be. And it can save you from the trap of under-refining stories that your team will need to start immediately or over-refining stories that your team won’t be picking up for some time.
Let’s look at a few examples.
Stories slated for the next iteration should be well-refined and ready to be picked up at any time. These are the stories that are immediately actionable that your team can begin to work on with little hesitation. You and your team will need to agree on exactly what makes a story actionable, but here are a few options to consider as a starting point:
Each story has a stated objective and corresponding business justification. While this is often expressed in the popular As a ___ I want ___ so that ___ format, the specific format isn’t important as long as the team knows what they’re trying to accomplish and why.
Each story has defined acceptance criteria to give the team a clear and unambiguous picture of what the end state of the story should look like.
Each story meets the agreed-to Definition of Ready established by your team. If your team has yet to establish their own, then the INVEST criteria is a good starting place to consider which qualities of stories are critical to your team beginning work on a story and which qualities may not be as important as they first seem.
Stories slated for the next two or three iterations aren’t ready to be picked up by your team today, but they are in a good enough state that you as the product manager can have a discussion about them with your team to decide when—if ever—these stories should be worked on.
Expect these stories to contain no more than an objective and business justification. In addition, don’t be surprised if they tend to be estimated larger than those stories already slated for the next iteration. In fact, it’s not uncommon for many of these stories to simply exist as unrefined epics. The goal for stories in this timeframe is to pin a specific idea to the backlog so that it’s not lost, as well as to facilitate a discussion around when it would make sense for the team to invest in tackling that story. If the story is not specific then this discussion will meander and fail to be productive. But, if the story has been over-refined then the creativity that would otherwise emerge from that discussion may be stifled.
The remaining stories in the backlog that aren’t slated for the next few iterations should be the least refined of them all. These stories tend to be largest stories on the backlog and exist only as vague ideas of things you and your team would like to consider for the future.
These stories are not ready for a team to work on and really aren’t even ready for a team to discuss. Instead, these stories exist as placeholders for the Product Manager to periodically evaluate whether they still make sense for the direction of the product and, if they do, to begin to introduce them into the discussion.
Structuring your backlog according to these rules of thumb will help you strike the balance between stories that your team can be productive with immediately and those stories that still require a bit more refinement.
Depending on your team and your product, you may find that you need to tweak these timeframes to optimize the backlog for what works best for your team. As with most agile practices, experimentation will be the key to finding what works the best for you and your team.
How ever you decide to implement it, refining stories according to the timeframe in which you expect to work on them will give you a nice guideline of how much of your backlog should be well-refined while keeping the risk of over-refinement at bay.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
