Product Backlog Grooming is a way to ensure that the team spends the required time (the team means the Scrum team along with the Product Owner and the Scrum Master) on preparing, reviewing and refining the User Stories. It is the common perception that the User Stories are prepared by the Product Owner, and that is mostly true, but there are a number of cases where the team can provide a lot of inputs to the User Stories prepared by the Product Owner (and in some cases, because of their extensive knowledge of the product, the team can even help in the refinement of the User stories). These sessions also help in ensuring that the team has had a chance to review the User Stories and have a greater understanding of the User Story when they approach the Sprint Planning session. This helps in ensuring that the Sprint Planning session goes off smoothly, less chances for the Product Owner to trip when somebody asks a difficult question, and the estimation tends to be more accurate. This then begs a question. If all this is so positive, why this post about some problems that may crop up. Well, there can be certain problems that crop up:
– First and foremost, the unpredictable nature of the Scrum features can trip up matters. When you define User Stories in the Product Backlog Grooming session for the following Sprint (could be more than one Sprint), then you risk the fact that those User Stories may not end up getting used in the following Sprints. Sudden changes may happen to the business environment because of which other User Stories may pop up, and the team would not really like the time spent in preparing for these User stories which are not going to be taken up. This point should be read along with the next point.
– The team may be uncomfortable with the amount of time that they are spending on these Backlog grooming sessions and may see this is as primarily a Product Owner task rather than something that the team needs to be involved with. In addition, this becomes yet another meeting for them to attend, and there can be resistance to it from the concept of being yet another meeting. Further, since these sessions happen during a regular Sprint, there is no tasks that can be produced out of these sessions (unless the team had already allocated time for these Grooming sessions in the list of tasks for the Sprint).
– Certain Product Owners may have resistance to the team suggesting changes. Prickly egos can cause problems, which is why all such processes (and the level of detail to be followed) depend on team to team, and these need to be discussed by the team and then followed rather than somebody asking for them to be implemented. It can happen that the Product Owner may end up feeling that the team is suggesting too many changes to the User stories or the detailed implementation / workflow details of these User Stories and start pushing back in a manner that causes friction within the team. This can also happen in the situation where the team starts taking a proprietorial interest in the product and feel that they know everything about the product.
These are some of the primary problems that can happen with the Backlog Grooming sessions. They need not happen with every such session, and there could be other problems with the Backlog Grooming session. What solution ? Well, as you would expect, it is hard to point out a clear solution – you need the team to be mostly convinced about all this, and ways to do that include getting this running for a couple of Sprints to see the advantages of the Backlog Grooming sessions happening, and also laying out the whole workflow of the Backlog Grooming Session -> Sprint Planning session, and getting the team to discuss this (if required, along with the Product Owner).
