Sprint Planning Meeting – The Basics
At the beginning of each sprint is a Sprint Planning Meeting (SPM).
Minor point: The SPM is inside the sprint time-box. It starts the sprint.
The Sprint has real meaning. Typically the Sprint is a time-box in which the Team will make significant progress in building a releasable product. Typically, it will take 2 or 10 sprints to build a releasable product. The work of the Sprint, the progress of the Sprint, will be ‘working product.’ To use Ken Schwaber’s phrase, it will be a potentially ship-able product increment.
The slightly newer wording is ‘working product.’ During the sprint some parts of the product will be built, tested, and ‘done’, as defined by a good ‘definition of done.’ This would include all bugs being fixed. Maybe better to say: all known bugs that relate to a specific story (features) built in the sprint must be fixed, if that story is to be considered done.
The whole Scrum Team and the business stakeholders come to the SPM. I imagine the whole team to be 7 people, and that includes the PO and SM. I imagine the Team has 4 people identified and assigned as ‘business stakeholders,’ by which we mean 4 people who will regularly come to the Sprint Planning Meeting and the Sprint Review, and give the Team independent feedback about the progress. These business stakeholders (BSHs) are chickens, not pigs, although they play an important role.
The SPM is said to have two parts:
(a) Agreeing on the Stories.
This is where the Team agrees to take on some stories that represent the velocity of the prior sprint (unless there is a compelling reason to believe the velocity in the prior sprint is not representative of the true velocity). We typically recommend that these stories be small enough, so that it takes 8+ small (roughly equal in size) stories to equal the velocity of the Team.
At the conclusion of this portion, the business stakeholders can leave. For a 2 week Sprint this would usually last less than 1 hour.
(b) Agreeing on the Tasks.
In this portion of the SPM, the Team identifies (volunteers for) tasks. The tasks need to be small. The recommendation is that they are 2-4 hours mostly. In any case, between 1-6 hours, because they need to be useful in tracking real progress each day (eg, in the Daily Scrum).
At first the team is terrible at breaking work into small pieces, but soon they learn.
I recommend that each task include a description, initials (of the person currently volunteering for and likely do the work), and an estimate (in hours, for beginning teams). NOTE: Any task can be re-assigned to a different person at any moment, if it makes sense. In general, people are volunteering for tasks; that is the attitude. And people expect tasks to be re-assigned whenever appropriate.
The Team should also look at the whole plan (the whole Sprint Backlog…stories and tasks) and improve it, as a Team. Anyone can propose improvements to anything. Reassigning tasks, balancing the workload, the hours are estimated too high or too low, tasks are missing, or not necessary. They all (the Team) are responsible for a good plan for the Sprint.
It bears repeating that the whole team is responsible for success. Not just in the Sprint, but overall. Saying ‘I did what I was told to do’ is not enough. Only real success is meaningful. The Team are self-managing, self-organizing and self-directing. It is not a ‘game’ (in the false sense), it is about winning together as a Team. In addition, it is about really satisfying the customers.
(c) The final part is ‘commitment’.
Well, in the recent Scrum Guide it is not called commitment.
Why? Because too many managers were thinking this means guarantee. And ‘forcing’ people to guarantee the future is silly. Evaluating whether they did a good job (in the past) is useful; but forcing people to work ‘all hours’ to ‘guarantee’ X amount of work is completed in the Sprint is foolish. Working extra hours does not help.
These managers are right in some respects. When the Team commits, they should be confident they will fulfill the plan. Usually that means being reliable 70-80% of the time. (You can argue what the range should be, and it varies depending on the type of work and the situation.) So, it is not a meaningless commitment. But it is also not a guarantee.
The team needs to learn how to become more reliable. For reliability, we are talking about reliable for one Sprint at a time. And only reliable to some degree (eg, 70-80%). And, they should also exceed their forecast about as often as under-shooting their forecast. So, longer term they are really quite reliable on average over X sprints.
(Note: The Team and especially the ScrumMaster are actively trying to increase the velocity.)
Now they have a good plan. Now they are well positioned to execute and to succeed.
By far I did not explain everything, but the above description gives some useful reminders.
What are some important things I left out?