In the previous post (More objectives for Product Backlog Grooming), I wrote about some of the objectives that can be achieved through a Product Backlog Grooming process, especially about ensuring that it happens before the Sprint Planning meeting. This is required so that the hard work of ensuring that User Stories are at the required level of detail during the Sprint Planning session has happened; and the confusion of the team about some of the details of these User Stories is also minimized. This ensures that the Sprint Planning session happens at full efficiency, and the team remains enthused about the combination of the Product Backlog grooming and the Sprint Planning sessions. But for that to happen, there is a sort of criteria that you should seek out for the Product Backlog grooming session to ensure that the User stories are in a fine form before the Sprint Planning session:
– Now, the level of detail that should be attained in the Product Backlog Grooming depends on the team. There can be teams that use the Product Backlog Grooming session to reach a high level of detail for the User Stories while there are others who would just prefer that the User stories have been reviewed by the team and high level issues resolved. What exactly to do depends on the team dynamics and team decision, and it is also possible that the team goes through a couple of such rounds of discussion and then changes the level of detail that they want to achieve. I want to take a look at the case where the team wants to reach a position where the User stories have been reviewed and refined, and even estimated. What should the team reasonably hope to achieve in such a situation ?
– When the Product Backlog Grooming is happening before the Sprint Planning session in order to ensure that User Stories are ready, then the Grooming session should not be seen as complete till enough User Stories have been completed; and what do we mean by enough ? Well, again this varies a bit, but a good estimate is if the next Sprint can cover around 10 User stories, then the Product Backlog Grooming should have done enough to prepare 12-13 User Stories for the next Sprint. Why more ? Well, have you seen that once in a while a User Story may still be taken as it is; after all, there could be technical or other reasons which would ensure that a User Story may have been reviewed in the Grooming session but not taken up during the sprint planning session. Further, in the event that the team is ahead of its estimates, you might reach a situation where there is bandwidth to take on more User Stories in the Sprint.
– When the User Stories are being reviewed and some rough estimation done during the Grooming session, there is a natural tendency to spend a lot of time discussing the technical and functional issues during such a meeting. This is not the objective. The actual functional and technical working out of the tasks needs to happen during the Sprint when actual execution happens, not during the Product Backlog Grooming. What the team can try to do during the Product Backlog grooming session is reach a point where the User Stories have been reviewed to the point where there are no serious confusions or queries on the issue, and the team is comfortable with the estimates that they have provided.
If the team reaches such a level, then they are all ready to move into the Sprint Planning without re-spending time on these User Stories and ensuring that they are able to do the breakdown into tasks and estimation fairly quickly and accurately.