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