Sprint Planning Meeting (SPM) is one of the four meetings-ceremonies described in the Scrum Guide as an element of the framework. During SPM, tasks are selected from the top of the Product Backlog, which the Development Team will execute in the upcoming sprint. How can you improve the discussion? Here is how to do it!
“Sprint means sprint” and developers, just like athletes, need to start smoothly in order to achieve a good result. A Sprint Planning Meeting is the kick-off to the next 2 weeks of work – if we start it in a long-winded way and without specifics, it will be difficult for the team to pursue the tasks eagerly and enthusiastically. In order for an SPM to truly serve as a start-up meeting, it is important to set the pace from the very beginning and at least a few things must be kept in mind. The success of the sprint is also influenced by the commitment, motivation and atmosphere at the SPM – that is why it is essential to take care of each of these elements.
What practices should I use during the Sprint Planning Meetings with my teams?
Here is a checklist that will streamline your Sprint Planning Meeting:
#1 Watch the time:
Sprint Planning Meeting is a ceremony where a lot of people meet (development team, Product Owner, invited stakeholders), everyone has something to say, and certainly there will be at least two people among those who like to discuss an issue. If the conversation goes further, it is worth setting limits, for example, a maximum of 5 minutes for one task, after which we move on to the next one. You can return to the abandoned task at the end and decide whether it is ready to include in the sprint if it has raised so much discussion. Remember : “Keep it short.”
A Sprint Planning Meeting, as the name suggests, is a planning meeting, not a reviewing one like the backlog meeting, so tasks should be prepared in advance. There is no place here to think about new features (of course, there are special situations that require it, but if we leave new task analysis until the SPM, it is very likely that we will get ourselves into trouble of underestimating the tasks and subsequent wrangling with regard to the scope). At the SPM, we review the list of tasks in the Product Backlog that is ready, written and prioritised. If during the SPM there emerges an idea for another task, it should be entered at the end of the Backlog Product and its refinement should be planned.
During the SPM, it is worth using the Planning Poker (if we estimate in Story Points) or any other estimation technique, because it is the easiest way to expose either the lack of understanding of the scope of the task or the lack of an idea for solving it. If you see that the estimates of individual team members differ significantly from each another, that means either someone has a great idea to solve the task (the one with the lowest estimate), or one of the developers is not aware of the risks involved in the task (again the one with the lowest estimate).
The moderator of the meeting should keep in mind that if the tasks have been previously analysed and estimated, each task should be summarised again during the Sprint Planning Meeting to ensure that everyone understands it in the same way. If the team has a problem with summarising the task’s objective, that is a signal that the task needs clarification.
During the SPM, it is important to determine who, and in what manner, will accept the task and note this information on the task card/in the system, so that, in the following two weeks, there will be no doubt whom to establish details with. Alternatively, you can put down who has the most information about the task.
#6 Check availability of the members:
At the beginning of SPM, the availability of all members of the development team should be established and taken into account during the meeting. Availability also means that if people happen to take leave during the sprint, the mode of transferring information/tasks to another person must be planned. This will help avoid a situation when someone “had not finished the task and took leave” or continual postponing of those tasks until the next sprint.
#7 Split tasks:
Avoid assigning individual tasks to developers during the SPM – this weakens the self-organisation of the team. It is the team that decides who and when will deal with a specific task so as not to bite off more than they can chew.
#8 Focus on business value:
If the task seems to have little business value – the Sprint Planning Meeting is the last good moment to talk about it.
#9 Set the sprint goal:
During the SPM, the purpose of the sprint should be determined – setting it has a deep motivational dimension for the team. The purpose of the sprint is not to accomplish individual tasks, but to actively respond to a defined business need. If we set a clear goal for the sprint, even if one of the tasks is not completed, the team will still be able to talk about success against some higher value (individual tasks in the sprint can also change, so the sprint goal also makes the team feel responsible for some bigger piece, running above individual, assigned tasks). By agreeing on the sprint goal, the team also knows which tasks have the highest priority (those that actively support the goal).
#10 Think about WHEN?
During Planning, we do not set the order of tasks – i.e. Client, Product Owner, Stakeholders or Business must be aware that they cannot expect any tasks to be completed within 3 consecutive days – the only thing the team can provide is the implementation of tasks within the following two weeks (or any other previously accepted sprint length);
#11 Communicate clearly:
During the SMP, it is worth establishing, or confirming if it has already been established, how we communicate within tasks (whether through a comment in the system or through assigned tasks, and, if the arrangement are made by phone, where to record the agreements reached in this form for future reference).
#12 Specify responsibility:
At the end of a Sprint Planning Meeting, it is important for the team to confirm that “this is our sprint”, it works as confirmation of the relay baton handover from tasks to active system functions.
I encourage Product Owners to use time in the Sprint Planning Meeting for motivational purposes. It is at the SPM that the Product Manager communicates the vision of what should be achieved within the next two weeks. This is the final moment to present the benefits that the implementation of the tasks just selected for the sprint will bring.
#14 CHECK – check it out!
An SMP is a meeting that requires strong moderation, so I would like to give you a few questions that you may like to ask the participants (or yourself – in your head – to check if you are going in the right direction):
– Is the discussed issue likely to be implemented in the next two weeks? If not – let’s arrange another meeting.
– Does the discussed issue have an effect on the labour intensity of the task? If not – move the discussion to a later date.
– Does the discussed issue affect the decision to include the task in the sprint? If not, keep the discussion to a minimum.
– What do YOU think about it? This engages all participants in the meeting – silent people often do not keep silent without a reason, and if for no reason, it is worth talking to them about the sense of their participation in the SMP (in the end it is a long meeting, why be bored for so much time?).
– Will the tester know how to test it? Often, the acceptors/testers need additional information to be included in the task – this is the best time to talk about it.
A clear vision of the goal of the sprint shared by the Product Owner and the Team, the relevant pace of the meeting based on particulars and active participation of the team in the whole process are the foundations of a Good Sprint Planning Meeting. The above practices work quite well in my teams – so I encourage you to also try them in yours!
Scrum Master in Unity Group. She is passionate about broadly understood agile project management. She deeply believes that the values and principles of Agile and Scrum are the guarantees of achieving success in the rapidly changing IT environment. She evangelises in the Agile way also using methods of non-formal education – recently she co-created a simulation game that teaches newcomers to work Scrum. She loves working with teams and within teams, but in her spare time, she often resorts to more solitary activities – sewing and gardening.