Walking through a Sprint

A sprint is a time-boxed period, usually two to four weeks, during which a specific set of tasks or objectives are completed. It’s the core rhythm of Scrum, the most widely used Agile framework. Here’s how a sprint works in practice.

Before the Sprint: Sprint Planning

Every sprint starts with sprint planning. The whole team — developers, product owner, Scrum master — meets to decide what gets done. You pull from the product backlog, a prioritized list of everything the product needs. The product owner presents the highest-priority items; the team decides how many they can realistically finish.

Then you break those items into tasks. Each task gets an owner and an estimate. Many teams use planning poker for this: everyone plays a card with their estimate simultaneously, then discusses outliers until consensus forms. This isn’t about precise hours — it’s about shared understanding of complexity.

During the Sprint: Daily Scrum

Once the sprint starts, you meet daily for 15 minutes max. Stand up. Keep it short. Each person answers three prompts: what did I finish yesterday, what am I tackling today, what’s blocking me. That’s it. Problem-solving happens after, with only the people who need to be there.

Work gets tracked in the sprint backlog — the live list of tasks in progress. Update it as you go. The product owner stays available for questions but doesn’t micromanage. If scope changes mid-sprint, the product owner and team negotiate what drops out to keep the commitment realistic.

At the End of the Sprint: Review and Retrospective

Two separate meetings, both mandatory.

The sprint review is a demo. You show working software to stakeholders. They give feedback; you capture it for the backlog. No slides, no status reports — just the product.

The retrospective is for the team only. What worked? What didn’t? What one thing will we change next sprint? Pick one actionable improvement. Not five. One. Write it down, assign an owner, verify it happens.

Practices That Keep Sprints Healthy

  1. Keep sprints short. Two weeks forces frequent feedback and smaller batches.
  2. Groom the backlog continuously. If the top isn’t ready, planning stalls.
  3. Protect the daily scrum. Fifteen minutes. Standing up. No deep dives.
  4. Make blockers visible immediately. A blocker that sits for a day is a sprint risk.
  5. Run retrospectives every sprint, even when things feel fine. Especially then.

Liked this briefing? Get it in your inbox

Every morning: the stories that make tech leaders act, with official clips and primary sources. Free, 5-minute read.

Free. One click to unsubscribe. We never share your email. Privacy

Walking through a Sprint

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to top