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!)
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.
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.
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.
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.