Scrum Process | Scrum Problems | Scrum Detail | Scrum Challenges

September 2014
M T W T F S S
« Feb    
1234567
891011121314
15161718192021
22232425262728
2930  

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.

Product Backlog Grooming – Removing team suggested features

One of the primary items in the Product Backlog Grooming is about having a process whereby the Product Owner and the Scrum team can get together on a regular basis for discussing the items in the Product Backlog and do some of the following:
- Removes items that don’t seem relevant
- Refines items based on outside information such as changed technical circumstances or industry developments
- Proposed technical exploration for items that are technically complex
- Looks for estimation of those tasks where the estimation can be difficult, so that such estimates are accurate when presented in the Sprint Planning meeting
All of these promise to make a much smoother Sprint Planning meeting, but there are several problems that are also apparent in such a process, or atleast there are concerns that need to be handled.

A number of these relate to a feeling where the contributors to the Product Backlog feel stifled. There can be a number of contributors to the Product Backlog, with some of them being the Product Owner, features from competitor analysis, contribution from the team members (who have had a lot of experience with the product and the customers workflow). The problem is also increased because a number of the features that come in from the team members may not be large features, but are more improvements that could make the product more efficient, or remove some shortcomings, and so on. Many of such improvements can do a lot for the product in terms of optimizing it for customer workflows, making it faster, and so on.

However, a number of such features are not really significant when you look in terms of attractiveness of rich features. After all, when you can have bright shiny new features, what is the attractiveness of feature improvements, and hence the possibility of such features not being taken is low. After all, as a matter of reality, there are limited resources available in every Sprint, and there is a lot of work to be done; further, when you look at a product in terms of internal and external stakeholders, a lot of focus is in terms of the new features that are getting added to the product.

Now, if this happens again and again, then you will find that the contributors from the team will slowly start getting disillusioned. After all, when people see that their features are not so well appreciated and are not included into the product not because there was something wrong with them, but because they are not so shiny or are related to product improvement rather than new features. There is a need to have innovation within the product team, because the team can generate a number of improvements and if this dies down because the team feels that their features are getting rejected during the Product Backlog Grooming, then it is not a desirable state of affairs. There needs to be more careful attention paid to this by the Product Owner.

Advantage of Product Backlog Grooming – gets the team to start thinking

The Product Backlog Grooming is not a process that every team goes through, and I believe that even with teams that do it, the level of detail that they follow differs from team to team. But what exactly is a Product Backlog Grooming ? Well, the Backlog Grooming is a process whereby, before the actual Sprint in which a few specific User Stories need to be taken up, the more complicated / complex of these User stories are taken up for discussions before the actual Sprint. In this way, the team and the Product Owner get into a more detailed, mutually acceptable discussion of the scope of these User Stories, and additional complexities such as technical complexity and estimates can be obtained during these discussions. However, in many times there are challenges with having such meetings, and this could be because many of the team members feel that any refinement of the User Story falls into the responsibility of the Product Owner, and so on. There is a need for defining some of the advantages that can accrue to the team because of doing this Backlog Grooming. One of the primary advantages is that it causes the team to start thinking about the User Stories.
Consider the overall scenario; the team implements Scrum and has a number of User Stories that it wants to take up for the next Sprint. Some of these could be more complex and not easy to understand (or rather takes time to understand); and if the team hears about such User Stories during the Sprint planning session, preparing tasks and estimates for these User Stories can be difficult and the estimates for these can turn out to be inaccurate. However, such processes need to happen and there are improvements that happen out of such processes.
One of the more crucial benefits of the backlog grooming meeting is that it encourages people to start thinking about the User Stories that will be present in the next or more Sprints, and start to evaluate these Scripts. Suppose that the Product Owner started explaining a more complex User Story, and was immediately presented with a barrage of questions, some of which provide inputs to the Product Owner itself. But with such queries coming up and some sort of answer, it also meant that a number of team members have been thinking about these User Stories and also some amount of detail for them. For example, you could have a complicated User Story which would be a problem during the Sprint Planning, but ensuring that it gets discussed during a Backlog Grooming meeting ensures that atleast some of the team members would have thought more of the problem and this in turn could ensure that the final tasks may see some modification based on their feedback, and there might be improvements in the workflow or the benefits to the end customers based on this discussion.

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.