All the articles dedicated to the To Do List have been published. The last one was about the Developer’s To Do List. So, it is finally time to kick off the section about the Planning rules in the ScrumOne process.
There are many rules, and all of them might seem to be clear and easy to understand on first sight. Nevertheless, we would like to explain why each rule has its own place within the Planning.
But before we start with the rules, we would like to show you that there is not only one planning mode.
With our previous Scrum version, the Moravia Flavour, we recognized only one planning mode derived from the Scrum guide. Our need to incorporate the requirements and requests of other teams lead us to include three more adjusted modes that help us satisfy those needs:
- Mode #1: Capacity Chosen
- Mode #2: Capacity Given
- Mode #3: Ad-hoc Planning
- Mode #4: The one we do not speak of
In this article, we will talk about the first mode, Capacity Chosen.
Mode #1: Capacity Chosen
This Planning mode is considered the standard approach derived from the Scrum guide. The Product Owner tends to the backlog and is in charge of prioritization. Developers are in charge of taking up User Stories.
Before the Planning itself, the Product Owner prepares the Product Backlog. It has to be organized, in order and ready.
By preparation, we mean collecting requests from stakeholders, clarifying them and putting them in order. For more on “how to put them in order”, you can read the article we published some time ago.
And, who chooses the items for the Sprint? Developers.
They choose the right amount to take into the next Sprint and are committed to do their best to develop the working increment by the end of the Sprint. Nobody, not even the Product Owner, can force Developers to take more items into the Sprint than they are willing to. And vice versa: nobody can limit them to take less items into the Sprint than they want.
If there are questions from the Developers, the Product Owner has to answer them. If we find out that User Stories should be reordered, it is up to the Product Owner to consider and reorder them. Developers can also negotiate switching the order of items in the Backlog with the Product Owner so they can take more items into the Sprint (for example, if they see that they will not be able to complete the next item estimated at 8 story points, but they will definitely be able to complete the next one estimated at 2 story points).
Different modes of Planning also mean different Burndown Charts. For this mode, it can look kind of like this:
This Burndown Chart shows a 14-day Sprint starting on Wednesday the first and ending on Tuesday the 14th two weeks later. For a better understanding, let’s say the team breaks down the User Stories into Tasks that total 100 hours.
The red line is the ideal burndown line and the blue line is showing the sum of the remaining work.
If the Burndown rises sharply, the Tasks hours have increased. If the blue line slumps, Tasks have been either done or canceled. The blue line is the one showing the real progress. If the blue line deviates too much from the ideal line, it is a heads up for the team and the Scrum Master that there is something happening that deserves attention—for example, there is a problem with the implementation of the item, the team got stuck or there are more Tasks to do to successfully complete an item, so the work is not progressing as expected. There can be a million reasons. And it is up to the Scrum Master to point them out.
You will see next time how the Burndown Chart evolves when there is a different Planning mode.
(More about the Burndown Chart, how it is made and what we use it for can be found in this article.)
As it was said before, the Product Owner cannot force Developers to take less items into the Sprint than they want. If that happens, we are no longer talking about this Planning mode, but about Planning in which the Product Owner sets the top limit for Developer team capacity, and that is Mode #2.
To be continued…