What This Template Is For
A sprint commitment is the team's explicit statement of what they plan to deliver in a sprint and the conditions under which that commitment is valid. Most teams plan sprints informally: they pull stories into a sprint, nod in agreement, and hope for the best. When things slip, there is no shared record of what was actually agreed to, what the capacity assumptions were, or which risks were flagged at the start.
This template creates accountability without blame. It documents what the team commits to, what they are stretching for, what capacity they have, and what could go wrong. At the end of the sprint, the team can compare the commitment against reality and learn from the delta. Over time, commitment accuracy improves because the team starts being honest about capacity, dependencies, and risk rather than optimistic about all three.
This template is filled out during sprint planning and reviewed during the sprint retrospective. For the broader sprint planning process, see the sprint planning template. The capacity planning template provides a more detailed approach to capacity allocation across sprints.
How to Use This Template
- Complete this template at the end of sprint planning, after stories have been selected and estimated.
- The PM or Scrum Master facilitates. The full team reviews and agrees before the sprint starts.
- Separate committed items from stretch items. Committed items are what the team is confident they can deliver. Stretch items are aspirational.
- Document capacity assumptions explicitly. If someone is out for 2 days or has a production support rotation, record it.
- List known risks and dependencies. These are not excuses. They are the conditions that the commitment is based on.
- Review this document at sprint retro. Compare planned vs. actual. Look for patterns.
The Template
Sprint Overview
| Field | Details |
|---|---|
| Sprint Number | [e.g., Sprint 24] |
| Sprint Dates | [Start date] to [End date] |
| Sprint Duration | [e.g., 2 weeks] |
| Sprint Goal | [One sentence describing the sprint's primary objective] |
| Team | [Team name] |
| Commitment Date | [Date this commitment was made] |
Capacity
| Team Member | Role | Available Days | Notes |
|---|---|---|---|
| [Name 1] | [PM/Eng/Design] | [e.g., 9/10] | [e.g., PTO Friday] |
| [Name 2] | [PM/Eng/Design] | [e.g., 10/10] | |
| [Name 3] | [PM/Eng/Design] | [e.g., 7/10] | [e.g., On-call rotation M-W] |
| [Name 4] | [PM/Eng/Design] | [e.g., 10/10] | |
| [Name 5] | [PM/Eng/Design] | [e.g., 8/10] | [e.g., Conference Thu-Fri] |
| Total Engineering Days | [Sum] | ||
| Effective Capacity (70%) | [Sum x 0.7] | Accounts for meetings, reviews, overhead |
Committed Items
Items the team is confident they will complete within the sprint:
| # | Story / Task | Points | Owner | Dependencies | Status |
|---|---|---|---|---|---|
| 1 | [Story title] | [pts] | [Name] | [None / Blocked by X] | Not Started |
| 2 | [Story title] | [pts] | [Name] | Not Started | |
| 3 | [Story title] | [pts] | [Name] | Not Started | |
| 4 | [Story title] | [pts] | [Name] | Not Started | |
| 5 | [Story title] | [pts] | [Name] | Not Started | |
| Total Committed | [Sum] |
Stretch Items
Items the team will attempt if committed items are completed early:
| # | Story / Task | Points | Owner | Notes |
|---|---|---|---|---|
| S1 | [Story title] | [pts] | [Name] | [Why this is stretch, not committed] |
| S2 | [Story title] | [pts] | [Name] | |
| Total Stretch | [Sum] |
Dependencies
| Dependency | Owner (External) | Status | Impact If Not Resolved | Date Needed |
|---|---|---|---|---|
| [e.g., API access from Platform team] | [Name/Team] | Confirmed / At Risk / Unknown | [Which committed items are blocked] | [Date] |
| [e.g., Design review for feature X] | [Name/Team] | |||
| [e.g., Third-party vendor approval] | [Name/Team] |
Known Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [Risk 1] | High / Medium / Low | [Which items affected] | [What we will do if this happens] |
| [Risk 2] | |||
| [Risk 3] |
Commitment Confidence
Team confidence that all committed items will be delivered:
- ☐ High (90%+): Strong capacity, few dependencies, well-understood stories
- ☐ Medium (70-89%): Some unknowns but manageable, dependencies are tracked
- ☐ Low (50-69%): Significant risks or unknowns. Consider reducing scope.
If confidence is Low, what would increase it?
[List specific actions that would increase confidence, e.g., "Resolve dependency X before Wednesday"]
Filled Example: Growth Squad, Sprint 24
Sprint Overview
| Field | Details |
|---|---|
| Sprint Number | Sprint 24 |
| Sprint Dates | March 3 to March 14, 2026 |
| Sprint Duration | 2 weeks |
| Sprint Goal | Ship the self-serve onboarding flow for free-tier users |
| Team | Growth Squad |
| Commitment Date | March 3, 2026 |
Capacity
| Team Member | Role | Available Days | Notes |
|---|---|---|---|
| Sarah | PM | 10/10 | |
| James | Eng Lead | 9/10 | PTO Friday March 14 |
| Maya | Designer | 8/10 | Design review committee Wed afternoons |
| Alex | Backend Eng | 10/10 | |
| Priya | Frontend Eng | 7/10 | On-call rotation March 3-5 |
| Total Engineering Days | 26 | (James + Alex + Priya eng days only) | |
| Effective Capacity (70%) | 18.2 |
Committed Items
| # | Story / Task | Points | Owner | Dependencies | Status |
|---|---|---|---|---|---|
| 1 | Onboarding wizard: step 1 (account setup) | 3 | Priya | Design complete (confirmed) | Not Started |
| 2 | Onboarding wizard: step 2 (workspace config) | 5 | Alex | API endpoint from Platform team | Not Started |
| 3 | Onboarding wizard: step 3 (invite teammates) | 3 | Priya | None | Not Started |
| 4 | Onboarding progress tracking API | 3 | Alex | None | Not Started |
| 5 | Onboarding analytics events | 2 | James | None | Not Started |
| 6 | Bug fix: password reset flow timeout | 1 | James | None | Not Started |
| Total Committed | 17 |
Stretch Items
| # | Story / Task | Points | Owner | Notes |
|---|---|---|---|---|
| S1 | Onboarding completion email trigger | 3 | Alex | Depends on email service migration (in progress) |
| S2 | A/B test: 3-step vs. 5-step onboarding | 2 | Priya | Needs experiment framework setup |
| Total Stretch | 5 |
Dependencies
| Dependency | Owner (External) | Status | Impact If Not Resolved | Date Needed |
|---|---|---|---|---|
| Workspace config API endpoint | Platform team (David) | Confirmed for March 5 | Blocks Story #2 | March 5 |
| Email service migration | Infra team (Lee) | In progress, ETA March 10 | Blocks Stretch S1 | March 10 |
Known Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Platform API delayed past March 5 | Low | Story #2 blocked, 5 points at risk | Alex works on Story #4 first, revisit Wednesday |
| Priya pulled into P0 during on-call | Medium | Stories #1 and #3 delayed | James can pick up frontend stories if needed |
Commitment Confidence
- ☑ Medium (70-89%): Some unknowns but manageable, dependencies are tracked
If confidence is Low, what would increase it? N/A. Confidence is medium due to Priya's on-call overlap. Will reassess Wednesday after on-call ends.
Tips for Better Sprint Commitments
Use the 70% capacity rule. Teams consistently overcommit when they plan for 100% of available time. Meetings, code reviews, Slack interruptions, and context switching consume 30%+ of each day. Plan for 70% of available engineering days. For more on capacity allocation, the capacity allocation template provides a detailed breakdown.
Separate confidence from hope. Committed items should have 90%+ probability of completion. If the team is not confident about a story, it is a stretch item. There is no shame in having fewer committed points and more stretch points. The goal is predictability, not heroics.
Track accuracy over time. After 5-6 sprints with this template, calculate your commitment accuracy: (committed points delivered / committed points planned). A healthy team is 80-90% accurate. Below 70% means systemic overcommitment. Above 95% means the team is sandbagging. Use the velocity tracking template to spot trends.
Dependencies are the number one risk. If a committed item depends on another team, treat it as medium risk regardless of verbal assurances. Verbal confirmations are not commitments. A dependency is only "confirmed" when the code is merged or the artifact is delivered.
Review at retro, not just standup. The sprint commitment document should be pulled up during the team retrospective. Compare planned vs. actual. Discuss why items slipped. Adjust the process. This feedback loop is what makes commitments more accurate over time.