A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum – Product Backlog Grooming – Level of detail and understanding ??

I have been receiving some queries on the previous posts on Product Backlog Grooming (including some by colleagues, who claimed that I might have caused them to become more confused :-), rather than less so). Some of the teams did not have any process comparable to Product Backlog Grooming, and when they read / heard about how some of the problems they were facing in the Sprint Planning session (hard queries, user stories being dropped because of wide gaps in understanding between the PO and the team, etc), they wondered whether the Product Backlog Grooming process might help them in this (they would still face problems, but the occurrence would get reduced). However, the level of clarity that a team tries to obtain for the User Stories as a part of the Backlog Grooming process is a bit hard to define and get right, and in the end, the team needs to iterate until it gets the right level of detail. However, I will submit one possible situation in this post.
This post will talk about ensuring that the team does not go overboard in trying to determine a high level of detail. One objective of the Product Backlog Grooming session is to refine some of the User Stories that are complex, or have technical challenges, or other such problems that will prevent them being detailed out quickly enough in the Sprint Planning session. If you have a User Story that is very complex technically, and when you have a time constrained situation such as the Sprint Planning meeting (you could have this meeting last for several hours, but where the technical complexity means some sort of prototyping or other such process needs to be done), any estimates during the Sprint Planning meeting could have a high degree of variance from the actual estimate. If this research was done earlier, as part of Product Backlog Grooming, the estimation task during the sprint planning could be much easier.
Consider another example, where a User Story is confusing for the team, or where the business case is not easy to understand (trying to explain some financial or accounting processes to an engineer can be a bit difficult sometimes). In such cases, you would not want the entire Sprint Planning session to be devoted to explaining this User story, instead, as a part of the Backlog grooming sessions, the team would have done an initial review of the User Story and then did a few rounds of review with the Product Owner till the concept and the business case was clear. It does not mean that the team reviewed the entire User story with the Product Owner to resolve everything; all that the team would have done in this specific case would be to ensure that the more difficult parts of the User story were discussed so that the team and the Product Owner had the same level of understanding. 100% understanding of the User story would still only happen during the course of the Sprint planning session rather than in the Backlog Grooming session. The idea being that the the Backlog Grooming session feeds into the Sprint Planing session rather than be a substitute for it.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>