The Effective Sprint Planning Meeting

January 14, 2009 by Peter Stevens

Picture courtesy of Photocapy@Flickr

At the beginning of each sprint, the Scrum team and product owner negotiate the scope of the sprint. They have a limited amount of time to discuss and agree on the sprint backlog. The product owner wants functionality implemented properly and to invest development dollars wisely. The team wants a mandate it can fulfill. And everyone wants the meeting to finish on time! Here is an agenda (complete with a downloadable template) to follow so that your sprint planning will be successful.

The purpose of the Sprint Planning Meeting is for the Product Owner and the team to negotiate what should be accomplished during the sprint, or as I call it, the sprint contract. (Scrum actually defines two meetings, a negotiation meeting with the product owner and a "let's figure out how we are going to do this" meeting among the implementation team. But I'll talk about the latter meeting another day).

Even though we value customer interactions over formal contracts, contracts can still be useful and I like to talk about a "sprint contract". It is simply an agreement between the Product Owner, who agrees not to change his mandate before the end of the sprint, and the team, who commits to delivering a defined set of functionality by that time.

Basic Parameters of the Sprint Contract

One of the best kept secrets of Scrum is that a project consists of a series of fixed time, fixed quality and fixed scope mini-projects, where each mini-project has a cost ceiling. Sum the results of all the mini-projects together and you have your release.

Since the sprint length, team size and definition of done are defined and fixed for the duration of the sprint, only the scope might vary, and even here, the team strives to define and fulfill a commitment.

Cost depends mostly on hours worked. The upper limit is known, but since things happen - like getting called to help another project or an unexpected doctor's visit - the limit is seldom reached. So you have a cost ceiling.

Quality is expressed though the definition of done, and should only change occasionally.

As all the parameters are fixed for the duration of the sprint, the only thing to agree on is the scope. Although not a parameter of the contract, the expected velocity helps set the expectation of how much can be accomplished in the sprint.

Staying within the Time Box

The Scrum Master moderates the meeting, but the Product Owner comes with the agenda. S/he wants functionality delivered and to ensure that the overall project is on track.

Regardless of the length of your sprint or size of your team, preparation is the key to finishing on time. If you are unprepared, the meeting can really drag on!

Before you start, the Implementation Team(s) should have seen, understood and estimated the stories. The stories should be small enough to implement in one sprint. The acceptance criteria should have been defined; this greatly improves your chances that the product owner can accept the implementation on the first try.

The team should know how much capacity they have available. So vacations, training, company events, and other commitments should be known and accounted for before the start of the sprint. Some events are unpredictable, in which case you just make a reasonable guess as to how much capacity they will consume, agree with the Product Owner on priorities, and then accept some stories as "conditional" - those you will do if you have time.

A Simple Sprint Planning Meeting

I have used this structure in a number of contexts, including a case in which the product owner paid for the team by the hour and another with distributed teams on two different sites. How formal you need to be will depend on many things, including the size of the project, how well the project is going, the commercial relationship between product owner and team, how well parties cooperate, etc. The more challenged the project, the more you need to dot you i's and cross your t's.

• Review the basic parameters - start & end date, time and location of the sprint review meeting, team availability and definition of done
• Present & discuss each story. A time box for each may be useful to keep to whole meeting on track. Holding a reserve at the end of this section for difficult stories often makes it easier to move on if the discussion is getting stuck on one story.
• Commit to the stories. Go through the list, one at a time and in order of priority. Get the team or a team to commit each one until no one will commit to any more.
• Agreement. Confirm the list of committed stories with the Product Owner.

You can download the meeting agenda, which also includes suggestions for time-boxing the individual sections

As Scrum Master, I have found it useful to confirm the Sprint Contract with an email to the Product Owner. A picture of the task board, a pdf of the spreadsheet or a screen dump of the wiki page can be an effective way to capture the agreement. Everyone is clear on what should be done and both product owner and team have a solid basis to examine the success of the sprint and the overall state of the project at the sprint review.

Permalink