Sprint Planning 1

What is the best possible step forwards?

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 to help keep your sprint planning on track and 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 traditionally 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. More recent guidance is going back to one meeting.)

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 a helpful reminder that Scrum implements commitment based planning, and everyone is bound by the agreement. 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 doing their best to achieve the sprint goal within that time. (Hint: your organization must also agree to respect the Sprint Contract!)

Basic Parameters of the Sprint Contract

One of the best kept secrets of Scrum is that an overall project consists of a series of fixed time, fixed quality and almost 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.
• If the team fails to achieve all the goals, it should deliver less scope. Time, Cost & Quality should remain fixed.

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, and how well parties cooperate. The more challenged the project, the more you need to care about the format and formality.

• •Review the basic parameters – Start and end dates, 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.
• •Forecast 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  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.

Agenda for Sprint Planning 1

• Participation:
  • •Must: Product Owner, Implementation Team
  • Should: ScrumMaster
  • Optional: Others whom the Scrum Team feel is necessary
• Purpose: Agree on the “Sprint Contract”. If the team fails, it should fail to deliver all the scope, but must ensure that time, cost and quality remain constant.
• Duration: 1 Hour per week of Sprint
• Frequency: Once per Sprint. It is advisable to reserve dates months in advance