sprint-delivery-management
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
More from dragoon0x/product-skills
prd-writing
Write product requirement documents that engineers want to read and can actually build from. Covers structure, scope discipline, and the balance between clarity and over-specification. Use when writing PRDs, reviewing spec quality, or when engineering keeps asking clarifying questions.
1freemium-vs-paid-gate
Decide whether a product should offer a free tier, free trial, or go straight to paid. Structured decision framework based on economics, distribution model, and competitive landscape. Use when launching a new product or reconsidering your pricing model.
1error-recovery
When things break, guide people forward instead of leaving them stranded. Error message copy, retry patterns, graceful degradation, and recovery flows. Use when building error handling or failed state UIs.
1cta-patterns
Design calls-to-action that people actually click. Covers button copy, placement logic, urgency without manipulation, and progressive commitment. Use when reviewing pages for conversion potential or when CTA copy feels generic.
1onboarding-flow
Design first-run experiences that create the aha moment fast. Reduces time-to-value by sequencing actions, progressive disclosure, and contextual guidance. Use when building signup flows, product tours, or empty states.
1user-psychology
Apply motivation, friction, and trust patterns to product decisions. Maps cognitive biases and behavioral triggers to specific UI and copy choices. Use when reviewing flows for drop-off points or when something feels right but doesn't convert.
1