What and Why?
Backlog grooming refers to the maintenance of the backlog. In an earlier post I mentioned that the backlog is emergent and can be compared to an iceberg.
In order to keep moving items up from the depths of unknown large epics to the small user stories completed in sprints, we need to perform this maintenance often. This also allows the team to become more familiar with items on the backlog and allows greater input as to whether everything has been covered. Lastly, the team should be able to estimate effort more accurately as they have a greater understanding of the stories.
Grooming the product backlog with the greater team starts the conversation. It is there to prevent the dreaded, never completed properly ‘hand-over’, and address miscommunication and misalignment. The team helps word the requirements and thus there is more buy-in and ownership of the work.
Most teams prefer having these meetings in the second half of the sprint – but not on the last day or two. They should take up roughly 5-10% of your sprint time.
Yes – it is work!
Usually teams and PO’s new to agile are not thrilled at the idea of a meeting to talk about things that they are not actively busy with. This is work – it happens to ensure that when the next sprint starts there is no confusion. A nice analogy is one of a race car making a pit stop. Its a brief break to ensure that that you can continue going at full speed :).
Breaking up the grooming
Here is a suggestion for how to break up the grooming meeting to minimise interruptions.
The PO should first roughly prioritise backlog items
The PO should meet with various stakeholders (analyst, architect, senior developers) to chat about and break down these items a bit more. Prioritisation might change as well. These should be “ready” user stories.
With the entire team present, the PO should go through the stories prepped above with the team. Questions should be asked and answered. Acceptance criteria should be noted. Some stories might need to be split up and again, prioritisation might change. If there are questions or checks that team/PO needs to make before estimating for the next sprint, they should do that before the next session (where they need to estimate).
Many teams combine steps 3 and 4 to happen together, I have found that having the estimation session the next day, gives time for answers and checks to be done, and for the PO to re-prioritise and possibly break down stories. The team should now be able to estimate. Aim to have enough stories estimated for 1.5 sprints.
Signs that you need to spend more time grooming:
- Ill-defined product backlog items
- No product backlog items
- Not-Done product backlog items within a sprint
- Insufficient infrastructure
- Difficulty forecasting when a project will be completed
- Large number of un-estimated Stories
- Planning meetings that are several days long and full of confrontation
- Ask various team member to explain backlog items – are they on the right page?
- Does the team select items and then only find out that some “pre” work needs to be done?
- Does the team do any checking before sprint planning to see if there are dragons lurking?
- Mid-Sprint – is the team overwhelmed by what they’ve committed to?
Techniques to assist with grooming:
More info here..
All above links as well as…