Product Backlog Refinement

• (PO, DT, SM (SH))
• usually consumes no more than 10% of the capacity of the Development Team
• it is time-efficient to refine only the top items in the Product Backlog because they will inevitably learn new things that change their view of items further down or make them redundant
• The act of breaking down into smaller more precise items: adding detail, estimates, and order to PBIs (attributes can vary) Scrum doesn’t prescribe how you do it
• refinement is not an event in Scrum. is something that Development Teams do as a natural part of development
• To maximize what we can learn (e.g. from feedback from stakeholders and by simply doing the work) and to reduce the risk of building the wrong product, we want to break down and clarify items to the point where we are fairly confident that we can complete them within a Sprint
• It may be tempting to go ahead and break down all the work on the Product Backlog to make it fit within a Sprint. But a much better use of our time is to break down and clarify only those items that we’re about to start work on (say next Sprint or one soon after). The time spent on items further down the Product Backlog is largely wasted as we are bound to learn things that change our views on how to implement them or make them irrelevant altogether
• Creates PBIs ready for selection in a Sprint
• Ongoing activity
  • It never stops because requirements and opportunities never stop changing. Detailing everything up front would create waste and also delay the delivery of value
• Allows:
  • PO to plan future
  • Developers create plan for current Sprint
• Effective: during Sprint planning PBIs selected quickly and most times most PBIs delivered
• GOAL: get Product Backlog Items to an actionable level of detail
• Lack of it can produce:
  • Few PBI completed or not able to deliver a done Increment at the end of Sprint
  • Problems estimating
  • Wrong Sprint Goal, creating wrong Features, features poorly created or low value
  • Low quality and Technical Debt, The need of Stagger Iterations
• PBIs reminders of conversations that need to happen in the future, and PBR… the ongoing process of having those conversations
• refinement session
  • 1. typically begins with the Product Owner presenting the current Product Backlog to the team
  • 2. The team start at the top of the PB and work their way downwards, refining each item in turn
  • 3. The team stop once the session’s time-box runs out
• Applying the Goldilocks Principle: about finding what is “just right” for your team
  • Goldilocks questions about refinement benefits with the Scrum Team
• Diverge-Converge Pattern (multiple cycles during a Sprint can happen)
  • Used to clarify or break down Items
• Benefits
  • Increase transparency
    • what you plan to deliver, as well as your progress
  • Clarify value
    • helps ****the Development Team build the right thing
  • Break things into consumable pieces
    • complete more than one in a Sprint. Having more than one PBI in a Sprint gives the team some flexibility to meet a Sprint Goal and deliver a “Done” Increment
  • Reduce dependencies
    • Dependencies often turn into impediments and can grind a team to a halt
    • you may not avoid them all, but can reduce them where possible
    • This is especially important for dependencies outside the Scrum Team
    • Many options
      • slice and split the PBIs in different ways
      • re-order
      • collaborate with other teams to help resolve the dependency in advance
    • at the very least, you want the dependencies to be transparent
  • Forecasting
    • refined PB combined with historical information about the Scrum Team’s ability to deliver helps to forecast
    • Scrum does not forbid up-front planning. Scrum simply says to consider your effort to do so, the potential waste, and the fact that you cannot perfectly predict the future
  • Incorporate learning
• PURPOSE
  • Clarifying Items (Full team not needed) preferably done directly with the stakeholders
  • Breaking down Items (Full team not needed) that are too big to pull into a Sprint
  • Re-ordering Items (suggested all team involved)
  • Adding or Removing Items
  • Estimating effort Items (suggested all team involved, Responsibility of Developers, PO help them understand and select trade-offs)