What do I blog about?
Error: Twitter did not respond. Please wait a few minutes and refresh this page.
somethings are just inevitable …
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.
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 :).
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.
All above links as well as…