Scrum Events

Why Scrum has events

Each Scrum event is a formal opportunity to inspect and adapt something: the plan, the product or the way of working. The events create a regular rhythm, so that inspection does not depend on someone remembering to call a meeting, and the Scrum Guide adds that they should "minimize the need for meetings not defined in Scrum". Skipping an event means losing an opportunity to inspect and adapt.

The guide also recommends holding all events at the same time and place, to reduce complexity. Every event has a timebox: a maximum duration.

The Sprint

A Sprint is a fixed-length event of one month or less in which ideas are turned into value. The guide calls Sprints "the heartbeat of Scrum". The Sprint is a container: Sprint Planning, the Daily Scrums, the Sprint Review and the Sprint Retrospective all happen inside it, and so does all the work toward the Product Goal. A new Sprint starts immediately after the previous one ends; there is no gap between Sprints.

Four rules apply during a Sprint:

• 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.

Why one month or less? A longer horizon lets the Sprint Goal go stale, adds complexity and increases risk. Shorter Sprints give more learning cycles and limit how much effort is at stake if something goes wrong. The guide says each Sprint "may be considered a short project". Why fixed length? Because a steady rhythm makes it possible to compare Sprints and to forecast. Extending a Sprint because the work is not finished hides exactly the information the team needs.

To forecast progress, the guide mentions practices such as burn-downs, burn-ups and cumulative flow, and immediately adds that these "do not replace the importance of empiricism". They are optional; see Estimation and Forecasting.

Canceling a Sprint

Sprint cancellation means ending a Sprint before its timebox is over. It can happen when the Sprint Goal becomes obsolete, for example because the market or a regulation changed and the goal no longer makes sense. The guide is short and strict: "Only the Product Owner has the authority to cancel the Sprint." Stakeholders, managers, the Scrum Master or the Developers can tell the Product Owner that the goal has become obsolete, but the decision is the Product Owner's. Cancellation is rare and disruptive; a goal that is merely hard or late is not obsolete.

Sprint Planning

Sprint Planning starts the Sprint by laying out the work to be done. The entire Scrum Team creates the plan together. The Product Owner makes sure attendees are prepared to discuss the most important Product Backlog items and how they relate to the Product Goal, and the team may invite other people to give advice. Sprint Planning covers three topics:

1. Why is this Sprint valuable? The Product Owner proposes how the product could increase its value in this Sprint, and the whole Scrum Team then defines a Sprint Goal that tells stakeholders why the Sprint is valuable. The Sprint Goal must be finalized before Sprint Planning ends.
2. What can be Done this Sprint? In discussion with the Product Owner, the Developers select items from the Product Backlog. Knowing their past performance, their upcoming capacity and their Definition of Done makes their forecast more reliable.
3. How will the chosen work get done? The Developers plan the work needed to create an Increment that meets the Definition of Done, often by breaking items into pieces of one day or less. How they do this is at their sole discretion.

The Sprint Goal, the selected items and the plan together form the Sprint Backlog. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint, and is usually shorter for shorter Sprints.

The Daily Scrum

The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, adjusting the planned work for the coming day. It is held at the same time and place every working day of the Sprint, to reduce complexity.

• It is for the Developers. If the Product Owner or Scrum Master is actively working on Sprint Backlog items, they take part as Developers. The Scrum Master makes sure the event takes place and stays within its timebox, but does not have to attend or lead it.
• Any structure is fine, as long as it focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.
• It is not the only time to re-plan. Developers often meet throughout the day to adjust the rest of the Sprint's work.

Done well, the Daily Scrum improves communication, surfaces impediments, speeds up decisions and makes other status meetings unnecessary.

The Sprint Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and decide on future adaptations. The Scrum Team presents the results of its work to key stakeholders, and progress toward the Product Goal is discussed. Together they look at what was accomplished and at what changed in their environment, and then collaborate on what to do next. The Product Backlog may be adjusted as a result.

The guide is explicit that the Sprint Review "is a working session" and that the team "should avoid limiting it to a presentation". A demo is a good start; the value is in the conversation that follows: what did we learn, what do users need now, what should come next?

The Sprint Review is the second-to-last event of the Sprint, with a maximum of four hours for a one-month Sprint. It is not a gate for releasing: Increments can be delivered to stakeholders before the end of the Sprint (see Increment).

The Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team looks at how the last Sprint went in terms of individuals, interactions, processes, tools and its Definition of Done. It discusses what went well, which problems it ran into, and how those problems were or were not solved, and it explores the assumptions that led it astray.

The team then picks the most helpful changes. The most impactful improvements are addressed as soon as possible, and may even be added to the Sprint Backlog of the next Sprint, so that improvement is planned work instead of a good intention. The Retrospective ends the Sprint, with a maximum of three hours for a one-month Sprint. For the wider idea of improving in small steps, see Continual Improvement.

Refinement: an activity, not an event

Product Backlog refinement is breaking down Product Backlog items and adding detail such as a description, order and size, until items are small and clear enough to be Done within one Sprint. The guide describes it as "an ongoing activity", not as an event, so it has no timebox and no prescribed form. The Developers who will do the work are responsible for sizing; the Product Owner can help them understand trade-offs. Techniques are on Product Backlog Management.

Many teams still schedule a regular refinement session, often once a week. That is a common practice, not a Scrum event; some teams spend about a tenth of their capacity on refinement as a rule of thumb, which is also not a rule of the 2020 guide: the figure comes from the 2017 guide ("usually no more than 10%") and was dropped in 2020.

Timeboxes and a two-week Sprint

The guide gives maximum timeboxes for a one-month Sprint and says that for shorter Sprints the events are "usually shorter". It gives no formula. Many teams scale the maximum in proportion to the Sprint length, as in the right-hand columns below; that is a rule of thumb, not part of Scrum. The Daily Scrum is 15 minutes whatever the Sprint length.

A Sprint at Kestrel

The Portal team at Kestrel Energy works in two-week Sprints. They hold the Daily Scrum at 13:00, which fits around Sprint Planning on the first morning and the Sprint Review on the last.

Portal team · Sprint 23 · Monday 5 October – Friday 16 October 2026

Mon  5 Oct  09:00–12:00  Sprint Planning       Isabel, Lars, all Developers
            13:00–13:15  Daily Scrum           Developers
Tue  6 Oct  13:00–13:15  Daily Scrum
Wed  7 Oct  13:00–13:15  Daily Scrum
            14:00–15:00  Refinement session    common practice, not an event
Thu  8 Oct  13:00–13:15  Daily Scrum
Fri  9 Oct  13:00–13:15  Daily Scrum
Mon 12 Oct  13:00–13:15  Daily Scrum
Tue 13 Oct  13:00–13:15  Daily Scrum
Wed 14 Oct  13:00–13:15  Daily Scrum
            14:00–15:00  Refinement session    common practice, not an event
Thu 15 Oct  13:00–13:15  Daily Scrum
Fri 16 Oct  10:00–12:00  Sprint Review         Scrum Team + customer service,
                                               billing, two pilot customers
            13:00–13:15  Daily Scrum
            14:00–15:30  Sprint Retrospective  Isabel, Lars, all Developers

Mon 19 Oct  09:00        Sprint 24 starts with Sprint Planning

Common mistakes

• A Daily Scrum that is a status report. When Developers report to the Scrum Master or a manager one by one, the event serves someone else. It is the Developers' own planning moment.
• Extending the Sprint "just a few days". Sprints have a fixed length. Unfinished work does not meet the Definition of Done, so it goes back to the Product Backlog, and the Retrospective asks why.
• A Sprint Review that is only a demo. Applause for a slideshow is not inspection. Invite the people who use or pay for the product, and leave with an updated Product Backlog.
• Skipping the Retrospective "because things are going fine". A team that never looks at its own way of working stops improving, and the guide makes it part of every Sprint.
• Sprint Planning without a goal. A list of unrelated items gives the Developers nothing to steer by when things change mid-Sprint.