When we refine the Product Backlog, we simplify it by reducing the size, and therefore the complexity, of Product Backlog Items (PBIs) in advance of Sprint Planning.This results in a Product Backlog that is better understood by the Scrum team, is more easily solved and sized by the developers on the Scrum team, and carries substantially less risk into the Sprint. Improvements in team performance and product quality can be, in a large part, traced directly to effective Backlog Refinement.
What Exactly Are We Doing When We Refine the Product Backlog?
The goal of backlog refinement is three-fold:
- ensure that the Product Backlog is properly sized (if you DO sizing/estimation, that is),
- ensure that the top of the Product Backlog is all very small items in time for Sprint Planning by breaking large items into smaller functional slices, and
- ensure that any backlog items that need special attention (long lead time or specialized skills) are identified early.
When Should My Team Do Backlog Refinement?
The scheduling of Backlog Refinement workshops is at the discretion of the Scrum team. Scrum does not define exactly when refinement should be done. In general, refinement should take no more than two to three hours per week and can be scheduled as one meeting a Sprint (for a one or two week Sprint) or once or twice a week. Most teams need more refinement time when starting on a new Product Backlog and then less and less as they get more experienced.
How Do We Do Backlog Grooming?
To groom (or refine) your Product Backlog, you will want to focus on the very top (highest priority) items on the backlog. For the purposes of grooming, the "top" of the Product Backlog is the amount of work that the Scrum team could likely complete in between one and a half Sprints and two Sprints of work. For every item in the "top" of the Product Backlog, your team will need to:
- Understand the Product Backlog Item (PBI) by discussing it with the Product Owner.
- Determine if the PBI is too big to safely fit in a Sprint (this usually involves estimation)
- If the PBI is too big, slice it into smaller functional pieces (new PBIs). Avoid solving and tasking
- For each child, go back to step 2.
- Continue until the entire "top" of the Product Backlog is small and ready for Sprint Planning