Jeremy Jarrell

Agile Made Simple

Tag: backlog refinement

Using the Blocking and Tackling Backlog Refinement Pattern to Ensure a Great Sprint Planning

This post originally appeared on the PivotalTracker blog. We’ve all had that sprint planning meeting. Your team spent the entire session arguing over which stories to include in the next sprint…

This post originally appeared on the PivotalTracker blog.

We’ve all had that sprint planning meeting. Your team spent the entire session arguing over which stories to include in the next sprint and you never even made it to sizing. By the time the session was over, you were no closer to having the next sprint planned and all that you’ve gained for your trouble is a frustrated and disheartened team.

If this sounds familiar, then it might be time to consider backlog refinement. Backlog refinement is a practice intended to help you keep the top of your backlog in a refined state so you can have better sprint planning sessions. But despite the value backlog refinement can yield, there is no officially prescribed approach for how to do it. However, if you’re looking for a simple way to introduce this practice to your team, then don’t despair: there’s an easy approach that you can use with your team today.

Blocking and Tackling Your Backlog

The *blocking and tackling* approach consists of two separate refinement meetings spaced evenly throughout each sprint. For example, if your team operates on two-week sprints, then you might hold the first session on the first Wednesday of the sprint and the second session on next Wednesday of the sprint.


In the first session, known as *blocking*, your goal is to select the stories that you expect your team to work on in the next sprint. Your selected stories will be a function of both your planned goal for the next sprint and your team’s forecasted capacity for that sprint. If your backlog has already been prioritized so your most important stories are near the top, and these stories already have a rough estimate applied to them, then this process tends to be relatively straightforward. However, it’s still helpful to do this session with the help of your team for two reasons.

First, sharing more detail about your goal for the next sprint and which stories you believe will enable that goal helps your team better understand the bigger picture of what they are trying to create. This understanding will allow them to make decisions in the current sprint that will put them in a better position to accomplish the work selected for the next sprint.

Second, while your team will save their final estimates for the next sprint planning meeting, they can often share their impression of whether or not the work selected seems too large for the next sprint—or even too small. If it turns out that the work you selected isn’t quite the right fit, then you have the rest of the sprint to decide how to adjust your selection accordingly.

The rest of the session is saved for discussion. Introducing the stories you’ve selected to your team often leads to questions and discussions about alternative approaches…many of which you may not have considered. Surfacing these questions before the sprint planning meeting allows you to take time before the next refinement session to find the answers your team needs to confidently move forward.


The second session, known as refinement, is where the real work happens. During this session, you will work with your team to further refine the selected stories to ensure that they’re ready for the next sprint planning meeting.

This session begins with you reviewing the selected stories for the next sprint to help refresh your team’s memory of what was selected. This is also a great opportunity to call out any changes that were made to your story selection to better fit your team’s forecasted capacity.

Next, take the time to provide any answers to questions you were unable to answer in the previous session. Not only does this help further refresh your team’s memory of their concerns regarding each story, but it also improves the chances of productive discussion later in the session.

Once you’ve answered any outstanding questions, give your team the opportunity to ask any questions that may have occurred to them since the last refinement session. Your team has now had several days to more thoroughly consider their approach to these stories; therefore, a few questions are to be expected. This is their chance to pose those questions to you before the deeper discussion begins.

Finally, the remainder of session is focused on ensuring that the selected stories are in a *ready state* for the next sprint planning session. Many high-performing teams already have a checklist in place of what they consider necessary for a story to be ready for discussion in an sprint planning meeting. The contents will vary, but at a minimum they often specify that a story must have a brief description of its objective, acceptance criteria, and a rough estimate.

If your team doesn’t have a checklist of its own yet, then the INVEST criteria is a great place to start. INVEST specifies six qualities that are often associated with well-refined stories. Try comparing each of your selected stories against the INVEST criteria to see what gaps it exposes. After several sprints of this, you’ll likely start to recognize which qualities seem to add value to your team and which qualities do not. Once this happens, feel free to adapt the INVEST criteria to your own set of criteria that makes the most sense for your team.

Getting the Results You Need

Regularly holding backlog refinement sessions will result in smoother sprint planning meetings and, ultimately, more predictable sprints. However, the approach outlined above should be considered a starting point, so don’t be afraid to adjust this practice to better fit the needs of your team.

Regardless of how you ultimately approach backlog refinement for your team, what’s important is that your team is always ready to start the next sprint and that you or your team never have to suffer through a painful sprint planning meeting again.

Are you a Product Owner who wants to help your team better understand your vision for your product. Or do you want to understand how you can work more effectively with your development team? Check out my course series Product Owner Fundamentals, part of the Using the Scrum framework learning path from Pluralsight, to learn how you can use Scrum to help your team deliver great products that your customers love.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Using the Blocking and Tackling Backlog Refinement Pattern to Ensure a Great Sprint Planning

What’s the Right Amount of Backlog Refinement?

Many teams struggle with getting the right level of detail in their backlog.  If the backlog is too vaguely defined, then the team picks up stories that aren’t immediately actionable…

Many teams struggle with getting the right level of detail in their backlog.  If the backlog is too vaguely defined, then the 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 the product takes shape.  It can even stifle the creativity of the team as they try to find the best option for achieving each outcome.

So, how do you strike the right balance when creating your own backlog?  In his excellent book Scrum Product Ownership, Bob Galen introduced the 20/30/50 Rule for product backlog refinement to address this very problem.

Here’s how it works…

The First 20 Percent

20% of the stories on the backlog 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 work on with little hesitation.  You and your team will need to agree on exactly what makes a story actionable for them, but here are a few options to consider as a starting point….

  1. Each story has a stated objective and corresponding business justification.  While this is often expressed in the popular format “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 they’re trying to do so.
  2. 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.
  3. 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 place to start to consider which qualities of stories are important to your team team which may not be as important.

The Next 30 Percent

RefinementThe next 30% of the stories on the backlog aren’t ready to be picked up by your team, but are in a good enough state that you as the Product Owner can have a discussion about these stories with your team and stakeholders to decide when these stories should be worked on…if ever.  

Expect these stories to contain no more than an objective and business justification and to be sized larger than the first 20%.  In fact, it’s not uncommon for many of these stories to simply exist as unrefined epics.  The goal for stories in this bucket are 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 won’t be productive, but, if the story has already been too well defined then the creativity that would otherwise emerge from that discussion will be stifled.

The Final 50 Percent

The final 50% of stories are the least refined of them all.  These stories tend to be largest stories on the backlog and exist only as vague ideas of things the team would like to consider for the future.  If the previous set of stories tend to be at the Epic level, then these items are the Themes of your backlog.  

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 Owner to periodically evaluate whether they still make sense for the direction of the product and, if they do, to begin to introduce them to the discussion.

Finding What Works

Structuring your backlog according to these rules of thumb will help you strike the balance between items that your team can be productive with immediately and items that still deserve more refinement.

Depending on your team and your product, you may find that you need to tweak the percentages to optimize the backlog for what works best in your organization.  You may also find that you need to experiment with whether these numbers correspond to the total remaining story points in your product backlog or to simply the total number of remaining product backlog items.  As with most opportunities in agile, experimentation will be the key to finding what works the best for your team.

However you decide to implement it, the 20/30/50 rule gives you a nice guideline of how much of your backlog should be ready at any time while keeping the risk of over refinement at bay.

Want to learn even more ways to slice your user stories so your team can start working with them immediately? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on What’s the Right Amount of Backlog Refinement?

Type on the field below and hit Enter/Return to search