Scrum Process | Scrum Problems | Scrum Detail | Scrum Challenges

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

Work started on a story, but constraints pop-up during the work ?

This can happen fairly easily. You would think that you have planned tasks to a great degree during initial planning of these tasks, and work has started; but it is a bit impractical to think that for all tasks, the task will go fully as expected. You would come across a situation once in a while where there are new constraints that are discovered during the ongoing task, these constraints needing additional work. In other cases, the constraints were such that they needed time to resolve, before actual work could happen on resolving these constraints. In most of these cases where constraints do show up, they will involve some amount of delay in the task, and this has a ripple effect on the other tasks that were planned for the ongoing Sprint.
So, it might seem that such constraints do cause problems to the team, but does that mean you avoid asking about such constraints ? Of course not. Even if you try to avoid a constraint, it will show up during the task at some point or the other, and cause problems. The best way to handle this is to encourage the team to raise any constraints during the Daily Scrum meeting, and then to handle these constraints as and when they were raised. There could be reasons why these constraints pop up during the Daily Scrum meeting – it could be because there were constraints that were skipped during the planning process, or there was dissonance between the way that the Product Owner conceptualized the task and the way that the team thought about it, or the most frustrating reason – there will sometimes be constraints that do not show up during the planning phase (it would be foolhardy and maybe arrogant for teams to think that they will be able to visualize all possible problems during the initial planning phase).
So how do we handle such constraints as and when they rise up during the actual working on the task:
– It is critical to define whether this constraint that has popped up is something which can affect the task or is something that can be avoided. This is true even when it seems initially that the constraint will affect the task, but it might turn out that some amount of thinking on this constraint could figure out a way to avoid it or bypass it.
– Once a constraint is decided that it is needed for work to happen, the development team would need to start working through the constraint to figure out the design, the execution process and the impact this can have on the task.
– At the same time, there needs to be a discussion between the team and the Product Owner about the prioritization of this constraint, and the impact on the task. It might actually turn out that the impact of the constraint on the task is high enough that the PO has to decide whether the task is threatened. For example, it might turn out that the schedule of the task is affected in such a way that other tasks in the Sprint are affected, and if other tasks are more important, the current task might need to be either postponed, or it might need to be split for some parts to happen in the current Sprint and some for a future Sprint.
However, as you work on these constraints, it is important to figure out whether this constraint could have been predicted, but need to be careful that you don’t end up beating up the team for not being able to predict this constraint.

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.