Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

sprint-delivery-management

Étoiles3

Forks0

Mis à jour24 février 2026 à 19:30

Drive predictable delivery without micromanaging the engineering team. Covers sprint planning, blocker removal, scope negotiation, and knowing when to cut vs. push. Use when sprints consistently miss commitments, scope keeps creeping, or delivery feels chaotic.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

Dragoon0x

Dragoon0x/product-skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Spécialistes en gestion de projetsProfessions des affaires et des opérations financières·SOC 13-1082

SKILL.md

readonly

name	sprint-delivery-management
description	Drive predictable delivery without micromanaging the engineering team. Covers sprint planning, blocker removal, scope negotiation, and knowing when to cut vs. push. Use when sprints consistently miss commitments, scope keeps creeping, or delivery feels chaotic.

Sprint Delivery Management

Drive predictable delivery through clarity, not control.

How to use

/sprint-delivery-management Apply 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

Plus depuis ce dépôt

même dépôt

cross-functional-alignment

Dragoon0x/product-skills

Bring engineering, design, research, marketing, and sales onto the same page and keep them there. Covers alignment levels, RACI clarity, and continuous maintenance. Use when teams have different understandings of what's being built, cross-team dependencies are causing problems, or alignment keeps breaking down.

2026-02-243

influencing-without-authority

Dragoon0x/product-skills

Get buy-in and drive alignment when you have no direct power over the people you need to move. Covers stakeholder framing, pre-wiring decisions, and building credibility over time. Use when pushing for a direction without exec authority, navigating disagreements, or when a proposal keeps getting blocked.

2026-02-243

managing-up

Dragoon0x/product-skills

Build a productive relationship with leadership by communicating effectively, managing expectations, and knowing when to push back. Use when navigating executive relationships, seeking alignment on direction, or when leadership requests conflict with team capacity.

2026-02-243

working-with-design

Dragoon0x/product-skills

Partner with design to create better products, not just prettier ones. Covers when to involve design, how to give useful feedback, and respecting the design process. Use when PM-design handoffs feel clunky, design feedback conversations are unproductive, or design is brought in too late.

2026-02-243

working-with-engineering

Dragoon0x/product-skills

Partner with engineering as a collaborator, not a ticket-writer. Covers communication norms, technical empathy, scope negotiation, and building mutual trust. Use when PM-engineering relationships feel transactional, technical decisions are made without product input, or scope conversations become adversarial.

2026-02-243

working-with-gtm

Dragoon0x/product-skills

Partner with marketing, sales, and customer success to bring products to market effectively. Covers launch coordination, sales enablement, and feedback loops. Use when launches aren't driving adoption, sales can't articulate the value prop, or customer feedback isn't reaching the product team.

2026-02-243

name	sprint-delivery-management
description	Drive predictable delivery without micromanaging the engineering team. Covers sprint planning, blocker removal, scope negotiation, and knowing when to cut vs. push. Use when sprints consistently miss commitments, scope keeps creeping, or delivery feels chaotic.

Sprint Delivery Management

Drive predictable delivery through clarity, not control.

How to use

/sprint-delivery-management Apply 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