The title of this post is a bit broad and could be thought to be confusing. So let me clarify this a bit. People who use Scrum as their development model know a lot about user stories capturing their requirements, but when you get into more detail about how to define user stories, the way that different teams provide details vary tremendously. There are some teams that opt for clear and concise user stories, short and to the point; there are other teams that provide some voluminous details to the user stories, these being quite wordy. Some would think that these stories are overkill, and such details are not required. I am not getting into this debate directly, somewhat in a more oblique way.
My belief is that the User Story should provide details of what is needed to be done, and teams need to take the call about why the User Story needs to be done in a specific way. For example, the Product Manager could come out with a specific requirement that a piece of functionality needs to be using a specific third-party component. So it could be: As a user, I would like my the Zip Code validation to be done in the second screen shown to the user, using component. Now, you would not expect the Product Owner to define a specific component to be used, since that is more in the technical realm.
If you were to proceed a few months down the line, with some attrition happening in the team (or the Product Owner getting busy), the Scrum team members who were working on the User Story as part of their Scrum tasks for the month might not be clear about why this specific component was to be used. They know that other teams already use an existing component, which has slightly better functionality or is faster, and it might make more sense to disregard that part from the Product Owner about the specific component to use. However, there is a specific point that was not known to the engineer who was working on this User Story. The organization was going to strike a deal with the makers of the third-party component which would drastically lower the price of the component, which was the reason that the Product Owner had specified this earlier.
If this detail was captured in some way during the creation of the User story (say by adding a small point, or small detail) in the tool capturing the User stories, it would present clear details to the Scrum team worker that it is not negotiable to take some other component even if it is slightly better, and there would not be any confusion about this. At the minimum, the engineer could re-confirm with the Product Owner regarding the component to use, since the engineer would have understood the need about using this component specifically.
This gets even more problematic when rotation of team members off the team or attrition means that the person who had initially discussed this with the Product Owner is no longer responsible for this User story, and there would be some confusion on behalf of the new engineer in terms of actually doing the work on this User story. It is not just in the case of components where this is valid, it would be valid in numerous other situations as well; and it is for individual teams to decide about the amount of details they add in the User story.
It has been the experience of many teams that the process of writing User Stories is mostly a one-person effort, or rather, a one-role effort. The Product Owner is the one who is expected to write the User Story (or rather, all the User Stories). If there are multiple Product Owners, then they would be expected to distribute the User Stories between them and deliver the same to the team. This has been the expectation of many teams as well – my discussion with many team members is that they expect that the Product Owner will have the entire responsibility of the User Stories. Talking about sharing the responsibility of the User Stories between the Product Owner and the Scrum team does not really draw any enthusiasm within the team. The common feedback from the team is that they do the implementation work, while the work of defining the requirements needs to be done by the Product Owner.
However, it is important that this be something that is discussed well within the team and with the Product Owner, since the User story is a critical document that forms the basis for all further work done by the team. It cannot be just a document made solely by the Product Owner. Instead, the document should be the outcome of discussions between the Product Owner and the team; these need to happen at a regular basis. A draft of the User Story can form the basis for this discussion, and as and when the discussion happens, the User story can be revised to incorporate the outcome of these discussions. The team needs to be an active participant in this activity, and with their previous experience about the details of the product and technical knowledge of feasibility, it is critical that the team works to help refine the User Story (for example, defining the workflow of a feature may be far easier one way rather than the other).
What is the advantage of doing something like this ? For one, it ensures that the User Story is something that is more realistic about what is possible and what is not feasible (else, it could be something like the team not sure about the User Story that is delivered by the Product Owner, which has its own cost). Further, making sure that the team is involved in such a way ensures that the team gets a sense of shared responsibility of the User Story, which increases their sense of overall responsibility for the Scrum effort; something that in most cases helps the chance of overall success of the Scrum project. (This sense of responsibility is of critical importance, with teams doing this as a formality not really reaping the advantages of the team that really feel responsible for the project).
At the same time, this is not easy to do. Teams will feel that additional responsibility is being dumped on them, and it needs an intensive discussion to ensure that the message has sunk home and is understood. One cannot force this on the team.
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.
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.