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 May 2018

The Berlin Scrum User Group meets on May 8th at agile42 in Grünberger Straße

Image of aballer

Alexandra Baller

agile42 Team Assistant

Agility requires cultural change

Article published in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Agile in Everywhere: Sales

An experiment as a ScrumMaster and Agile coach working with a Sales team, where Agile practices are supporting new acquisition and retention targets

Image of ebru4984

Ebru Yalçınkaya

I act as a change agent where the teams, domains need to enhance agility to reach their goals, to create a shared vision if needed. I coach every kind of team , every domain, like management teams or like customer care, technology and sales groups.

Good VIBE at Scrumtisch Berlin

Scrumtisch March 2018 at SAP 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.

Step up your Kanban game

In the upcoming weeks, Accredited Kanban Trainers from agile42 will facilitate certified Kanban training in locations all around the world

Image of mikefreislich

Mike Freislich

Image of rhilll

Russell Hill

Image of mgaewsj

Gaetano Mazzanti

My background includes a long experience as a manager in the Software and Machinery Industry. I worked in USA and India leading distributed teams in advanced software projects (CAD/CAM, PLM, Industrial Automation, Plant Control and Supervision). As a coach I am now trying to help organizations to change embracing Agile and Lean values and principles. I am a WIP limit addict :) and a KCP