How to Run Execution Sprints That Actually Ship
·ScaledByDesign·
sprintsexecutionshippingprocess
The Sprint That Ships Nothing
Here's how most sprints work: Monday planning takes 3 hours. The team commits to 10 stories. By Wednesday, 3 new "urgent" items are added. By Friday, 4 stories are "in progress" and none are done. The retro identifies "scope creep" as the problem. Next sprint, repeat.
This isn't agile. It's organized chaos with a calendar.
What an Execution Sprint Actually Looks Like
The Rules
- Fixed scope — what's committed on Monday is what ships on Friday. Nothing added, nothing removed
- Clear ownership — every story has one person responsible, not a team
- Definition of done — not "code complete," but "deployed, tested, and verified by the business"
- No meetings during the sprint — planning happens before, retro happens after, the middle is for building
- Daily standup is 10 minutes max — blockers only, not status updates
The Structure
Pre-Sprint (Friday before):
30 min: Sprint lead selects work from prioritized backlog
30 min: Each story gets: owner, acceptance criteria, estimate
Result: Locked sprint scope
Monday:
15 min: Team reviews the plan, raises concerns
Remainder: Building starts immediately
Tuesday-Thursday:
10 min daily: Blockers only standup
Remainder: Building, reviewing, deploying
Stories move: To Do → In Progress → In Review → Done
Friday:
Morning: Final deployments and verification
30 min: Sprint review (demo to stakeholders)
30 min: Retro (what to improve, one action item max)
The Story Template That Prevents Scope Creep
Every story follows this format before entering a sprint:
## [Story Title]
**Owner:** [One person]
**Estimate:** [In hours, not points]
### What
[2-3 sentences describing what will be built]
### Why
[1 sentence connecting to business goal]
### Acceptance Criteria
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]
### Out of Scope
- [Explicitly list what this story does NOT include]
- [This prevents scope creep mid-sprint]
### Definition of Done
- [ ] Code reviewed and merged
- [ ] Deployed to production
- [ ] Acceptance criteria verified by [person]
- [ ] Monitoring confirms no errorsThe "Out of Scope" section is the most important part. It's the boundary that keeps a 2-day story from becoming a 2-week project.
The Estimation Framework
Stop using story points. Use hours. Here's why:
Story points: "This is a 5-pointer"
→ What does that mean? Nobody agrees.
→ Does it include testing? Code review? Deployment?
→ A "5" for a senior is a "13" for a junior.
Hours: "This is 12 hours of work"
→ Clear. Measurable. Verifiable.
→ Includes: implementation, testing, review, deployment
→ If it takes 20 hours, we know we were 67% off
The Sizing Rules
| Estimate | Action |
|---|---|
| < 4 hours | Ship it this sprint |
| 4-16 hours | Standard sprint story |
| 16-40 hours | Break it into smaller stories |
| > 40 hours | This is a project, not a story — needs a spike first |
The single most important rule: If a story can't be finished in one sprint, it's too big. Break it down until every piece is independently shippable.
Protecting the Sprint
The "Urgent" Request Protocol
When something "urgent" comes in mid-sprint:
Step 1: Is it actually urgent?
→ "Revenue is currently being lost" = Yes
→ "A customer asked for this" = No
→ "The CEO wants it" = Maybe (ask why)
Step 2: If truly urgent, what gets removed?
→ Equal hours out for hours in
→ Sprint lead decides, not the requester
→ Document the swap and the reason
Step 3: Track interruptions
→ Monthly report: how many mid-sprint changes
→ If > 20% of sprint capacity changes, fix the planning process
The Blocker Protocol
Blocked for < 2 hours:
→ Try to solve it yourself
→ Ping the relevant person in Slack
Blocked for 2-4 hours:
→ Raise in standup
→ Sprint lead pairs you with help or removes the blocker
Blocked for > 4 hours:
→ Story gets swapped out
→ Blocker becomes a priority for next sprint
→ Don't let one blocked story kill the whole sprint
Measuring Sprint Health
Track these metrics every sprint:
| Metric | Healthy | Concerning | Broken |
|---|---|---|---|
| Commitment completion | > 80% | 60-80% | < 60% |
| Mid-sprint scope changes | 0-1 stories | 2-3 stories | > 3 stories |
| Stories carried over | 0-1 | 2-3 | > 3 |
| Estimation accuracy | ±20% | ±50% | > ±50% |
| Retro action items completed | 100% | 50-100% | < 50% |
The Velocity Chart That Matters
Don't track velocity as an absolute number. Track the trend:
Sprint 1: Committed 8, Completed 5 (62%)
Sprint 2: Committed 7, Completed 5 (71%)
Sprint 3: Committed 6, Completed 5 (83%)
Sprint 4: Committed 6, Completed 6 (100%)
Sprint 5: Committed 7, Completed 6 (86%)
The team learned to commit to what they can actually finish.
Velocity went DOWN. Throughput went UP.
The Sprint Retro That Actually Improves Things
Format (30 minutes max):
5 min: What shipped? (celebrate wins)
10 min: What blocked us? (identify friction)
10 min: One action item (not three, ONE)
5 min: Did last sprint's action item get done?
Rules:
- Max ONE improvement action item per retro
- Action item has an owner and a deadline
- If last sprint's action item didn't get done,
that IS this sprint's action item
- No blame, only systems thinking
The Execution Sprint Advantage
Teams that run disciplined execution sprints see:
- 2-3x throughput — not from working faster, but from finishing what they start
- 80% fewer "urgent" interruptions — because the process forces the conversation
- Higher team morale — engineers like shipping, not re-planning
- Better stakeholder trust — when you ship what you commit to, people stop micromanaging
Execution sprints aren't about moving faster. They're about finishing things. Speed comes from focus, not effort.