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

Definition of Done vs Acceptance Criteria: a Meet the Coach Webinar

First webinar in "Meet the Coach" series on Wednesday, October 16, 2019 aiming to support individuals working in an agile context

Image of magnus.kollberg

Magnus Kollberg

Agile Leadership at Manage Agile 2019

agile42 is Gold Sponsor of the Manage Agile conference taking place from November 4th to 7th, 2019 in Berlin

Image of simsab

Simon Sablowski

Simon has spent several years working as a software developer, ScrumMaster and CTO. He is dedicated to shortening feedback loops to accelerate learning and strengthening team collaboration to maximise synergies. At agile42, Simon enjoys coaching and training teams and organisations that desire to attain higher productivity, continuous innovation and extraordinary performance.

ORGANIC agility in Helsinki

Join Andrea Tomasini and agile42 Finland in Helsinki on October 7, 2019, to discuss how to make organizations more resilient

Image of lasseziegler

Lasse Ziegler

Lasse Ziegler is a agile and lean consultant, trainer and coach. He has over 10 years of experience in complex and difficult software development project and software product development.

Article in JAVAPRO Magazine: achieving resilience

Resilience and leadership as vital capabilities in our complex times 

Image of marion

Marion Eickmann

I am one of the founders and the executive director at agile42. I have supported strategic product development and leadership development for longer than 15 years. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: ORGANIC agility, complexity, resilience, organizational culture & Agile? Just send an email :-)

Agile HR

Image of ayse.turunc

Ayşe Turunç

As an Agile coach, I strongly believe in people talent, in collective intelligence and that happy teams are more efficient. I'm looking forward to put my talent to help teams and individuals to work better together and grow.