April 8, 2015

Backlog Refinement – The Rodney Dangerfield of Scrum Ceremonies

I tell ya’ sometimes it seems like Backlog Refinement just don’t get no respect!

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 Guidei 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?


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.


iJeff Sutherland, Ken Schwaber 2013 http://www.scrumguides.org/ iihttp://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Image of rdolman

Richard Dolman

Agile pragmatist, evangelist, coach, trainer, practitioner, explorer and learner…
blog comments powered by Disqus
Image of rdolman

Richard Dolman

Agile pragmatist, evangelist, coach, trainer, practitioner, explorer and learner…

Latest Posts

Scrumtisch September 2019

The Berlin Scrum User Group meets on September 30th at agile42, Gruenberger Str. 54, 10245 Berlin.

Image of aballer

Alexandra Baller

agile42 Team Assistant

The Scrum Master as an organizational multi-function pocket knife

The Scrum Master is a jack of all trades with a magic problem-solving knife in his back pocket or a master of Scrum?

Image of elrich.faul

Elrich Faul

I’m passionate about helping the current and next generations to develop the skills they need to be successful in a rapidly changing world. I believe that by leveraging my expertise in engineering, psychology and management I can empower individuals and teams to reach their maximum potential. I’m inspired when given the opportunity to coach teams as well as individuals toward growth and happiness.

Campaigning for Dave

agile42 coach Dave Sharrock is running for Scrum Alliance Member Elected Director and we support his candidacy!

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Talking agility at Agile Islands conference

Pascal Papathemelis and the agile42 team will be present at the Agile Islands 2019 conference in the Åland Islands

Image of pascal

Pascal Papathemelis

Pascal has worked as an agile project manager/scrum master/facilitator of various developments in size and type for almost two decades. His focus is on people and practical approaches in order to deliver value. Currently Pascal is working at agile42 as an agile coach on a journey to help organisations and individuals grow, improve and become more efficient in a sustainable way.

Coaching at the Nordic Business Forum in Helsinki

Giuseppe De Simone will represent the Scrum Alliance at Nordic Business Forum in Helsinki, October 9-10 providing agile conversations to attendees

Image of giuseppe.desimone

Giuseppe De Simone

Giuseppe De Simone is a Certified Scrum Trainer (CST), Certified Enterprise Coach (CEC) and Certified Team Coach (CTC), passionate about helping individuals, teams and organizations become more productive by embracing Agile values, principles and practices. He is one of very few to be accredited from the Scrum Alliance as an educator of the Certified Agile Leadership and Path to CSP programs.