Last time, you read about how Tasks work. So, as already announced, it’s time for the last four rules.
The Sprint Backlog belongs solely to the Developers.
The Developers are committing to the work taken into the Sprint based on their capacity. The Sprint Backlog is an array of User Stories that defines the Sprint Goal and is based on which Product Increment will be built. The Developers prioritize the Sprint Backlog based on their best knowledge to be able to build the Product Increment, so nobody should touch it.
If all User Stories deemed Ready are exhausted, the Scrum Team can run a Backlog Refinement within the Planning time-box and include newly refined User Stories into the Sprint Backlog based on their rank in the Product Backlog, starting from the top. Backlog Refinement can be stopped when there are enough User Stories that meet the Ready criteria prepared for the Sprint.
Not sure what Ready means? Have a look at this article. What we want to express by this point is that if you pull all Ready User Stories into the Sprint, but the Development team still has capacity to take more, you can run a Backlog Refinement to refine the User Stories that are not yet Ready to be pulled into the Sprint. This might be tricky for two reasons:
- We want to shorten the Plannings as much as we can (as already mentioned in this article), and we run Backlog Refinements out of the Plannings. So, ideally, we try to avoid Backlog Refinement during the Planning session.
- Do not forget that all the User Stories pulled into the Sprint should go hand in hand with the Sprint Goal.
You can read more about this in the article dedicated to the Planning Agenda.
The Product Owner can freely refine and rearrange User Stories in the Product Backlog in reaction to gained insights.
The Product Owner is responsible for reacting to the needs of the Stakeholders and product. They should communicate all changes to the team. But they also need to react to the insights from the team and communicate possible priority changes in the Backlog to the Stakeholders.
The event can last a maximum of 4 hours.
Timeboxing keeps the team focused on accomplishing the planning task. If we do not manage to plan the Sprint within the time box, it means that the work is not clear—we need to prepare the Product Backlog better or the team is not focused on Planning. And that is something that we as a Scrum team need to address and improve.
There we are! Planning Rules are over, but it does not mean we have nothing more to say about Perfect Planning. There are many more exciting topics to come!