The sprint planning meeting is one of the most important steps in a Scrum project. Let’s see what it consists of exactly through its objectives and its place in the project and its organization.
We will now see what sprint planning is. It is perhaps one of the most important meetings and not necessarily the easiest to integrate. Often, it takes several sprint plans to manage the animation and make it as effective as possible.
Understand the purpose of sprint planning
So to find your bearings, sprint planning in the Scrum process is used to plan the work to be done during the sprint. This is the objective of this meeting which will also serve to answer two important questions:
What can be done in this sprint?
How to transform the elements of the product backlog that we have selected into a completed increment?
The maximum duration of sprint planning is 8 hours for a 4-week sprint. This duration is proportionally lower if the duration of the sprint is shorter.
The role of the owner of the product in sprint planning
This planning meeting results in the creation of a sprint plan . It is the result of collaborative work by the entire Scrum team. Here, the Scrum master will have the role of ensuring three essential things:
- That the meeting is taking place.
- That it respects the objectives.
- That it responds well to the two questions mentioned above.
Through sprint planning, the scrum master also ensures that this meeting will help participants respect the time box. Then he must also check that each member of the team has understood the interest and the meaning of this meeting.
Selection of elements involved in the sprint
You have to be aware that the part of the product backlog that will be selected to be engaged in the sprint is frozen. There are only two situations in which we can return to these elements:
In case the development team is ahead and they will turn to the product owner to see what element they can take in the sprint before its end,
Or conversely, if the team is late, approach the product owner to see which elements can be removed by mutual agreement.
These situations are frequent, especially over such short durations. Thus, the slightest unexpected can affect the sprint. You should, therefore, be aware that this scenario can occur, all the more at the start of the project where the development team will find it more difficult to estimate its velocity. In other words the quantity of story point or the number of elements of the product backlog that it will be able to carry out in this sprint, before being able to transform them into potentially deliverable increments.
The elements of the product backlog not engaged in the sprint
The part of the product backlog that has not been engaged or selected in the sprint can constantly evolve. Contrary to what has been started and can no longer be changed in terms of scope. We will simply go into the detailed design of each element and then their realization or their test. But for all the rest of the product backlog, we can be led to:
- Change the user stories already present.
- Add elements to new ideas that we had on the way.
- Remove items.
All that can move and that is what constitutes all the flexibility that Scrum offers vis-à-vis the product owner, who will be able to adjust all the elements of the product backlog that have not yet been achieved.
That’s what sprint planning is all about. We will, of course, have the opportunity to deepen this subject since sprint planning is once again one of the most important meetings and not the easiest to master at the start.
