Scrum Events for First-Timers: What Happens and How to Prepare

Your calendar just filled up with invitations called Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective, and you are not quite sure what happens in each or what you are supposed to bring. That is a normal first-week feeling.

This guide walks through one complete Sprint in order, based on the 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland, which is the official definition of Scrum. For each event you will find its purpose, how long it can last, and practical tips for a first-timer.

The Sprint: the container for everything else

Scrum has five events, and one of them holds the other four. The Scrum Guide calls Sprints "the heartbeat of Scrum," and describes them as "fixed length events of one month or less." A new Sprint "starts immediately after the conclusion of the previous Sprint."

During a Sprint, according to the guide:

• No changes are made that would endanger the Sprint Goal.
• Quality does not decrease.
• The Product Backlog is refined as needed.
• Scope may be clarified and renegotiated with the Product Owner as more is learned.

A Sprint can be cancelled if its goal becomes obsolete, but "Only the Product Owner has the authority to cancel the Sprint." The guide also recommends holding events at the same time and place to reduce complexity, which is why your invitations probably repeat on a fixed schedule.

Here are the maximum lengths, or timeboxes, the guide sets for a one-month Sprint. For shorter Sprints, the guide says these events are "usually shorter."

• Sprint Planning: up to eight hours
• Daily Scrum: 15 minutes, every working day
• Sprint Review: up to four hours
• Sprint Retrospective: up to three hours

Step 1: Sprint Planning

Sprint Planning starts the Sprint. The whole Scrum Team creates the plan together, and the team may invite others to give advice. The guide organizes it around three questions:

1. Why is this Sprint valuable? The Product Owner proposes how the product could become more valuable, and the team agrees on a Sprint Goal, a single objective for the Sprint. The goal must be set before planning ends.
2. What can be Done this Sprint? The Developers, in discussion with the Product Owner, select items from the Product Backlog.
3. How will the chosen work get done? The Developers plan the work, often by breaking items into pieces of one day or less. How they do this "is at the sole discretion of the Developers."

The Sprint Goal, the selected items and the plan together make up the Sprint Backlog.

First-timer tips:

• Know your availability for the Sprint, including time off, before you walk in. The guide notes that Developers forecast better when they know their past performance, upcoming capacity and Definition of Done.
• Ask questions about any item you do not understand. Clarifying now is cheaper than discovering confusion later.
• It is fine to say an item looks too big. Splitting it is part of planning.

Step 2: The Daily Scrum

The Daily Scrum is "a 15-minute event for the Developers of the Scrum Team," held at the same time and place every working day. Its purpose is "to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary."

Many people still expect a fixed script. Agile Alliance's glossary notes that "Scrum's Three Questions" have commonly been used to structure the meeting, with each person briefly describing completed contributions and any obstacles. However, the 2020 revision of the Scrum Guide removed the Daily Scrum questions. Today the guide says Developers "can select whatever structure and techniques they want," as long as the meeting focuses on the Sprint Goal and "produces an actionable plan for the next day of work."

Agile Alliance lists common pitfalls worth avoiding from day one: turning the meeting into a "status report" delivered to one person, letting it drag on, and the "no problem" meeting where nobody ever raises obstacles. Its suggested fix for long tangents is a "parking lot," where topics are noted and discussed afterward by the people affected.

First-timer tips:

• Speak to your teammates, not to the Scrum Master or a manager.
• Mention anything blocking you, even if it feels small.
• If a topic needs more than a minute, offer to talk right after.
• The Daily Scrum is not the only time to adjust the plan. The guide notes that Developers often meet throughout the day.

Step 3: The Sprint Review

The Sprint Review exists "to inspect the outcome of the Sprint and determine future adaptations." The Scrum Team presents its results to key stakeholders and discusses progress toward the Product Goal. Together, attendees review what was done, what has changed in their environment and what to do next, and the Product Backlog may be adjusted.

Two points often surprise newcomers. First, the review "is a working session and the Scrum Team should avoid limiting it to a presentation." Expect discussion, not a slideshow. Second, only finished work counts. The guide says that if an item does not meet the Definition of Done, "it cannot be released or even presented at the Sprint Review." The review is also not a release gate: work can be delivered to stakeholders before the Sprint ends.

First-timer tips:

• If you built something, be ready to show it working rather than describe it.
• Write down stakeholder feedback so the Product Owner can turn it into backlog items.
• As a stakeholder, try the work yourself and say what you actually think.

Step 4: The Sprint Retrospective

The Retrospective concludes the Sprint. Its purpose is "to plan ways to increase quality and effectiveness." The team looks at how the Sprint went in terms of "individuals, interactions, processes, tools, and their Definition of Done," discussing what went well, what problems came up and how they were or were not solved.

The goal is change, not just conversation. The team identifies the most helpful improvements and addresses the most impactful ones "as soon as possible." They may even be added to the next Sprint Backlog.

First-timer tips:

• Bring one or two specific observations, such as "we waited three days for test data," rather than general feelings.
• Focus on the process, not on blaming people.
• Leave with a small number of concrete actions and an owner for each, and check on them next time.

One more thing: refinement is ongoing

You may also see time set aside for "backlog refinement." It is not one of Scrum's five events. The guide describes it as "an ongoing activity" of breaking down and further defining Product Backlog items, adding details such as a description, order and size, so items are ready for future Sprint Planning.

What a two-week Sprint might look like

For example, imagine a team running two-week Sprints that start on a Monday:

• Day 1, morning: Sprint Planning, ending with an agreed Sprint Goal.
• Days 1 through 10: a 15-minute Daily Scrum at the same time each morning.
• Midway: an hour of refinement for upcoming backlog items.
• Day 10, afternoon: the Sprint Review with stakeholders, then the Retrospective.
• The next Monday: a new Sprint begins with planning.

Your team's exact schedule will differ, but the order of events stays the same. For more on who does what in these meetings, see our guide to the people on an agile team.

Key takeaways

• A Sprint lasts one month or less and contains Sprint Planning, Daily Scrums, the Sprint Review and the Retrospective.
• Sprint Planning answers why, what and how, and ends with a Sprint Goal.
• The Daily Scrum is 15 minutes for the Developers to plan the next day toward the Sprint Goal, with no required script.
• The Sprint Review is a working session with stakeholders on Done work only.
• The Retrospective ends the Sprint with concrete improvements the team will actually try.

Sources

• Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide (November 2020)
• Scrum Guides, Scrum Guide Revisions: Changes between 2017 and 2020 Scrum Guides
• Agile Alliance, Glossary: Daily Meeting