Sprint Zero: Getting a Team Ready to Deliver

Sprint Zero: Getting a Team Ready to Deliver

Establish the artifacts, environments, and agreements so Sprint 1 starts clean.

3 min read

Sprint Zero is a short preparation sprint, typically two to three weeks, that establishes the shared artifacts, environments, and agreements that let Sprint 1 begin cleanly. It exists to make the team genuinely ready to start, not to start delivering features. Aim its end date at the planned sprint cadence so the rhythm is set from day one.

When to use this play#

Use it whenever a new team is forming around a new effort and you want Sprint 1 to be productive rather than a scramble to set up tooling and agree on basics. It is the difference between a team that starts and a team that is ready to start.

How to run it#

Sprint Zero produces two kinds of output: whole-team artifacts and engineering setup. Make the shared agreements big and visible. Start spikes during the sprint, but do not require finishing all of them.

Whole-team artifacts. Create and post these so the whole team can see them:

  • A team name.
  • Key roles identified: delivery lead, product owner, tech lead.
  • Value stories with quantified value, posted.
  • Personas.
  • A story map sliced into releases, identifying the MVP or steel thread.
  • A Definition of Done agreed by every member and posted.
  • A spike list for the unknowns.
  • A card wall or board showing the workflow.
  • A defined cadence.
  • A Definition of Ready (optional).
  • Team norms: pairing approach, stand-up expectations, and how the team works together.

Engineering setup. Get the machinery running:

  • Source control with team access.
  • CI running a green build.
  • Local development environments that work.
  • An automated build.
  • Testing frameworks configured.
  • Code-quality tooling in place.

Spikes. Begin the spikes for the biggest unknowns during Sprint Zero. The goal is to start retiring risk and capture what you learn, not to close every spike before the sprint ends.

Common traps#

  • Treating Sprint Zero as Sprint 1. If you start building features, you skip the readiness work and pay for it later. This sprint is about being ready, not delivering.
  • Keeping agreements private. A Definition of Done in someone's notes is not an agreement. Make it big and visible.
  • Trying to finish every spike. Spikes can run past Sprint Zero; gating the sprint on all of them defeats the purpose.
  • Skipping the engineering setup. A green CI build and working local environments on day one prevent a week of friction in Sprint 1.

Exit criteria#

Sprint Zero is done when:

  • Spike results are captured and shared.
  • Increment and release objectives are agreed by product and dev.
  • Sprint 1 is planned: committed cards have acceptance criteria, are estimated, and are on the board.
  • The backlog is groomed, with the top cards sized.

Signals it's working#

  • New team members can find the agreements on the wall instead of asking around.
  • A fresh checkout builds green locally and in CI without tribal knowledge.
  • Sprint 1 planning is a confirmation, not a discovery exercise.

How it ends#

It ends on a date aligned to the sprint cadence, with the team genuinely ready: artifacts posted, environments green, agreements shared, and Sprint 1 planned. The first real sprint then begins clean, which is the entire point.