Planning your first Sprint: a walk-through for a new team

The first Sprint Planning meeting carries two burdens. It is the team's first attempt at the event, and it is a forecast with nothing to measure it against. Teams respond by over-planning, because they feel they should know more, or by guessing wildly, because they are told it is only a forecast. Neither helps. A short preparation and a deliberately modest plan work better.

What to have before the meeting

The Guide says the Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. For a first Sprint that preparation is the most useful thing anyone can do.

A Product Goal, even a rough one. A sentence about the future state of the product is enough. Without it, the Sprint Goal has nothing to serve.

An ordered top of the backlog. Perhaps five to ten items, ordered, with the first three or four clear enough to discuss. They do not need to be detailed. The Guide says items that can be Done within one Sprint are ready for selection, and they usually reach that after refinement, so a first round of refinement a few days before the meeting is worth the time.

A draft Definition of Done. The Developers cannot plan how work gets Done without knowing what Done means. A short draft, perhaps five lines, is better than none. Agree to improve it in the first Retrospective.

Known availability. Who is away, and what the working hours are. This turns capacity from a guess into arithmetic.

A Sprint length. See choosing a Sprint length. The meeting has a maximum of eight hours for a one-month Sprint and is usually shorter for shorter ones, so decide the length before you start.

Topic one: why is this Sprint valuable?

The Product Owner proposes how the product could increase its value in this Sprint. The whole Scrum Team then defines a Sprint Goal that tells stakeholders why the Sprint matters, and the goal must be finalised before the end of the meeting.

For a first Sprint, the best goals are small and complete. "A visitor can find a tutor and see their availability" is a better first goal than "start the search feature". It names an outcome that can be inspected, and it is narrow enough to survive surprises. Teams are usually tempted to pick the most important piece, which is often the hardest. A first Sprint is also a test of the team's way of working, so a moderately valuable and tractable goal is a good choice.

Topic two: what can be done?

The Developers select items from the top of the Product Backlog, in discussion with the Product Owner. The Guide notes that confidence rises with knowledge of past performance, upcoming capacity and the Definition of Done. In a first Sprint, the first of those is missing. There are three honest ways to cope.

1. Use capacity, not history. Count the available days. Take the number of people, the working days in the Sprint, subtract holidays and the time for events, and keep a margin for the unknown. A common rule of thumb is to plan for about 60 to 70 percent of the nominal hours, since meetings, questions and interruptions take the rest. This is a practitioner estimate and not a rule from the Guide.
2. Start light. Select fewer items than feels comfortable. A team that finishes early can pull another item. A team that has overcommitted spends the Sprint feeling behind.
3. Compare with a similar piece of work. If the team has built something like this before, use it as a rough measure.

Resist the urge to use story points or velocity borrowed from another team. They have no meaning for you until you have your own record.

Topic three: how will it get done?

For each selected item, the Developers plan the work needed to create an Increment that meets the Definition of Done. The Guide says this is often done by decomposing items into smaller work items of one day or less, and that how it is done is at the sole discretion of the Developers.

In a first Sprint it is enough to plan in detail for the first days and more loosely for the rest. The Sprint Backlog is a plan that will change. The Guide says it is updated throughout the Sprint as more is learned and should have enough detail to inspect progress at the Daily Scrum.

A worked example

This is an illustrative case. A new team of five builds a tutoring marketplace. The Sprint is two weeks, ten working days. One Developer is away for two days.

The Product Owner proposes the goal: a visitor can search for tutors by subject and see their profile. The team agrees. Four items are at the top of the backlog: a profile page, a subject filter, a search results list and a basic data import for tutors.

Capacity: five people times ten days is fifty person-days, minus two for the absence, minus roughly one day each for events and refinement, leaves about forty-three. At sixty-five percent that is about twenty-eight days of focused work.

The team looks at the four items and estimates, from their experience, that the profile page and the subject filter would take about eight days between them, the results list about six, and the data import about ten. That totals twenty-four, within twenty-eight, with a margin. They select all four, but they agree that the data import is the item to drop if the Sprint goes badly, because it can be seeded by hand for the Review. They plan the first three days in detail and leave the rest to the Daily Scrum.

By the end of the meeting they have a Sprint Goal, four items and a plan, and each person knows what to do on day one.

What to avoid in a first Sprint

• Stretching for impressive. A modest and finished first Sprint teaches more than an ambitious partial one.
• Treating the forecast as a promise. The Guide calls it a forecast. The Sprint Goal is the commitment.
• Skipping the Definition of Done. Without it, "done" will mean something different to everyone by Thursday.
• Planning every day of the Sprint. The plan will change, and the effort is better spent on the first week.
• Leaving without a first task for each person. The Guide's three topics end with the Developers knowing how the work will start.

GOV.UK's guidance on planning in agile makes a related point that suits a first Sprint: plans should be based on what you know now and revised as the team learns.

How to practise it

Plan a first Sprint on paper with your own numbers, and keep the arithmetic. In the simulator, step 2.2 asks you to commit to stories against the team's capacity, which is a safe place to practise doing it for the first time.