Sprint Planning
Sprint Planning is the first of the Scrum Events within the Sprint, the one where the team agrees the goal for the Sprint and makes an initial plan as to how they are going to achieve their goal. Sprint Planning really sets the tone for the Sprint, if it doesn’t go well; it’s likely the rest of the Sprint is not going to go that well. The Scrum guide now refers to events, some people call them meetings or even ceremonies (which they certainly are not), however I think a better metaphor for planning is a workshop. It’s the teams workshop for how it’s going to achieve its goals for the next Sprint. Think of the team on their feet sharing ideas as they sketch out designs on a whiteboard.
Start with What
However before the team starts diving into the how, make sure everybody is clear about the what. It is the last chance to refine any late breaking product backlog items that are candidate for the Sprint, and make sure the order makes sense. Through conversations between the team and the Product Owner a goal emerges and is refined. A ScrumMaster may be asking questions like:
- How realistic is the goal for this Sprint?
- How will we know when we have achieved it?
- What is the benefit of doing this for our customers?
Team Workshop – How will we do that?
Once the what is clear, the team get to work planning, designing, questioning, challenging each other to decide how they are going to achieve their goal. The Product Owner has probably opened their laptop at this point, they are available for questions, but they are rarely needed (or wanted) in the how conversation.
How teams do this part will look very different, it’s something that will change overtime as they grow in confidence and competence as a team. Be very careful of people who tell you, that Sprint Planning has to be done in a certain way, beware people saying things like:
- Product Backlog Items must be broken into tasks – some do/some don’t, this is a team decision based on what helps them plan and focus during the Sprint.
- Tasks must be estimated in time – I have seen teams do this in the past to help them decide how much work to take on. This is rare these days as the side affects can be nasty, as some will focus on meeting the estimate rather than what’s best for the Product.
- You need to commit to a number of Backlog Items – commitment is an important value in Scrum, but here it is about commitment to each other in pursuit of the goal. The Sprint Backlog is just a forecast of what the team believes it will need to do to achieve its goal.
ScrumMaster Tips
So what are some of the common challenges of Sprint Planning and how might a ScrumMaster deal with them?
Challenge |
Possible Approach |
| Lack of energy in the team or the team aren’t taking ownership | Do as little as possible and get the team doing the work. Think of it as facilitating from the back of the room. Get the team drawing, writing, talking and listening to each other.Get them on their feet; get them moving (even when distributed).
Only touch the pen, the sticky notes or the keyboard to hand them to the team. |
| Things aren’t being said; there is a lack of trust. The environment is not safe. | If somebody is in the workshop that is not in the team, you may have to ask him or her to leave.If it is within the team it may be time for an intervention. This could be as simple as asking what is not being said? It may be worth doing some team activities to build trust or some team chartering activities, before continuing. |
| The team doesn’t challenge each other; they go with the first idea. | This is where initially you may need to step in and challenge them, by asking questions. Are their any other options that may be better? What else could we do? Rather than allowing whole team discussions, break the team down into smaller groups for a few minutes to come up with options, to ensure there is some divergent thinking. |
| The team never shut up, they talk over each other and go around in circles. | Try silent writing or drawing, so that everybody can arrange their own thoughts and put them on paper. Then allow everyone time to talk through their notes individually. |
| The team never gets anywhere near their goal, so there is no sense of shared commitment to each other. | Challenge again, ask What would stop us achieving the goal? What are the risks? On a scale of 1 to 10 how likely are we to do this? What would need to happen to increase it from 6 to an 8? |
As a ScrumMaster you own the process of Sprint Planning, helping the development team get the value out of the workshop as painlessly as possible. If the team don’t have to worry about the process, the next step is to get them engaged in the work, using all of your facilitation know how, but make sure you are not over facilitating and getting in their way. You also focus on creating an environment of trust and ownership for the work, again the more the team do the more likely they are to own it. However if they are paying lip service to that ownership you should be prepared to challenge them.
As a Product Owner you focus the team on the goal, it that way all the details of the Sprint do not have to be decided in Sprint Planning, this helps keep it short and focused. Read about this from a Product Owners perspective.
Learn more about the Scrum Values, Roles and Events as part of our Scrum Fundamentals series, and download a pdf of the Scrum Guide.
