The Sprint Planning Meeting
The Sprint Planning Meeting takes place on the first day of the Sprint. It's purpose is two-fold:
- For the Scrum Team to build a reasonably complete functional understanding of the backlog items on the top of the Product Backlog and from this understanding to agree upon a solution for building the desired functionality. The result of this planning is called the Sprint Backlog.
- For the Scrum Team and the Product Owner to create a clear understanding (often called a "committment" or a "forecast") of what will be built during the upcoming Sprint.
Meeting Logistics
The Sprint Planning Meeting's required attendees are the Scrum Master, the Scrum Team, and the Product Owner. Others (including managers, stakeholders, subject matter experts, etc.) may attend as the situation requires. However, it is not recommended to have too many people in the Sprint Planning Meeting at the same time.
A Sprint Planning Meeting is a time-boxed meeting. In other words, planning doesn't continue until it's finished; the concept of a timebox here is crucial, alerting the team when they are spending too much time on planning (perhaps trying to go too deep or perhaps trying to plan something not well understood. The timebox is helpful in identifying behavoiral and process dysfunctions with regard to planning. The length of the Sprint Planning Meeting is directly proportionate to the planned length of the Sprint.
- One calendar month or 4 week Sprint = 1 day of Sprint Planning
- 3 week Sprint = 3/4 day of Sprint Planning
- 2 week Sprint = 1/2 day of Sprint Planning
- 1 week Sprint = 1/4 day of Sprint Planning
Of course, these are approximations, but experience has shown that most Scrum Teams can do effective planning in the timeframes suggested.
Executing the Planning Meeting
While there is no specific "correct" way to run a Sprint Planning Meeting, it is clear that there are a lot of good practices that effective Scrum Teams can employ. Here are some suggestions:
- Agree Upon a Target Capacity - Assuming you keep you Scrum Team membership consistent from Sprint to Sprint, teams have a demonstrable velocity (demonstrated, of course, by their ACTUAL output during previous Sprints). As the team gets better and better at understanding their actual velocity, they can begin their Sprint Planning by comparing their expectations for the current Sprint against their performance in recent previous Sprints. For example, the Scrum Master, can say something like, "OK team, we got 33 points done two Sprints ago and 35 points in the Sprint we just finished. Does anybody have a reason (vacation days, holidays, department meetings, scheduled training) why we should commit to more, less, or roughly the same for this Sprint?"
- Review and Solve Product Backlog Items - Once the target capacity is set, the team should then start at the top of the Product Backlog and
- Review the item - the item is reviewed for remaining functional questions and unknowns.
- Solve the item - the team determines how to build the item in question. Tasks may be created (and may be estimated) to detail what the team needs to do to implement the solution. When tasks are created, they are grouped together onto the Sprint Backlog.
- Negotiation of acceptance criteria and other functional characteristics may occur in order to simplify items and/or make them "completable" in the current Sprint. This might include slicing items into smaller pieces and then completing the "riskier" or higher priority slice in the current Sprint.
- The team continues reviewing and solving items until, based on past performance (Velocity) or a "best guess," the team decides that the Sprint is full. The committed work becomes the Sprint Goal.
