Your First Sprint: A Step-by-Step Walkthrough for New Teams

Running your first sprint can feel like a big leap, but the mechanics are simple. A sprint is a fixed block of time in which a team turns a small slice of its plan into something usable, then stops to look at the result and at how it worked together.

This guide walks through one complete sprint using the rules in the Scrum Guide, the free, short document written by Ken Schwaber and Jeff Sutherland that defines Scrum. The current edition is dated November 2020. Where this guide offers practical advice that goes beyond the Scrum Guide, it says so.

Treat your first sprint as an experiment. You are not trying to be perfect. You are trying to finish something small, learn from it, and make the next sprint a little better.

Before you start: check the basic setup

The Scrum Guide describes Scrum as "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." It also defines who is involved: "The Scrum Team consists of one Scrum Master, one Product Owner, and Developers." The guide says a Scrum Team is "typically 10 or fewer people."

Before day one, agree on three things:

• Who is the Product Owner? The guide says this is "one person, not a committee." This person orders the backlog and decides what matters most.
• Who is the Scrum Master? This person helps the team understand and use Scrum and removes obstacles.
• Who are the Developers? In Scrum, "Developers" means everyone who does the work of building the increment, whether they write code, design, write copy or test.

If your group cannot fill these roles yet, you can still borrow ideas from Scrum. Just be aware that the guide states: "While implementing only parts of Scrum is possible, the result is not Scrum."

Step 1: Choose a sprint length and book the events

The Scrum Guide sets an upper limit: sprints are "one month or less." The Agile Manifesto's principles also express "a preference to the shorter timescale" for delivery. Practical advice: for a first sprint, one or two weeks is usually long enough to finish something and short enough to get feedback quickly.

Then put every event on the calendar for the whole sprint. The guide's timeboxes are maximums for a one-month sprint, and are usually shorter for shorter sprints:

• Sprint Planning: a maximum of eight hours.
• Daily Scrum: a 15-minute event, held at the same time and place every working day.
• Sprint Review: a maximum of four hours.
• Sprint Retrospective: a maximum of three hours.

Booking these in advance protects them. When the meetings are already on everyone's calendar, they are far less likely to be skipped.

Step 2: Prepare a small backlog and a draft Definition of Done

Before planning, the Product Owner should have a short, ordered list of work at the top of the Product Backlog. You do not need the whole product mapped out. A dozen or so clearly written items is plenty for a first sprint. Our guide to building your first product backlog covers this step in detail.

Next, write a first Definition of Done. The Scrum Guide calls it "a formal description of the state of the Increment when it meets the quality measures required for the product," and it adds that "Work cannot be considered part of an Increment unless it meets the Definition of Done." If your organization has no standard, the team must create one. For example, imagine a small team building a booking page. Its first Definition of Done might be: reviewed by a second person, tested on a phone and a laptop, and live on the staging site. Keep it short, honest and checkable.

Step 3: Run Sprint Planning

The Scrum Guide organizes Sprint Planning around three topics:

1. "Why is this Sprint valuable?" The team writes a Sprint Goal, a single objective for the sprint.
2. "What can be Done this Sprint?" Through discussion with the Product Owner, the Developers select items from the Product Backlog.
3. "How will the chosen work get done?" The Developers break the selected items into smaller pieces of work, often tasks of a day or less.

Your first forecast will be a guess, and that is fine. The guide notes that the more the Developers know about "their past performance, their upcoming capacity, and their Definition of Done," the more confident their forecasts become. On sprint one you have no history yet, so aim low. Finishing a little and adding more is far better than starting a lot and finishing nothing.

The Sprint Goal, the selected items and the plan together form the Sprint Backlog. Make it visible on a physical board or a simple digital one.

Step 4: Run the sprint with Daily Scrums and clear rules for change

The guide says the purpose of the Daily Scrum "is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary." It also says the Developers "can select whatever structure and techniques they want."

A practical starting format is to walk the board from right to left, beginning with the items closest to done, and ask what is needed to finish them. Keep detailed problem-solving for a separate conversation right after.

New requests will arrive mid-sprint. The Scrum Guide's rules are clear: "No changes are made that would endanger the Sprint Goal" and "Quality does not decrease." At the same time, "Scope may be clarified and renegotiated with the Product Owner as more is learned."

In practice, new ideas go to the Product Owner, who adds them to the Product Backlog for a future sprint. If something truly changes the picture, the guide allows that "A Sprint could be cancelled if the Sprint Goal becomes obsolete," and only the Product Owner can cancel it.

Step 5: Close with a Sprint Review and a Retrospective

The purpose of the Sprint Review "is to inspect the outcome of the Sprint and determine future adaptations." Invite the people who care about the work. The guide warns that the team "should avoid limiting it to a presentation," so show the working result, invite questions, and update the Product Backlog based on what you learn.

The retrospective "concludes the Sprint." Its purpose "is to plan ways to increase quality and effectiveness." A simple first format is to ask what helped, what got in the way, and what one or two changes the team will try next. The guide notes that the most helpful changes "may even be added to the Sprint Backlog for the next Sprint," which keeps them from being forgotten.

Then the cycle repeats. As the guide puts it, "A new Sprint starts immediately after the conclusion of the previous Sprint."

Common first-sprint stumbles

• Taking on too much. Plan less than you think you can do.
• A vague Sprint Goal. If nobody can say it in one sentence, rewrite it.
• Unfinished work at the end. Unfinished items go back to the Product Backlog. They do not count as partly done.
• Skipping the retrospective because you are busy. That is the meeting that makes the next sprint better.

Key takeaways

• Agree on the Product Owner, Scrum Master and Developers before you start.
• Keep the first sprint short and book every event in advance.
• Write a short Definition of Done and a one-sentence Sprint Goal.
• Forecast cautiously; you have no history yet.
• End with a real review and a retrospective that produces one or two concrete changes.

Sources

• Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020)
• Agile Manifesto authors, Principles behind the Agile Manifesto (2001)
• GOV.UK Service Manual, Agile tools and techniques