In the previous post (Product Backlog grooming and objectives), we talked about some objectives that are sought to be attained as a part of the Product Backlog Grooming session. We talked about what the Product grooming session can achieve, and covered items such as updating the Product Backlog to remove older or defunct content, as well as doing a lot of work on User stories. One question that I get from time to time is why do a separate Product Backlog meeting ? Why not just combine this with the Sprint Planning meeting where there is a lot of work related to taking User Stories and doing estimation and scheduling of such tasks. Well, there are some fundamental differences between these approaches ?
– During the Sprint Planning meeting, the Product Owner takes a look at the Product Backlog items that have been prioritized for the current Sprint and explains those to the team.
– The assumption is that these items are ready and the team can start work on these items in the Backlog, the User Stories have been written and ready, and so on. However, this assumption misses the fact that getting the User Stories ready in a form that the team can start breaking down into tasks and estimating those can only happen through a separate process (the fact that the Scrum theory does not cover such a process / meeting leads to a lot of confusion though), which is mapped to the Product Backlog grooming process.
What I would like to state instead is that the Product Backlog grooming meeting is a method to ensure that the Sprint Planning meeting happens in a more effective and time-efficient way; in fact the Grooming meeting could be seen as a precursor to the Sprint planning meeting. The end result of a Product Backlog grooming meeting is a Backlog which is highly optimized, where the User Stories have been reviewed (including the team) and so can be thought of being in a final form. Once you are in such a condition, the Sprint Planning meeting does not result in a situation where the team is not clear of what the Product Owner is expecting from the User Stories and a lot of time is just spent in questions and answers regarding the User Stories, extending the duration of the first half of the Sprint Planning meeting and making them much longer. Further, when the team asks queries that the Product Owner may not have thought of before-hand, it can become more tricky since now the Product Owner has to either come up with an answer on the fly (as the term goes, “just wing it”) or defer the query for later, which is a very odd thing to do during a Sprint Planning meeting. Such an approach results in a situation where the estimates that the team provides for the tasks are much more accurate, since the team has had time to think about the User Stories and maybe had even provided some initial estimates during the Product Backlog grooming session. Such an approach also ensures that the team feels that the meeting moves at a rapid pace, and if this is explained well enough, the team will see enough of a difference between the Product Backlog Grooming meeting and the Sprint Planning meeting so that they understand that there is a need to for a separate Product Backlog grooming meeting. In fact, once they see how this 2 step approach results in faster meetings and less uncertainty, they will also become advocates of having a separate Product Backlog Grooming meeting before the Sprint Planning meeting.
Read more about the level of refinement in the Product Backlog Grooming session (Level of detail in Product Backlog Grooming)