Mode #2: Capacity Given
This is a modified approach to Planning in which the Product Owner sets the top (maximum) limit for Developers for Sprint capacity. This is so that the Product Owner can keep a buffer for flexible reorganization of what will be done in Sprint, usually because he or she expects something to be solved operatively. But, they should emphasize that reaching this limit should be an exceptional situation.
For example, if the team’s velocity is 20 story points and the Product Owner expects an ad hoc request that needs to be dealt with, the Product Owner can say that the maximum work they can take into the Sprint is 10 story points and leave the rest of the capacity for these ad hoc requests. If you are not familiar with story points, no worries, we will get to that later in another article.
But, instead of planning the amount of work based on story points, it is better to plan based on a natural divide in the Sprint such as a week. So, plan the amount of work to be done by the end of the work week, rather than by taking 10 story points instead of 20. Thinking in terms of weeks is much more natural and easy.
In other words, this mode helps teams manage unpredictable work that needs to be done within the current Sprint.
The new work accepted in the Sprint should be processed in the same way that the planned work is handled. After the initially planned work is finished, the team starts working on the ad hoc request that arrived during the Sprint.
If they finish it before the end of the Sprint, they can take items that are at the top of the prioritized Backlog.
The Product Owner has to explicitly state the reason for the limit and the Scrum Master will mark that Sprint as a Pull Sprint with a tag in our system so that it’s clearly visible that we use this mode of Planning. If the Product Owner puts a limit on Planning, they need to discuss the reasoning and impact with the Scrum team.
The Product Owner also has to take care of the backlog more often than just in Planning mode #1. They need to keep the Backlog in order almost constantly because the team will have to pull things into the Sprint before the Sprint ends. To effectively do that, the Backlog needs to be up to date and sorted by priority.
The Pull Sprint must be defined and mentioned in:
- the Sprint Planning, so that the Scrum team knows why this mode is being set and can plan accordingly),
- the Sprint Review, so that the Stakeholders know what is happening during the Sprint and why and can react if needed and
- the Sprint Retrospective, so that the Scrum Master can review the impact of using this mode of Planning on the Developers, whether this mode was effective and if there were any benefits of using it.
And last but not least, what do you think the Burndown chart looks like? Is there any difference compared to the first mode of Planning? Yes, there is.
Let’s take a situation in which the Product Owner at first sets the maximum hours in Tasks to 50, not 100, so that they only reserve half of the team’s capacity. The Burndown chart looks exactly the same as for the first mode of Planning. But, when the initial work is finished, there is still capacity in the Sprint, so another User Story is taken into the Sprint. After that one is finished, another one is taken, etc., until the end of the Sprint. That is why the Burndown chart goes up and down after the initial work is finished.
Curious about the third mode of Planning? No worries, we will come back with it in two weeks!