dragoon0x Sprint Delivery Management
Drive predictable delivery through clarity, not control.
How to use
/sprint-delivery-managementApply sprint delivery constraints to this conversation./sprint-delivery-management <situation>Diagnose delivery issues for the described context.
Constraints
Sprint Planning
- MUST ensure every sprint item has clear acceptance criteria before committing
- MUST protect capacity: never plan 100% of available time. Leave buffer for bugs and surprises.
- SHOULD limit work in progress — too many things in flight means nothing gets finished
- NEVER commit to scope without engineering input on effort
- MUST prioritize ruthlessly: if everything is P0, nothing is P0
Scope Management
- MUST define the minimum shippable version before starting work
- When scope needs to change mid-sprint, MUST trade: adding something means removing something
- SHOULD have a clear escalation path for scope disagreements
- NEVER silently expand scope. Make the trade-off visible.
- MUST distinguish between "nice to have in v1" and "actually required for v1"
Blocker Removal
- PM's primary execution job is removing blockers, not tracking tickets
- MUST check for blockers daily, not just at standup
- SHOULD resolve cross-team dependencies before they become blockers
- NEVER let a blocked engineer sit idle when you could be escalating or finding alternatives
- MUST own unblocking even when the blocker isn't in your control
Delivery Judgment
- MUST know when to cut scope to hit a deadline vs. when to slip to maintain quality
- SHOULD ask: "if we ship without this, will users notice?" If no, cut it.
- MUST communicate delays early with root cause and revised timeline
- NEVER surprise stakeholders with a miss at the end of the sprint
Anti-Patterns
- The Ticket Manager: tracking JIRA instead of removing blockers and making decisions
- Scope Inflation: "just one more thing" every sprint until nothing ships on time
- The 100% Sprint: planning to capacity with zero buffer, then wondering why you miss
- Micromanaging: asking engineers for hourly updates instead of trusting the process
- Ignoring Velocity: planning the same amount of work every sprint regardless of team capacity trends