Scrum Events : Product Backlog Refinement

The Product Backlog Refinement meeting is a key component of ensuring work is ready

When doing agile at scale work must be READY before it can be DONE – only READY work can be taken into a sprint

The Product Backlog Refinement meeting is not a formal scrum meeting, but it is so useful that most scrum teams do it.  Product Backlog Refinement is where the development team helps the product owner get work ready for the next sprint. 

  • It happens sometime in the previous sprint, leaving enough time to work on items that need more effort before sprint planning can proceed. Don't leave it until too late!
  • Normal duration is a two hour time-box for a two-week sprint (four hours for a one-month sprint). 

Work being ready is a key enabler for a number of devOps concepts:

  • FLOW (DevOps 1st Way) : work that is Ready flows through the system better because it is understood well, is free of dependencies and is decomposed to a small and consistent batch size, enabling it to process through the system faster and with higher quality and lower variation
  • Quality Assurance not Quality Control : work that is Ready enables the notion of building-in quality, versus inspecting-in quality (or trying to) because quality assurance is shifted-left to occur before we begin implementation
  • Finishing is more importantant than Starting : also known as 'slow down to speed up'. Work that is ready is work we know we can finish, not just start, avoiding waste and confusion caused by stalled work
  • Shortened Feedback Loops (DevOps 2nd Way) : Ensuring work is ready means we improve quality by taking feedback from all downstream roles before we begin implementation, rather than waiting until it is already built and lands in their lap, ready or not

The technique we follow is to use Sprint Estimation to Inspect and Adapt the Product Backlog Items.  Understanding emerges naturally as the Scrum Team works to come to an agreed estimate on each item.

  • Only the people doing the work can estimate the work (Development Team)
  • Estimation cannot be done on their behalf 
  • If the work is not estimable that means it is not understood
  • Work that is not understood, by definition, is not READY

The INVEST criteria is used to confirm work is READY.

  • Independent | If we start it we can finish it
  • Negotiable | If it is too big we can split it into smaller bits
  • Valuable | The business value is clearly described so we know what we are trying to achieve
  • Estimable | Can be estimated. If we can’t agree on an estimate, that means we don’t understand it
  • Small | 2-3 days work for the team, because we know that small, consistently sized, pieces of work  flow most effectively through the system
  • Testable | Because if we cannot test it, we don’t know whether it is DONE



   Priority | Product Owner has confirmed that the Product Backlog is prioritized the way they want it
   GOAL | Product Owner has described draft scrum goal and discussed with Development Team
   Refine  | Describe | Product Owner describes the first (next) Product backlog Item
   Refine  | Discuss |  Development Team have clarified their understanding through clarifying questions and comments about the Product Backlog Item
   Refine | Estimate |  Development Team has estimated the item (repeat prior step until consensus among the Development Team is confirmed)
   Refine | READY |  Development Team have assessed against the INVEST Criteria and follow up actions have been identified
   Refine | Repeat |  Return to the refine | describe step, until timebox expires or we have run out of items
   Set Actions |  Document actions needed to get the items to a completely READY state before the next sprint