The first six Sprints: what a new team should expect

The first Sprint is not representative. The team is learning the vocabulary, the product, each other and the tool, all at once. Management watches for results and gets a modest Increment and a lot of questions. Teams that do not expect this tend to conclude within a month that Scrum is slow, or that they are doing it wrong. They are doing it as new teams do.

The arc

A new team's first months follow a pattern that group development models describe for teams in general: a period of getting to know each other and the rules, a period of friction as differences surface, a period of settling into norms and then of working well together. The SBOK® Guide includes such a model among the human resource theories it summarises, with its stages of forming, storming, norming and performing, and links them to team building. The Scrum Guide does not describe stages, but its view that team members learn and explore the values as they work with the events and artifacts implies the same: capability grows through doing.

Applied to Scrum, the arc has a recognisable shape:

• Sprint 1 to 2: awkward and slow. The team learns the mechanics. Estimates are poor. Goals are loose.
• Sprint 3 to 4: friction and a dip. Real problems surface: unclear stories, dependencies, quality, disagreements. Output may drop. This is the stage at which teams give up.
• Sprint 5 to 6: settling. Habits form. The Definition of Done holds. Forecasts improve.

The aim of this post is to make the dip expected.

Sprint by Sprint

Sprint 1: get a complete cycle done. The goal is to experience every event and to finish a small, real Increment. Keep the scope modest. Write a Definition of Done, even a short one. Expect to be unsure how much to take. See planning your first Sprint. In the Retrospective, pick one change.

Typical numbers: the team finishes half to two thirds of what it forecast. That is normal.

Sprint 2: calibrate. Use the first Sprint's result to forecast more honestly. Focus on the Sprint Goal and on keeping the Sprint Backlog current. Start refining ahead, so the next Sprint's top items are clear before planning. Begin collecting simple data: items finished, time to finish.

Typical numbers: closer to the forecast, still variable.

Sprint 3: expect the dip. Problems that the early Sprints hid appear. The Definition of Done begins to hurt because it is being applied. Dependencies bite. People disagree about how to work. Throughput may fall. This is where the Scrum Master's work is most needed: keep the team's attention on learning, not on the number, and bring organisational impediments to light.

Typical numbers: lower throughput, more carry-over. Do not panic.

Sprint 4: fix the biggest cause. The Retrospectives from the earlier Sprints have a list. Choose the largest single cause of the dip and fix it. Often it is story size, refinement, a missing test environment or an unowned dependency. See common Sprint Planning mistakes.

Typical numbers: beginning to recover.

Sprint 5: stabilise. The team has a rhythm. The Definition of Done is mostly met. The Product Owner orders with confidence. Use the data to forecast the next release as a range. Tighten the Definition of Done by a line. Invite real users or stakeholders to the Review if not already.

Typical numbers: steadier. Throughput varies less between Sprints.

Sprint 6: review the approach. Step back and look at the six Sprints as a whole. What has the team learned? What are the biggest remaining problems? What is the evidence that Scrum helps here? Decide what to change in the next six, for instance a different Sprint length, a stronger Definition of Done or a new practice. Agree a working agreement based on what has worked. See working agreements.

Typical numbers: the Sprint Goal is met more often than not.

A worked example

This is an illustrative team of six, new to Scrum, building a booking tool.

Sprint one: it forecasts 20 points and finishes 11. The Retrospective's action: refine stories before planning. Sprint two: 18 forecast, 15 finished. Sprint three: the Definition of Done now includes automated tests, and throughput falls to 10. The Product Owner worries. The Scrum Master shows the six-Sprint arc and points out that test failures found now would have been found by customers later. Sprint four: the team splits the largest stories and fixes a flaky test environment. Done: 16. Sprint five: 19 forecast, 19 done, the Sprint Goal met for the second time. Sprint six: the team's data shows a steady 17 to 19. In its review it decides to lengthen refinement slightly and to add a monthly health check.

The sponsor, who had been sceptical in Sprint three, now sees working software every fortnight and a forecast with a range. The team did not get better in a smooth line. It got better by hitting a wall and fixing what caused it.

What to measure

Keep it light.

• Sprint Goal met? A yes or no each Sprint.
• Items forecast and finished. The gap tells you about planning.
• Carry-over. Items not finished.
• Time to finish. Cycle time, roughly.
• A simple team mood rating. See team happiness.

Do not compare the numbers with other teams, or with your own early Sprints as a verdict. They are for learning.

Signs you are on track

• The team can say what each event is for.
• The Retrospective produces an action each time, and last Sprint's is finished.
• The Product Owner can say what the next two Sprints will probably hold.
• Items are smaller by the sixth Sprint than the first.
• Someone outside the team has seen the working product.
• The team is surprised less often at the Review.

Signs of trouble

• No improvement in the same area over three Sprints.
• A Product Owner who cannot be reached.
• Stories regularly unfinished for the same reason.
• Events being skipped.
• Team members talking of Scrum as "their" process and not "ours".
• The Scrum Master is the only person who understands the framework.

These are the signs to bring to a sponsor early.

How to practise it

Before your next Sprint, tell the team and the sponsor what the dip looks like and when it is likely, so they recognise it. In the simulator each phase has its own challenges, and the early steps teach in the same arc of confusion and then clarity.