maxClaint

Insights · Agile organisation

A Scrum week: from planning to delivery

How a Sprint of one to four weeks runs, what happens in the show and tell with the business and how several teams provide deliverable results continuously with Scrum@Scale.

By Michele Mangieri · Updated

In short

A Sprint in Scrum lasts one month or less, usually one to four weeks. It starts with Sprint Planning, a 15-minute Daily Scrum follows every day, and it ends with the Sprint Review as a show and tell with the business, followed by the retrospective. Finished results may be delivered during the Sprint.

Graphic: two weeks from Monday to Friday; planning on the first Monday, a daily every day, refinement twice, show and tell with the business and retrospective on the last Friday, three deliveries within the Sprint.

Events

What happens in a Sprint.

A Sprint lasts one month or less, in practice usually one to four weeks. Its length stays the same so that a reliable rhythm develops. All events take place within the Sprint.

Sprint Planning

At the start, the team clarifies why the Sprint is valuable, what can be done and how. The result is the Sprint Goal.

Daily Scrum

Every day for 15 minutes, at the same time and place. The developers inspect progress towards the Sprint Goal and adapt their plan.

Sprint Review: show and tell with the business

At the end, the team shows the business and other stakeholders what is done and discusses it with them: what fits, what is missing, what comes next? The Scrum Guide treats the review as a working session, not just a presentation.

Sprint Retrospective

The team inspects how it worked: collaboration, processes, tools and the Definition of Done. The most important improvements go into the next Sprint.

Backlog refinement

An ongoing activity: Product Backlog items are broken down and clarified until they fit into a Sprint.

Example

Two weeks in rhythm.

This is what a two-week Sprint looks like for many teams. Each team sets its own times.

Graphic: two weeks from Monday to Friday; planning on the first Monday, a daily every day, refinement twice, show and tell with the business and retrospective on the last Friday, three deliveries within the Sprint.
Fig. 22 · Sprint cycle
  • Monday, week one: Sprint Planning in the morning, then work on the Sprint Goal begins.
  • Every day: Daily Scrum, 15 minutes, always at the same time.
  • Thursday of week one and Wednesday of week two: one refinement session each, so the next Sprint is prepared.
  • Continuously: whatever meets the Definition of Done is integrated and can be delivered, not only at the end of the Sprint.
  • Friday, week two: show and tell with the business. The team shows working results, the business tries them out and gives feedback for the backlog. Then the retrospective; the next Sprint starts on Monday.

Sprint length

One to four weeks: what the length changes.

1 week

Fastest feedback, but a lot of coordination relative to the work. Good when requirements change often. Planning up to about 2 hours, review about 1 hour, retrospective about 45 minutes.

2 weeks

A common rhythm: enough time for a usable result, feedback every ten working days. Planning up to about 4 hours, review about 2 hours, retrospective about 1.5 hours.

3 weeks

Fits when results need more lead time, for example for business testing. Planning up to about 6 hours, review about 3 hours, retrospective about 2 hours.

4 weeks

The Scrum Guide's upper limit. The longer the Sprint, the more likely the Sprint Goal becomes outdated along the way and the higher the risk. Planning up to 8 hours, review 4 hours, retrospective 3 hours.

The times are maximums from the 2020 Scrum Guide for a one-month Sprint; for shorter Sprints they are given proportionally as a rule of thumb.

With several teams

Deliverable fast with Scrum@Scale.

When several teams work on one product, a deliverable result only exists once their work fits together. Scrum@Scale and proven engineering practices offer several ways to get there.

  • One shared Definition of Done: when several teams work on one product, the Scrum Guide says they define and follow the same Definition of Done. If it includes integration, automated tests and production-like deployment, every finished result is deliverable.
  • One integrated increment in the Scrum of Scrums: delivery is a building block of the Scrum Master Cycle. The teams bring their work together into one shared, tested state instead of each delivering on its own.
  • One joint show and tell: in the Scrum of Scrums, all teams show the business one integrated result instead of presenting partial states one after another. That way the business sees what actually works together.
  • Delivering within the Sprint: several increments may be created in a Sprint. The review is not a gate for release; a result is delivered as soon as it is done.
  • Separating deployment from release: with switches in the code (feature toggles), software goes to production continuously. When a feature is switched on is decided by release planning in the Product Owner Cycle.
  • An automated pipeline: without automated tests and a deployment pipeline, every delivery becomes a project. In SAP landscapes this includes transports and interface tests.
  • Removing impediments fast: what a team cannot solve on its own is raised in the Scaled Daily Scrum and goes to the Executive Action Team.
  • Feedback into both cycles: product feedback goes to the Product Owners, release feedback to the Scrum Masters.

From our work

In an S/4HANA transformation we automated UAT and regression tests so that results are ready for acceptance sooner. As Scrum Master and facilitator between business and IT, we have seen that the rhythm only holds when the business and stakeholders actually attend the review.

Want to bring several teams into one rhythm? To Workshop Facilitation →

Sources: The Scrum Guide, November 2020, Ken Schwaber and Jeff Sutherland; The Scrum@Scale Guide, version 2.1, February 2022, Jeff Sutherland and Scrum Inc.; both under the CC BY-SA 4.0 licence. Scrum@Scale is a registered trademark of Scrum Inc. maxClaint is an independent advisory firm and not affiliated with Scrum Inc.

Frequently asked questions

Questions about the Sprint

How long is a Sprint in Scrum?

One month or less, in practice usually one to four weeks. The length stays the same so that a rhythm develops. If a Sprint is too long, the Sprint Goal can become outdated along the way and risk increases.

What is a show and tell in Scrum?

It is a common name for the Sprint Review. The team shows the business and other stakeholders its working result, the business tries it out and gives feedback. The Scrum Guide treats the review as a working session in which the next steps are decided.

Can you deliver before the end of a Sprint?

Yes. Several increments may be created and delivered within a Sprint. The Sprint Review is not a gate for release. The condition is that the result meets the Definition of Done.

How do several teams deliver fast with Scrum@Scale?

With one shared Definition of Done, an integrated increment in the Scrum of Scrums and automated deployment. Feature toggles separate deployment from release. Impediments go via the Scaled Daily Scrum to the Executive Action Team.

30 minutes, and you will know whether we can help.

You describe the decision ahead. We tell you which package fits, or that none does.

Start an enquiry