Categories

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.

Is the same amount of time required for Product Backlog Grooming across Sprints ?

So far, in previous posts, we have talked about Product Backlog Grooming primarily being used for preparing and optimizing User Stories for the upcoming Sprint. Of course, in addition, it is also used for refining the overall Product Backlog, weeding out those where it is clear that they will not make it into the product, and doing similar activities for optimizing the Product Backlog. As a result, the Product Backlog Grooming session covers both the work for the next Sprint, and also optimizing the overall Backlog. However, a lot of literature and articles focus primarily on the part where the Backlog Grooming is meant to take User Stories for the next Sprint, and get into some more detail for these Stories, whether this be resolving some functional or technical complexity, ensuring that team and Product Owner have the same understanding of the functionality, and ensuring that the Sprint Planning meeting is much smoother.
All this would lead us to believe that the duration of the Backlog Grooming session would remain the same across Sprints, and yet, when we talk to teams that are using Backlog Grooming, we find that the amount of time spent on Backlog Grooming reduces as the schedule advances and more Sprints happen. The reasons for those are manifold, with some of them being:
– As the schedule advances, some of the more complex features would already have been discussed, and as a result, these discussions across Sprints would have helped in clarifying most of the functional or technical doubts / challenges, and even if there are some remaining, it can be sure that the number of these would have reduced. Further, we typically find that when there are features with some being more complex than the others, features that are more complex (and also important) are taken up in earlier Sprints and not left for later Sprints. There will still be the odd complex feature for future Sprints, but this will be a rarity.
– There will also be a greater degree of congruence between the team and the Product Owner as Sprints go by. Initially, if the Product Owner is new, or there are new members in the team, it can take some time to develop a working relationship, but as time goes by, the level of understanding of each other also increases and as a result, the amount of time spent in discussion during the Grooming meetings also gets reduced.
– During the initial rounds of Sprints, additional requirements from different sources get added to the Product Backlog, and most of the addition of these new features happen during the first 1/3rd to 1/2 of the schedule, and in the later sprints, there are far fewer newer features / User stories added to the Product Backlog, and hence less time is spent in the Backlog Grooming session on these.

All of these however should not mean that the Grooming meetings should be treated less seriously. Even if the need for longer meetings is reduced, it is still important that the team spend the required amount of time on grooming the Backlog as well as ensuring that discussion for oncoming User stories happens as required.

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>