Backlog Refinement – The Rodney Dangerfield of Scrum Ceremonies

Seeing the Patterns

• Have you ever been in a Sprint Planning session only to realize that the team doesn’t have enough understanding of the product backlog items (PBIs) or related requirements to properly plan the Sprint?

• Does your team feel like they don’t have time to "waste" elaborating PBIs, learning about Acceptance Criteria, or collaboratively estimating as a team?

• Has some manager decided that it’s “too expensive” or “inefficient” to bring the whole team together regularly and that just one or two “leads” can effectively review and estimate PBIs for the entire team?

These misconceptions and related anti-patterns are far too common when new teams begin transitioning to Agile/Scrum.

Backlog Refinement may be the 2nd most important activity (after the Retrospective) for enabling team improvement.  I like to think of it as “collaborative discovery”.  

But too often, new Scrum teams neglect it only to find themselves struggling to establish predictability, sustainable pace, stakeholder engagement or collective ownership.  The most common indicators of this neglect emerge in:

• Painful and ineffective Sprint Planning

• Repeated “undone work” pattern at the end of the Sprints.  

• Poor Quality and higher Defect rates

Collaborative Discovery

The Scrum Guideⁱ refers to Product Backlog Refinement as “the act of adding detail, estimates, and order to items in the Product Backlog”, as well as “an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items”.  Although not an official Scrum “event”, those of us with experience will come to view Backlog Refinement as a critical activity, making it both a core collaboration “event”, as well as an on-going, collaborative activity for the entire team.  

As with most recurring activities, it’s important to keep it fresh by changing up the format and/or focus from time to time.  It should always be viewed as a working session, with a clear expectation that the team concludes with some valuable outcome.  That means, sometime the focus may be on:

• story elaboration or refinement

• acceptance criteria refinement

• lightweight, visual design  

• adjusting value prioritization with technical feasibility or risk

• relative estimation    

I encourage teams to timebox their refinement sessions to allow time to do a combination of things including, learning about new items that have emerged, elaborating items that have emerged as priorities, validating requirements for those items ready for planning and doing some form of relative estimation, like planning poker.  I also encourage the use of the INVESTii acronym/mnemonic to help them ask the questions necessary to know when they’ve reach good understanding.  My colleague Dhaval Panchal recently shared his “walk the dog” concept with me.  I love it because it provides teams with a very simple way to connect with both the functional and technical aspects of a PBI or requirement.

Teams should have a known Definition of Ready (DoR) that they have agreed to as a team that helps make sure PBIs are ready to review as a team or plan for Sprint.  If your Product Owner (assuming you have one) is too busy or disconnected from the team it can be very challenging for the team.  If you have “Business Analysts” on the team, they can often serve the “glue” between the PO and the team to help make sure the necessary details emerge in a timely manner. Include SMEs and key Stakeholders, as necessary, to make sure expectations are managed effectively.

Remember, it’s not solely the responsibility of the PO to refine the backlog. I believe the entire team should contribute to this, certainly early on, to achieve collective ownership and predictability.  This does not mean that every person must get into the details of every item. It may make sense to self-organize a few folks around - what’s valuable, what’s feasible or what’s usable.  While some will advocate that you don’t need the whole team participating in Backlog Refinement, I think new teams need this to build collective ownership and shared understanding.  More mature teams may get away with alterations to this, but be careful not to inject more risk or ambiguity by excluding team members from the conversation.

Some teams choose to do this once per Sprint, while others may do shorter, but more frequent, refinement sessions. We can debate the merits of estimation, or the level of detailed planning needed by the team, but you can’t argue the value of collaborative discovery, where the team learns, explores, designs and estimates together.

Are your teams actively collaborating, or just sitting in a room with one person talking, while everyone else wishes they were somewhere else?

Conclusion

If you see this activity being ignored, or you sense that your team is struggling to plan and/or deliver consistently because of this, bring the topic into your next Retrospective, identify the impediment and commit, as a team, to overcome that obstacle.  Although I advocate having the entire team involved, the absence of a few team members should not prohibit the rest of us from having the conversation. Be practical, show up prepared and use your time wisely.

High-performing teams are the ones that learn together, deliver together and succeed (as well as fail) together.  Give Backlog Refinement the respect it deserves and your Scrum team, particularly the value and quality of what they produce, will definitely improve.