This is a sample agenda for a sprint planning meeting. Depending on your context you will have to change the details, just make sure the outcomes stay the same.

Meeting purpose: Plan and prepare for the upcoming sprint
Meeting duration: ca. 1 hour for a 2 week sprint (it will be less if you’re an experienced team and know your domain well)

Part 1:

1. Intro & set the scene

Remind everyone that the purpose of the meeting is to plan the work for the next sprint.
Remind everyone of the sprint duration and demo date.

Share the desired meeting outcome:
– A sprint goal
– A sprint backlog including tasks

Share the planned agenda:

• Define the sprint goal
• Decide how much to chew off
• Decide which stories to do this sprint
• Create tasks for stories

2. Define the Sprint goal

Come up with a sprint goal: The purpose of having a goal is to be able to select user stories that support the goal, i.e. help you work towards something bigger than just delivering a collection of stories or unrelated features. It’s also really useful to assess at the end of the sprint whether you have been successful or not. Success is achieving the sprint goal, not just delivering all the stories you had planned to get done.

Examples could be:

• “Build edit delivery feature”
• “Make the app hotter!”
• “Demo advanced property search” (It’s okay to have a goal that is to collect feedback through a demo/prototype)
• “Fix push notifications and improve motors search” (One goal is better but if it is way too small it’s okay to have a dual goal. Just make sure you don’t end up with just a collection of unrelated user stories)

3. Decide how much to chew off

If you are using story points or count the number of stories delivered as a measure of velocity it’s a good idea to decide on a target velocity next. Base that decision on looking at a combination of past velocity, people’s availability (any holidays?) and just plain gut feeling.

Make sure you take past data into consideration, not just wishful thinking about how much you feel you “should” get done. This is also the reason why I like to discuss target velocity before choosing stories for the sprint: It is all too easy to get carried away with enthusiasm and optimism.

If you don’t have any data yet, don’t worry – just go by gut feeling and start collecting data now.

4. Decide which stories to do in this sprint

Take your product backlog and discuss for each candidate story what it means, what you’re trying to achieve and what success looks like. Do this for all the stories you think you might be able to schedule into the sprint.

Choosing which stories to consider for your sprint is mainly determined by the sprint goal. Other considerations are:

• What if we can do more than just the stories that support the goal?
  You could have a secondary goal (“Fix push notifications and improve motors search”) but make sure these are prioritised against each other. Or you could “fill” with bug fixes, enhancements and smaller, not necessarily related requests. Make sure to communicate that these are less important though than things that support the sprint goal and will get dropped if the goal is in danger.
• What if there’s stuff we really want to do such as re-paying some technical debt?
  I like agreeing on one or two of such items for each sprint. I have found ca. 20% of a sprint’s work dedicated to the team’s wishes to be a good thing.
• What about high risk items?
  It sometimes makes sense to prioritise a risky story higher to just learn, gather knowledge and be able to plan. Early prototypes for hairy features are a good idea.

What it comes down to is to have a discussion between the team with their technical expertise and the Product Owner as the representative of end users and stakeholders and to decide together what you want to do during the next couple of weeks.

Also, make sure not to “fill up” your entire sprint with planned work but to leave some room for unexpected opportunities or complexities.

Once you have decided which stories to aim for during the next sprint, move on to part 2.

Part 2:

5. Task planning

I like planning individual tasks for each user story and to make work visible at a granular level. This makes it easier for people to collaborate around user stories and to help each other reach a shared goal.

As an example for the user story “As a photographer I want to make some of my albums private so that no one else can see them” we identified the following tasks:

If you find it hard to make tasks ask yourself how you would get started. And what you would do next? And then? You’ll find you can come up with quite a lot of useful tasks that need to be done.

Try to keep tasks to less than a full day’s work so that stuff moves through on a daily basis and there is a sense of progress and opportunity for collaboration during the daily standup. Also, try to split them in a way so that in theory different people could do different tasks.

Remember that you don’t need to get the tasks right upfront: It’s perfectly fair to add new tasks to a story or to delete tasks that are no longer needed during the sprint.

And don’t assign tasks upfront! It will just make you wait for each other and cheat you for opportunities to collaborate and help each other.

Part 3: Set up your visual workspace

This is the outcome of your sprint planning meeting: A visual workspace with a list of user stories and associated tasks.

Here’s an example:

If you aren’t co-located you can of course achieve the same in Jira or some other tool. I really like the tactile and highly visible nature of the post-it note board though, so if you have the option I’d definitely use one of these.