How to deal with ineffective Product Backlog refinement?



  • We are following Scrum but our https://scrumguides.org/scrum-guide.html#product-backlog meetings are not successful at all. The Product Owner (PO) presents a story and there are so many open questions and loose ends that we never manage to go through more than 1-2 stories in the session.

    As a result many stories are refined while the Developers actually start work on them during the Sprint. I am not really clear what could be the root cause or how it can be corrected besides the fact that all main topic of the stories are completely unknown to the team until that refinement meeting before Sprint Planning.

    What are common cases that cause this? I don't think this is expected following Scrum.



  • TL;DR: You're Missing a Definition of Ready

    The whole Scrum Team should work together to define a standard Definition of Ready for both Product Backlog refinement and Sprint Planning activities, and should collaborate as a team to ensure that improperly-refined Product Backlog items (PBIs) are:

    1. a priority item at https://scrumguides.org/scrum-guide.html#sprint-review to create https://www.agilealliance.org/glossary/information-radiators/ and https://scrumguides.org/scrum-guide.html#transparency about the granularity and estimation problems to keep stakeholders informed;
    2. an urgent item at each and every https://scrumguides.org/scrum-guide.html#sprint-retrospective until the issues are resolved;
    3. are given space and priority within the https://scrumguides.org/scrum-guide.html#product-backlog itself if addressing the problem requires training, team capacity, or otherwise needs explicit inclusion in the project for scope, scheduling, or budgeting purposes; and
    4. items that aren't ready for Sprint Planning are either reduced to https://www.scaledagileframework.com/spikes/ to assist with refinement or estimation in a future Sprint, or rejected from the current https://scrumguides.org/scrum-guide.html#sprint-backlog .

    The rest of the answer explains how and why the Scrum framework https://scrumguides.org/scrum-guide.html#end-note , and recommends some of the things your team can collectively do about it within the defined scope of the Scrum framework.

    Developers Can Gate Poorly-Refined PBIs During Sprint Planning

    The Product Owner (PO) presents a story and there are so many open questions and loose ends that we never manage to go through more than 1-2 stories in the session.

    The https://scrumguides.org/scrum-guide.html#product-owner is solely accountable for the https://scrumguides.org/scrum-guide.html#product-backlog , and the Backlog Refinement event is meant to ensure that stories meet the Definition of Ready for https://scrumguides.org/scrum-guide.html#sprint-planning . Note that Scrum itself doesn't actually use or define the term "Definition of Ready," although it's commonly used by agile practitioners to describe its related activities. However, the 2020 Scrum Guide https://scrumguides.org/scrum-guide.html#product-backlog :

    Product Backlog items [often referred to as "PBIs"] that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller[,] more precise items. This is an ongoing activity to add details, such as a description, order, and size.

    Please note that the refinement event—many agilists related to standardized refinement criteria such as https://en.wikipedia.org/wiki/INVEST_(mnemonic) as the Definition of Ready—isn't actually specified as a https://scrumguides.org/scrum-guide.html#scrum-events , but the related activities are referenced enough throughout the Scrum Guide that its lack of inclusion as a formal event should probably be considered an unintended oversight. Product Backlog refinement is where questions about issues with granularity and any item-specific https://scrumguides.org/scrum-guide.html#increment should be called out. If the Definition of Ready, Definition of Done, or Product Backlog item granularity aren't sufficient for reasonable estimation during Sprint Planning then the Scrum Team should consider such stories as unsuitable for inclusion in https://scrumguides.org/scrum-guide.html#sprint-backlog for the current Sprint.

    Developers Should't Accept Unrefined or Inestimable Work into a Sprint

    The Developers are https://scrumguides.org/scrum-guide.html#sprint-planning to select the work that will be included within the Sprint, and are therefore implicitly empowered to reject work for the Sprint that doesn't meet the Sprint Goal, or that is insufficiently refinable during Sprint Planning to fit within a single Sprint within a reasonable confidence interval. Planning Poker and other consensus techniques such as https://www.lucidmeetings.com/glossary/fist-five

    See Also

    Consensus Techniques

    • https://www.ncfp.org/knowledge/fist-to-five-voting-and-consensus/
    • https://en.wikipedia.org/wiki/Consensus_decision-making
    • https://www.linkedin.com/pulse/estimation-prioritization-agile-safe-framework-samir/



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2