In the previous post on the topic of Product Backlog grooming (link), I had talked about what a Product Backlog grooming session is, and presented some details on that. I will provide more details on the Product Backlog grooming in this post, although some of the items in here would be providing more details of what was talked about in the previous post. So, let us talk about the structure of the Product Backlog, and consider that the next couple of posts will provide more details of what the inputs are for the Product Backlog grooming process, what is the process of the meeting and ensuring that it works effectively, and what are some of the problems that need to be avoided for this meeting to be effective, as well as proposed schedule times for such a meeting. So here goes:
– When somebody from higher management asks about what the Product Backlog grooming meeting is for, an effective answer is that such meeting are part of the process to ensure that the Product Backlog remains optimized and current
– One should have a lot of clarity about what the goals of the Product Backlog grooming session are. These can vary from team to team, but here are some possible options:
1. One of the bigger problems that people quote about Scrum is that everything works on a Sprint to Sprint cycle, and where is the planning for several months ahead ? Well, as a part of the Product Backlog grooming, one of the objectives is to review the various stories in the Backlog to determine the order of which features need to be done in which Sprint from a technical perspective. This ensures that you build up the application from a technical perspective, so that work which is of a building nature is done early, and work that is dependent on this early work happens later. This prioritization can of course be tweaked as you move ahead.
2. Actually define User Stories. A number of teams after a bit of training say that the Product Owner will write the User stories, but this simple statement of fact does not capture the details of this process easily enough, especially when you consider that members of the team can put in a lot of useful effort in terms of contributing to the User Story, and there is no other process that defines incorporating the team during the User story writing process.
3. A User Story, in some cases, can be something that is pretty large and was put together some time back. However, it is important for the team and the Product Owner to review the larger User Stories to determine whether they are too unwieldy for a single User Story and need to be split into multiple such User stories, and this process may need to be done again if it turns out that the scope of a particular User Story has to be increased because of some new business requirement.
4. A User Story needs to be well written for it to be broken down into tasks and estimated. However, it could be that when the User story was written, it was of a very brief or cursory nature, or there were mistakes in the User Story that could be pointed out and then discussed. And hence, the Product Backlog grooming provides a perfect example of a meeting where the team and the Product Owner can discuss such User stories (they could have been identified earlier though) and rewrite them to reflect the requirement more accurately.
5. Another work item that can be accomplished in the Product Backlog grooming meeting is to provide more details to the User Story. The Product Owner and the team could take some prioritized User stories and do some estimation of some of these User stories and make them more ready for later use by adding completion criteria (acceptance criteria).
I will add more about Product Backlog grooming in the next post in the series (Product Backlog grooming and Sprint Planning)