Sprint planning should take place on the first day of the sprint. This session is divided into two parts, the first part is attended by the delivery team and the product manager, whereas the second part is usually only attended by the delivery team.

The session can take place anywhere, however due to the collaborative nature of the session, it’s probably best if there’s a big table that everyone can fit around.

Attendees:

• Scrum Team
• Product Manager
• Relevant Product Owner(s)

Tools/Documentation:

• Post-its/Index Cards
• Pens
• Whiteboard/Marker pens

Agenda:

1. Presentation of the product backlog by the Product Manager and/or Product Owner(s)
2. Team and Product Manager define Sprint Goals
3. ****BREAK****
4. Team agree upon User Stories to be delivered in the coming sprint
5. Team agree delivery strategy (Create task cards for each User Story)

Presentation of the product backlog by the Product Manager and/or Product Owner

This session kicks off with the Product Manager and/or Product Owner presenting each backlog item to the team in priority order. These backlog items should be in User Story format and should be accompanied by relevant acceptance criteria and Test Confirmations where possible.

Best practice dictates that the Product Owner should take responsibility for presenting the Product Backlog to the Team.  This secures buy-in and offers an opportunity for collaboration between the Product Owner and the Team.

With that said, assuming communication is really strong between the Product Manager and the Product Owner, there is no reason why the Product Manager shouldn’t be able to cover for the Product Owner(s). In the event the Product Owner is not able to attend, just be aware that you will need to invest more time towards insuring that communication, awareness and buy-in is strong between the Product Manager, Team and Product Owner.

So, back to presenting the User Stories.

Most of these User Stories will already be familiar to the team – they will have been introduced to them at the Scrum Requirements Workshop.

Some of the stories will have had outstanding actions/questions that were raised at the Scrum Requirements Workshop – these will all be addressed within this session.

The Scrum Team should advise the Product Manager and Product Owner on the number of stories to discuss in this session – it’s usually good to have at least 1.5 sprints worth of stories ready at any given point in time. The team may feel particularly ambitious one sprint, or disruptions may force them to accept new stories into a sprint – better to be prepared.

The team and Product Manager/Product Owner may enter into negotiation in this session – they’ll seek to clarify expectations, priorities and the level of investment required in any particular story e.g. ‘do you want me to go all out on that story or do you want something basic?’. If the scope changes entirely, the team may re-estimate a story using their .

Once the team are clear on the expectations, they move on to the next agenda point.

Team and Product Manager/Product Owner define Sprint Goals

Sprint goals are actually really useful – we didn’t start creating them until quite recently. Although it may not be an obvious side-effect of setting goals, I find teams actually become quite creative at this point. They begin to look outside of the pre-defined User Stories and might make a few suggestions on other things that can be done to better fulfill the sprint goal.

Nevertheless, this discussion ends with a few goals having been defined. Try not to commit to more than 3 or 4 goals. This keeps things focused. These goals will be used to benchmark the success of the sprint at the Sprint Review Meeting – did they meet their goals?

Once the team are fully-briefed and aware of their goals, the Product Manager and Product Owner(s) usually leave the team to it.

Team agree upon user stories to be delivered in the coming sprint

Once the Product Manager leaves, the team reflects upon the objectives and discussion. They then look through the prioritised backlog and agree the slice that will be taken forward into the next sprint.

Before making a commitment, the team will review the following:

• How many Story Points did they deliver last sprint
• Are there any holidays planned for the coming sprint
• Are there any big milestones/events taking place that may affect their velocity

Once the team agree on the number of stories to accept, they will begin to plan their delivery strategy.

Team agree delivery strategy

It is at this point that some teams break the User Stories down into tasks, which are then estimated in hours. If the User Stories are small enough, it may not be necessary to break them down further. The approach taken will affect the way the team tracks progress during the sprint.

Burning down on Hours or Points?

If tasks are estimated in hours then teams will generally burn down on hours remaining at the end of each day e.g. Joe starts a 6 hour task, at the end of day one he has 2 hours remaining on the task so the burn down chart reflects a 4 hours decrease in ‘hours remaining’.

If User Stories are small enough, then the teams will generally burn down Story Points upon completion. e.g. Joe starts a 5 point task and finishes it after two days. At that point he adjusts the burn down chart to show a 5 point decrease in ‘points remaining’.

It is also at this point that the team may need to draw ideas on a whiteboard/make notes on task cards etc.

Note:

This session will take longer if:

• The team is less established
• The project is new
• The sprints are longer
• The User Stories are not clearly defined in advance of the session
• The User Stories are too big***
• People deviate from the agenda^^

***Although it shouldn’t translate, I’ve met a lot of Product Managers and Agile Teams who all seem to agree that all sprint contenders should be estimated at 13 points and below. Stories above 13 points will often be less thought through.

^^ Each team is different. Some are good at sticking to the agenda, others are less good. Agree your meeting rules in advance of the session – some teams come up with interesting ways to control one another e.g. raising a ‘Time Out’ card when people go Off Topic.

Read more about Scrum Meetings

Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!