Sprint Planning is the first event of the sprint, where the development team prepares for the couple of weeks ahead. First, let's go through the basics of sprint planning in terms of the 6 key questions - who, what, where, when, why, and how. Then we’ll dive into some common issues and anti-patterns we’ve seen in the industry.
The Scrum Team attends, which includes the Product Owner, Scrum Master & Development Team. Subject matter experts who provide special insight to the upcoming PBIs may also attend on a case-by-case basis.
In Sprint Planning, the team forecasts the PBIs they plan to do during the upcoming sprint, and creates a plan to transform them into a working software increment. Tasks are often used to express that plan, but some teams may prefer acceptance tests, documents, or plain ol' bullet points. The team also creates a Sprint Goal, to give them focus, context, and purpose for the upcoming Sprint.
Ideally, someplace the team can be together. Remote Sprint Planning can be done, but the team may suffer from a loss of context and visual cues the same way they would during any remote meeting. Having a whiteboard (virtual if necessary) might be useful for more involved technical/design discussions.
The very beginning of every sprint. The team should always have it after the previous sprint's events, as priorities might change or new information arrives! The team can't begin work unless it knows what it's working on, right?
As with all scrum events, sprint planning is timeboxed - it can take up to, but not more than 4 hours for a 2-week sprint. For longer sprints, scale the timebox proportionally.
The goal of sprint planning is (surprise) to come up with a </p>plan for the upcoming sprint. A deeper goal of sprint planning would be to divide the work up into manageable pieces so that anyone on the team can grab a piece when it is ready to be worked on, and those pieces help the progress of a PBI to be visible and transparent. Sprint planning should also produce a sprint goal. The sprint goal gives the team focus, context, and purpose for their forecasted work. Instead of everyone running in different directions for each PBI, their thought, discussion, and work are oriented around a holistic view of the product, from the perspective of a user.
The development team should begin by selecting which PBIs they forecast to complete during the sprint. This can be a negotiation with the product owner, and may result in a change in priority e.g.: "Hey, these two PBI's are really similar, we'll get them done quicker if we work on them concurrently."
Once forecasting is complete, the development team begins to plan how they are going to complete that work. Tasks are often used to break down the PBIs into pieces of work that are less than a day each.
The last thing the team should do before finishing sprint planning is to write their sprint goal. This should be short and sweet, and encompass the work they plan to do during the sprint, giving the team context, focus, and purpose. It shouldn’t be a list of “complete these PBIs”... the sprint goal should knit the PBIs together. It should also be specific, a goal for the team to shoot for.
A bad example: "Build a shopping cart feature."
A better example: "Improve the purchasing process to allow better visibility and user experience."
All of this is easy, of course. Scrum is notorious for being simple with lots of subtle potholes. Here are some of the common gotchas we encounter while coaching and training teams:
Planning poker is not used to determine how things are done, it's an exercise used to estimate the effort of backlog items. This shouldn't be done in sprint planning, it should be handled during product backlog refinement, as knowing how big something is will help the product owner make long-term forecasts and prioritize things within the backlog. The exception to this is if your plan changed during sprint review and you've got something brand new on the backlog.
If you decide to use that field in your PBI's, and you have a reason to (someone is the "point of contact" for that PBI, for example), then go ahead. But remember, the team is responsible for the quality and completion of every PBI, not just the person it is assigned to. Moreover, allowing the team to unite around few PBIs at a time creates much more reliable progress through the sprint than "divide and conquer". Making assignment decisions at a management level reduces the team's ability to self-organize - see Erin's other post on this subject, "Why Exactly Do We Want Self-organizing Teams?" Consider leaving the field blank, and hold the entire team accountable instead of individuals.
The team selects how much work they can reasonably accomplish within the sprint. If they aren’t confident they can do more, they probably can’t do more, no matter what. Scrum, as an agile framework, values responding to change over following a plan. If your deadline can’t be achieved reasonably by your team, be prepared to alert concerned parties and consider alternative solutions.
Adding additional teams or people can help, but be warned that the churn of adding cooks to the kitchen might hurt as much as help in the short term (see Brook's Law). Better ideas might include negotiating scope changes, moving back the deadline, or addressing impediments the development team has identified.
The first thing to check is if you’re spending time debating what’s in scope, what is the intended functionality, or how large the PBI is - this suggests your team isn’t spending enough time doing product backlog refinement, which is used to gain an understanding ahead of time of what the PBIs are and how they big they are. When you get to sprint planning, the only things you want to have to worry about are: “How much can we forecast to accomplish?” and “How are we going to implement this?”.
If you aren’t doing any of those things, then remember that Sprint Planning is simply for developing a plan, a rough outline of how the team plans to accomplish the work. If you’re diving into very specific implementation details during Sprint Planning, take a step back, those things can always be discussed later.