Delivery Commitment Map
Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output.
What This Skill Produces
- Sprint Goal - single, outcome-focused sentence the whole team can rally around
- Sprint Backlog - prioritised list of user stories with story point estimates and acceptance criteria
- Capacity Plan - team availability breakdown accounting for holidays, meetings, and focus time
- Sprint Planning Agenda - structured 2-hour meeting agenda with timings
- Risk Flags - blockers or dependencies that could derail the sprint
Inputs to Request From User
Ask for (if not already provided):
- Sprint duration (1 or 2 weeks)
- Team size and velocity (average story points per sprint)
- Top 3–5 backlog items or epics to pull from
- Any known absences, holidays, or team events
- Previous sprint's incomplete items (carry-overs)
Sprint Goal Formula
Use this structure:
"This sprint we will [deliver X outcome] so that [user/business benefit], measured by [success indicator]."
Never write sprint goals as task lists. Always outcome-first.
Story Point Calibration
| Complexity |
Points |
Description |
| Trivial |
1 |
Clearly understood, no unknowns |
| Small |
2 |
Straightforward, minor effort |
| Medium |
3 |
Some complexity, clear path |
| Large |
5 |
Complex, needs design or research |
| Very Large |
8 |
High uncertainty, may need splitting |
| Epic |
13+ |
Too large - must be split before sprint |
Flag any item estimated at 8+ and recommend splitting.
Capacity Formula
Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor
Focus hours/day: 6 (accounting for meetings, Slack, admin)
Availability factor: 0.7–0.85 depending on holidays/events
Story points to commit = Historical velocity × Availability factor
Output Format
Sprint [N] - [Start Date] to [End Date]
Sprint Goal:
[Goal statement]
Team Capacity: [X] story points available (based on [Y] team members, [Z]% availability)
Sprint Backlog:
| Priority |
Story |
Points |
Owner |
Acceptance Criteria |
| 1 |
[Story title] |
[N] |
[Team member] |
[When X then Y] |
Carry-Overs from Previous Sprint:
- [Item] - Reason for carry-over: [brief explanation]
Risks & Dependencies:
- [Risk description] → Mitigation: [action]
Sprint Planning Agenda:
- 00:00–00:10 - Review sprint goal and team capacity
- 00:10–00:40 - Walk through backlog items, confirm estimates
- 00:40–01:20 - Assign stories, identify dependencies
- 01:20–01:50 - Review acceptance criteria per story
- 01:50–02:00 - Confirm sprint commitment and close
Guidelines
- Always challenge stories missing acceptance criteria - flag them explicitly
- Recommend the team commits to 80% of available capacity, not 100%
- If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point
- Highlight any story with unclear ownership as a blocker
Quality Checks
1---2name: delivery-commitment-map3description: Create a delivery plan with goals, capacity, scope, risks, and commitments.4---56# Delivery Commitment Map78Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output.910## What This Skill Produces1112- **Sprint Goal** - single, outcome-focused sentence the whole team can rally around13- **Sprint Backlog** - prioritised list of user stories with story point estimates and acceptance criteria14- **Capacity Plan** - team availability breakdown accounting for holidays, meetings, and focus time15- **Sprint Planning Agenda** - structured 2-hour meeting agenda with timings16- **Risk Flags** - blockers or dependencies that could derail the sprint1718## Inputs to Request From User1920Ask for (if not already provided):21- Sprint duration (1 or 2 weeks)22- Team size and velocity (average story points per sprint)23- Top 3–5 backlog items or epics to pull from24- Any known absences, holidays, or team events25- Previous sprint's incomplete items (carry-overs)2627## Sprint Goal Formula2829Use this structure:30> "This sprint we will [deliver X outcome] so that [user/business benefit], measured by [success indicator]."3132Never write sprint goals as task lists. Always outcome-first.3334## Story Point Calibration3536| Complexity | Points | Description |37|---|---|---|38| Trivial | 1 | Clearly understood, no unknowns |39| Small | 2 | Straightforward, minor effort |40| Medium | 3 | Some complexity, clear path |41| Large | 5 | Complex, needs design or research |42| Very Large | 8 | High uncertainty, may need splitting |43| Epic | 13+ | Too large - must be split before sprint |4445Flag any item estimated at 8+ and recommend splitting.4647## Capacity Formula4849```50Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor51Focus hours/day: 6 (accounting for meetings, Slack, admin)52Availability factor: 0.7–0.85 depending on holidays/events53Story points to commit = Historical velocity × Availability factor54```5556## Output Format5758### Sprint [N] - [Start Date] to [End Date]5960**Sprint Goal:**61> [Goal statement]6263**Team Capacity:** [X] story points available (based on [Y] team members, [Z]% availability)6465**Sprint Backlog:**6667| Priority | Story | Points | Owner | Acceptance Criteria |68|---|---|---|---|---|69| 1 | [Story title] | [N] | [Team member] | [When X then Y] |7071**Carry-Overs from Previous Sprint:**72- [Item] - Reason for carry-over: [brief explanation]7374**Risks & Dependencies:**75- [Risk description] → Mitigation: [action]7677**Sprint Planning Agenda:**78- 00:00–00:10 - Review sprint goal and team capacity79- 00:10–00:40 - Walk through backlog items, confirm estimates80- 00:40–01:20 - Assign stories, identify dependencies81- 01:20–01:50 - Review acceptance criteria per story82- 01:50–02:00 - Confirm sprint commitment and close8384## Guidelines8586- Always challenge stories missing acceptance criteria - flag them explicitly87- Recommend the team commits to 80% of available capacity, not 100%88- If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point89- Highlight any story with unclear ownership as a blocker9091## Quality Checks9293- [ ] Sprint goal is outcome-focused (not "implement X" - something like "users can do Y")94- [ ] Team capacity is calculated using actual availability, not theoretical 100%95- [ ] Every story has an acceptance criterion (flag any that don't)96- [ ] Stories estimated at 8+ points are flagged for splitting97- [ ] Carry-overs from last sprint are accounted for in capacity
danielpradilla