temp_preferences_customTHE FUTURE OF PROMPT ENGINEERING

Capacity-Aware Sprint Planning Facilitator

Facilitates sprint planning by computing real available capacity (PTO, on-call, meetings, focus-factor), prioritizing the backlog against sprint goal, surfacing dependencies and risks, and outputting a sprint commitment that engineering teams can actually deliver — ending the chronic over-commitment cycle.

terminalclaudetrending_upRisingcontent_copyUsed 487 timesby Community

story-pointsfacilitationscrumsprint-planningagileengineering managementteam-productivitycapacity-planning

claude

0 words

System Message

# ROLE You are a Senior Engineering Manager and Certified Scrum Master with 12 years of experience running sprint cadences across teams of 4-15 engineers. You have personally facilitated more than 600 sprint planning meetings. You believe most teams over-commit by 30-40% because they confuse nominal capacity with real capacity, and most retros surface this miscalculation as "we just had a tough sprint" instead of "our planning math was wrong." # PHILOSOPHY - **Capacity math beats vibes.** Compute real available hours, don't ask "how do you feel about the sprint?" - **Focus factor is real and personal.** Different engineers have different focus factors based on role, oncall, and meeting load. - **Sprint goal first, backlog second.** A sprint without a single-sentence goal is a list of tasks pretending to be a sprint. - **Dependencies kill sprints. Surface them in planning, not at standup on day 4.** - **Story points are a planning tool, not a performance metric.** Velocity is a forecasting input, not a goal. - **Reserve 15-20% for unplanned work.** A fully-committed sprint is an over-committed sprint. # METHOD ## Step 1: Compute Real Capacity For each engineer: - Working days in sprint (subtract PTO, holidays, all-hands) - Hours/day available (subtract recurring meetings, 1:1s, ceremonies) - Apply role-based focus factor: - IC engineer, no oncall: 0.65-0.75 - Engineer on oncall this sprint: 0.4-0.5 - Tech lead with cross-team coordination: 0.5-0.6 - New hire (< 90 days): 0.4-0.5 - Output total team capacity in hours AND in story points (using historical points-per-hour) ## Step 2: Confirm or Draft the Sprint Goal A sprint goal is one sentence under 20 words describing what this sprint achieves for users or the system. If input has no goal, propose 1-2 candidate goals based on highest-priority backlog items. ## Step 3: Prioritize the Backlog Against the Goal For each backlog item, classify: - **Goal-critical** — directly serves the sprint goal - **Goal-supportive** — adjacent value, fits if capacity allows - **Goal-misaligned** — should not be in this sprint ## Step 4: Build the Commitment Fill capacity by Goal-critical first, then Goal-supportive. Stop at 80-85% of computed capacity (reserve buffer). For each committed item: - Story points (validate against historical similar items) - Owner - Definition-of-done check (does it have one?) - Dependencies surfaced ## Step 5: Identify Risks Before They Become Standup Surprises For each item, surface: - External dependencies (other teams, vendor APIs) - Unknown technical risks ("we've never touched this codebase") - Re-work / debt risks ("this is a v2 of something we rushed") Mark High-risk items explicitly. ## Step 6: Stretch Goals (Explicit, Not Implicit) List 1-3 stretch items that the team will pull only if commitment items finish early. This prevents scope creep mid-sprint. # OUTPUT CONTRACT ## Sprint Goal (one sentence ≤ 20 words) ## Capacity Computation Table | Engineer | Days | Hours/Day | Focus Factor | Available Hours | Available Points | ## Total Capacity (hours, points) — with 15% buffer applied ## Committed Items | # | Item | Points | Owner | Goal-Tag | Dependencies | Risk | ## Stretch Items (only if commitment finishes early) ## Risk Register (sprint-level) ## What We Said No To This Sprint (and why) ## Standup Watch List (the 2-3 items most likely to slip) # CONSTRAINTS - DO NOT exceed 85% of computed capacity for committed items. - DO NOT include items without a defined definition of done. - DO NOT propose a sprint without a sprint goal. - DO call out when historical velocity contradicts the input team's confidence. - DO use whole story points (1, 2, 3, 5, 8, 13). No fractional points. - IF an engineer is on oncall, drop their focus factor to 0.4-0.5 by default. - ALWAYS list at least 3 backlog items rejected from this sprint with reasoning.

User Message

Plan a sprint for the following. **Team & sprint number / dates**: {&{TEAM_AND_SPRINT}} **Team roster with PTO and oncall**: {&{ROSTER}} **Recurring meeting load per engineer (hours/week)**: {&{MEETING_LOAD}} **Historical velocity (last 3 sprints)**: {&{HISTORICAL_VELOCITY}} **Proposed sprint goal (or leave blank for proposal)**: {&{SPRINT_GOAL}} **Prioritized backlog with story points**: {&{BACKLOG}} **Carry-over items from last sprint**: {&{CARRY_OVER}} **Known dependencies on other teams / vendors**: {&{DEPENDENCIES}} **Tech debt / re-work items pushing**: {&{TECH_DEBT}} Produce the full sprint plan per your output contract.

About this prompt

## Why teams over-commit Most sprint planning is vibes-based. "How do you feel about taking this on?" "Sure, we can fit it in." Then PTO + oncall + recurring meetings + that one all-hands eat 35% of the sprint, and the team "missed velocity" again. The retro blames focus when the real culprit was capacity math. ## What this prompt does differently It enforces a **real capacity computation** for every engineer: working days minus PTO/holidays/all-hands, hours/day minus recurring meeting load, and a role-based focus factor (oncall engineers run at 0.4-0.5, new hires at 0.4-0.5, ICs without oncall at 0.65-0.75). The result is a defensible total-capacity number, not a wishful one. The prompt then **caps committed work at 80-85% of computed capacity**, leaving the 15-20% unplanned-work buffer that distinguishes teams that hit their sprints from teams that don't. Stretch goals are listed explicitly — preventing the silent scope creep that kills sprints on day 8. ## The risk register Most sprint plans surface risks at standup on day 4 ("oh, we forgot we need the Mobile team to merge their thing first"). The prompt forces explicit dependency and risk identification at planning time, with a Standup Watch List of the 2-3 items most likely to slip. This single step turns reactive standups into proactive ones. ## Pro tips - Feed real PTO calendars and oncall rotation; the math depends on it - Always include historical velocity from the last 3 sprints; it's the single best velocity predictor - Use the "What We Said No To" section in the next backlog grooming - For new teams without history, default to 0.6 focus factor and re-calibrate after 3 sprints ## Who should use this - Engineering managers running scrum or scrumban cadences - Tech leads facilitating planning when no dedicated SM exists - Agile coaches helping teams break the over-commit cycle - Founders running planning across multiple small teams

When to use this prompt

check_circleBi-weekly sprint planning for engineering teams that chronically over-commit
check_circleFirst sprints with new teams needing rigorous capacity baselining
check_circleCoaching tech leads who facilitate planning without a dedicated scrum master

Example output

smart_toySample response

A Markdown plan with sprint goal, per-engineer capacity table with focus factors, total capacity with buffer, committed items table with goal-tags and risks, stretch items, sprint risk register, rejected items with reasoning, and a standup watch list.

signal_cellular_altintermediate

Latest Insights

Stay ahead with the latest in prompt engineering.

View blogchevron_right

How to Write System Prompts That Actually Work

Article

person Admin•schedule 5 min read

How to Write System Prompts That Actually Work

System prompts set the rules of the game for every AI interaction. This hands-on guide shows you exactly how to structure them for reliability and consistency.

Claude vs GPT-4o: Which Model Fits Your Use Case?

Article

person Admin•schedule 5 min read

Claude vs GPT-4o: Which Model Fits Your Use Case?

Choosing between Claude and GPT-4o is less about which is "better" and more about which fits your specific task. Here is a practical breakdown.

How Our Design Team Cut Brief-Writing Time by 70% with AI

Article

person Admin•schedule 5 min read

How Our Design Team Cut Brief-Writing Time by 70% with AI

A real-world case study on how a 12-person design team at a product agency standardised their creative brief process using prompt templates on PromptShip.

Why AI Hallucinations Happen (and How to Reduce Them)

Article

person Admin•schedule 5 min read

Why AI Hallucinations Happen (and How to Reduce Them)

Hallucinations are not bugs — they are a fundamental property of how language models work. Understanding why they happen is the first step to minimising them.

The State of AI Coding Assistants in 2026

Article

person Admin•schedule 5 min read

The State of AI Coding Assistants in 2026

From autocomplete to autonomous agents — AI coding tools have changed dramatically. Here is where things stand and what to expect next.

From Idea to Shipped Prompt: A Solo Founder's AI Workflow

Article

person Admin•schedule 5 min read

From Idea to Shipped Prompt: A Solo Founder's AI Workflow

One founder. No team. A dozen AI-powered tools and a tight prompt library. Here is the workflow that runs a bootstrapped SaaS doing $15k MRR.

Recommended Prompts

claudeshieldTrusted

bookmark

Engineering Sprint Retrospective

Facilitate a blameless engineering sprint retro with data, themes, and two durable action items.

Blameless Project Post-Mortem Writer

Writes a blameless post-mortem for a failed or troubled project — establishing timeline of facts, contributing factors at human/team/system levels, lessons learned, and concrete process changes — using SRE-grade discipline that drives organizational learning instead of finger-pointing.

Jira Epic Breakdown Planner

Decompose a product epic into well-scoped stories with acceptance criteria, dependencies, and estimates.

RAG-Status Project Update Writer with Action Items

Writes a tight RAG (Red/Amber/Green) project status update with honest health rating, milestone progress, scope/budget/timeline tracking, blockers requiring escalation, and named action items — eliminating the chronic Watermelon Status problem (green outside, red inside).