Grooming 3 Sprints Ahead

Items on the backlog is often too large and/or too fuzzy. The process called "Grooming" is about the team helping the Product Owner to clarify and divide such items into doable User Stories, so that there won't be a lack of them in the sprint planning sessions.

But how do we do it? First of all you should know that it depends on your situation. Are there many urgent large or fuzzy items? The team need to assign more resources into grooming. Are they very large? Groomers need to have an architect approach slicing them. Are they very fuzzy? Groomers need to act as business analysts, seeking out answers from the stakeholders in the business.

Now, situations like those, where stuff comes in bulk, should generally be avoided, since it is examples of Mura, creating waste in the organization. It is better to have a situation where the amount of ungroomed issues is predictable and handled smoothly.

This is achieved by not grooming much more than you plan to implement, and by grooming ahead. I will give you a practical example of how that can be accomplished, in a way that I have found effective in many organizations.

First: set aside a number of grooming sessions during the sprint where they will hurt as little as possible. One hour once a week could be good for starters, and schedule the sessions so that they won't interrupt things. This gives everybody a sense of predictability.

Second: during sprint planning you briefly look ahead at the items that will need to be groomed. Identify what kind of issues they are (maintenance, new development, component A or component B etc), so that the team can decide who is best suited to groom them. Normally, you put a cap on the grooming saying that no more than 10% of the team's capacity will go into grooming.

Third: at the grooming sessions you look at the issues in three blocks:

• Issues 3 sprints ahead: Product Owner explains the issues, and receives a lot of questions and criticism from the team. Until the next occasion, these are questions that the Product Owner need to find answers to, preferably in the form of a live stakeholder. This is about reducing fuzziness.
• Issues 2 sprints ahead: Product Owner has found out answers to all the open questions, so that the team can start dividing issues into doable User Stories. This is about reducing size.
• Issues doable in the next sprint planning: The team and the Product Owner knows what stories there are, and preferable there should be an early estimate so that the Product Owner can prioritize together with the stakeholders.

Either in that order, or the other way around.

The method presented above gives you a structure to the grooming process. It will need to be adapted so that it fits with your other cadences: Product Owner meetings with the stakeholders, sprint planning, etc.