What is a Sprint?

How a Sprint Works: The Full Cycle

Every sprint follows the same pattern, regardless of length:

• Sprint Planning — team selects items from the backlog, estimates effort, and commits to a sprint goal
• Sprint Execution — team works on committed tasks, with daily standups to surface blockers
• Sprint Review — team demonstrates completed work to stakeholders and collects feedback
• Sprint Retrospective — team reflects on process: what went well, what slowed us down, what to improve

Sprint Planning: How Teams Pick What to Build

Sprint planning is where the sprint is defined. The team reviews the prioritized product backlog and selects items they can complete within the sprint timeframe. Each item should be small enough to finish in the sprint and clear enough that everyone understands what "done" means.

A common mistake: teams overcommit. They select 3 weeks of work for a 2-week sprint because everything feels important. Velocity — the team's average output per sprint — prevents this by showing what's actually achievable based on past sprints.

Good sprint planning ends with a sprint goal: one sentence describing what the team will accomplish and why it matters. "Complete client onboarding flow so we can launch beta" is a good sprint goal. "Work on onboarding stuff" is not.

Choosing the Right Sprint Length

Sprint length is a team decision. The main considerations:

Sprints vs Continuous Flow (Kanban)

Not every team needs sprints. Kanban uses continuous flow — tasks move through the board as capacity allows, without fixed cycles. Sprints add structure but also overhead (planning meetings, retrospectives, ceremony).

Sprints work well when work can be broken into discrete chunks, when stakeholders want regular demos, and when the team benefits from clear start/end points. Continuous Kanban works better for support teams, operations, and agencies with unpredictable inbound work.

Many teams use a hybrid: sprint-style planning with a Kanban board for execution, and a retrospective every two weeks.

Sprint Zero: How to Prepare Before You Start

Sprint Zero is the setup phase before Sprint 1. It's not a sprint with a deliverable goal. The purpose is to make Sprint 1 functional from day one instead of spending the first week configuring tools, clarifying roles, and backfilling missing context.

Teams new to sprint-based work need Sprint Zero. Without it, Sprint 1 becomes Sprint Zero under the pressure of a delivery target.

Backlog creation takes 4–6 hours. Write down every active project, task, and open request. Break large items into tasks one person can finish in 1–3 days. Assign rough estimates: small (under a day), medium (1–2 days), large (3–4 days). Anything larger than 4 days gets broken down. At the end, you should have a backlog of 30–50 items covering 2–3 months of work. Don't try to capture everything — focus on the next quarter.

Defining "done" takes 1–2 hours. Agree on what completion means for each type of deliverable your team produces. A design file, a client document, a copy draft: each type has different completion criteria. Write them down in a shared location before Sprint 1 starts.

Sprint length takes 30 minutes to decide. New teams should start with 2-week sprints. They give more time to complete work without the pressure of a weekly deadline. After 2–3 months, re-evaluate: if client feedback cycles make 2 weeks feel too long, switch to 1-week sprints.

Role assignment takes 30 minutes. Who owns the process (Scrum Master)? Who owns the priority list (Product Owner)? For small teams, these overlap with other responsibilities. Set clear expectations before Sprint 1 so the first sprint planning session doesn't start with a debate about who's facilitating.

Capacity planning for Sprint 1 takes 1 hour. Calculate each team member's available hours: total working days × focus hours per day, minus planned time off and recurring meetings. For Sprint 1, plan to fill 70% of capacity. Leave a buffer for first-sprint overhead and learning curve.

Sprint Zero is not a phase for delivering client work. If you're producing deliverables during Sprint Zero, rename it Sprint 1 and add a sprint goal.

• Backlog: 30–50 items, all broken to 1–3 day tasks, rough estimates applied before planning starts
• Definition of done: written, agreed by the full team, posted where everyone can find it
• Sprint length: 2-week default for new teams, re-evaluate after 8 sprints
• Roles: Scrum Master (owns the process) and Product Owner (owns the priority list) assigned before Sprint 1
• Sprint 1 capacity: plan at 70% of available hours — leave buffer for first-sprint overhead

Running a Sprint Review That Clients Actually Find Useful

Most sprint reviews fail because teams run them as internal progress meetings. The Product Owner hears what was completed, nods, and the meeting ends. Nothing in the next sprint changes based on that conversation.

A useful sprint review is a feedback and decision session. The goal is not to report progress. The goal is to collect decisions and confirm priorities before the next sprint starts.

Who attends matters. Bring the full delivery team, the Product Owner, and at least one client or stakeholder who can approve work and make decisions. A sprint review without a decision-maker produces unverified feedback that may not reflect what actually matters to the client.

Structure that works in 45 minutes:

Sprint goal recap (5 minutes): state the sprint goal and whether the team met it. No justification, no context. "We planned to complete the three homepage sections and the mobile navigation. We finished the two homepage sections. Mobile navigation moves to the next sprint."

Demo of completed work (20 minutes): show the work, don't describe it. For design work, open the files or prototype. For written work, read the key sections. Walk through each completed item. One person presents, one person handles questions. Nothing "almost done" appears here.

Feedback and decisions (10 minutes): after the demo, ask two questions: what works and what needs to change? Record every piece of feedback in writing during the session, where the client can see it. Don't paraphrase. Their words matter. This prevents "that's not what I said" follow-ups later.

Next sprint preview (10 minutes): show the top 5–7 items from the backlog planned for the next sprint. Ask if the priorities are correct. This is when clients redirect work before it gets started, not after it gets delivered. Most teams cut this section when time runs short. It's the highest-value part of the review for the client.

After the review, update the backlog within 24 hours with all feedback incorporated. Send the client a one-page summary: what was completed, what was deferred, and what the next sprint covers.

• Present only completed work — nothing "almost done" appears in the review
• Record client feedback in writing during the session, not from memory afterward
• Include the next sprint preview — this is where priorities get confirmed, not in email threads
• Invite a decision-maker — a review without one produces unverified feedback
• Send a written summary within 24 hours: completed items, deferred items, next sprint scope

Sprint Capacity: How to Stop Overcommitting

Overcommitting is the most common sprint problem. Teams plan for 100% of available hours, hit unexpected blockers, and end every sprint behind. After 3–4 sprints like this, the team stops trusting the plan entirely.

Sprint capacity planning fixes this with a calculation instead of an estimate.

For each team member, calculate available sprint hours in four steps: 1. Count total working days in the sprint (10 days for a 2-week sprint). 2. Subtract planned days off and public holidays. 3. Subtract time for recurring meetings, converted to hours. 4. Multiply by focus hours per day.

Focus hours per day is typically 5–6, not 8. Two to three hours per day go to email, Slack, context switching, and administrative tasks that don't appear in anyone's sprint backlog. Teams that plan against 8-hour days consistently end up 30–40% over capacity.

For a 10-person team on a 2-week sprint with no planned absences and 1 hour of daily meetings, using 5 focus hours per day: each person has 10 days × 5 hours = 50 hours available. Team total: 500 hours.

Apply a buffer. New teams: plan at 70% of capacity (350 hours). Experienced teams: 80–85% (400–425 hours). Never 100%.

The buffer absorbs imperfect task estimates, unexpected client requests, sick days, and blockers nobody predicted. Teams that run at 100% capacity have no mechanism to absorb any variation. One unexpected event breaks the sprint.

Midpoint check on day 5 of a 10-day sprint: each team member estimates remaining hours on in-progress tasks. Compare total remaining work to remaining available capacity. If remaining work exceeds remaining capacity by more than 20%, the team decides at the midpoint what moves to the next sprint. Raising this on day 10 leaves no time to adjust.

Track buffer usage over 3–4 sprints. If you consistently finish well under capacity, raise the buffer to 80%. If you consistently run over, drop to 65%.

• Use 5–6 focus hours per day, not 8 — the gap goes to email, admin, and context switching
• Buffer: 70% for new teams, 80–85% for experienced teams — never plan at 100%
• Midpoint check on day 5: compare remaining work to remaining capacity, adjust the backlog then
• Track buffer usage over 3–4 sprints and calibrate — 70% is a starting point, not a permanent rule

Multi-Project Teams and Sprints: Making It Work

Most sprint frameworks assume one team, one project, one backlog. For agencies and studios, that's not reality. A 12-person team might run 6 active client projects at the same time. Everyone works across multiple projects. Single-project sprint models break immediately under this structure.

Three approaches work for multi-project teams.

Shared sprint, separate project backlogs: the team runs one sprint together. Each project has its own backlog. Sprint planning pulls from all project backlogs into a single sprint backlog. Each person's capacity distributes across projects based on current priorities. This works when projects are similar in nature and team members are interchangeable across them. The risk: context switching costs 15–20 minutes of focus recovery per switch. A team member touching 4 projects in one day may produce less than one touching 2.

Project sub-teams with a shared sprint rhythm: group team members into loose project clusters. Designer A and Copywriter B focus on Client X this sprint; Designer C and Copywriter D focus on Client Y. Everyone runs the same sprint dates and attends a shared standup. Each sub-team manages their own sprint backlog. This works well for complex, long-running projects that need sustained focus. The risk: sub-teams become siloed over time.

Fixed capacity allocation per project: assign each team member a fixed percentage of their capacity per active project. A designer at full capacity allocates 40% to Project A, 30% to Project B, 20% to Project C, and 10% to internal work. Sprint planning respects these percentages. Most practical for agencies running 5–8 projects simultaneously, but requires honest tracking and a clear lead for each major engagement.

Four rules that apply regardless of which approach the team uses:

Every piece of work lives in someone's sprint backlog. Work outside the sprint backlog is invisible and unmanageable. If it isn't in a backlog, it won't get planned, tracked, or delivered on time.

Context switches get batched by day where possible. If a designer works across two projects, designate Monday–Wednesday for Project A and Thursday–Friday for Project B, not mixed hour by hour.

Sprint reviews happen per project. Clients see their project's completed work, not a combined demo of everything the team shipped.

New projects enter the next sprint, not the current one. This rule requires buy-in from account leads before Sprint 1. Without it, new work keeps getting added to active sprints and the backlog stops reflecting reality.

• Shared sprint + separate backlogs: best when team members are interchangeable across projects
• Sub-teams + shared rhythm: best for complex, long-running projects needing sustained focus
• Fixed % allocation per project: most practical for agencies running 5–8 projects at once
• Batch context switches by day — the recovery cost per switch is 15–20 minutes of focus
• Reviews per project, not per sprint — clients see their work, not a combined demo
• New projects enter next sprint — enforce this before Sprint 1, not when it first becomes a problem