| name | piper-sprint-plan |
| description | Scope a sprint from the GitHub backlog — review open issues, apply capacity and velocity, surface dependencies and risks, and produce a proposed sprint with rationale. Works without GitHub connector (manually-supplied backlog) but is significantly richer with it. Trigger phrases: "let's plan the sprint", "help me scope [sprint name]", "what should go in this sprint", "which issues should we tackle next". |
sprint-plan
Scope a sprint from your backlog — select what to pull in, flag what to leave out, surface dependencies, and produce a proposed sprint with rationale PM can accept, adjust, or reject.
Why this exists
Sprint planning without a thinking partner defaults to: PM opens the backlog, picks things they recognize, fills up until it feels full, and hopes it's right. The failure modes are predictable:
- Pulling in work without considering what it blocks or what it depends on
- Capacity optimism (sprints fill at 100%; velocity is usually 60–80%)
- Missing the 1–2 high-leverage issues that would advance the product most
- No explicit "and therefore we're NOT doing X" reasoning
Piper's value here isn't running the planning for PM — it's being the thinking partner who asks the right questions before the sprint starts.
With the GitHub connector: Piper can pull actual open issues, read their labels and milestone assignments, check closed-issue velocity, and propose a specific sprint scope.
Without the GitHub connector: Piper asks PM to supply the candidate list and works as a structured sounding board — better than solo planning, just not automated.
Procedure
Step 1 — Establish the planning frame
Confirm with PM:
- Sprint length: 1 week / 2 weeks / other
- Team / capacity: who's working this sprint, any known absences
- Velocity reference: how many issues/points does the team typically close? (If unknown, estimate from recent sprints)
- Sprint goal: is there a theme or outcome this sprint is organizing around? (Optional, but dramatically improves selection)
- Any fixed constraints: must-have items (committed work, customer asks), must-exclude items (blocked, not ready)
Step 2 — Pull or receive the backlog
With GitHub connector:
- Query open issues from the relevant milestone or label
- Filter to: unblocked items (no open blockers filed against them) + not assigned to a future milestone explicitly
- Sort by: priority label if present, then by age (older backlog items often represent forgotten important work)
- Surface top 2× velocity as candidates (more than will fit, so selection is deliberate)
Without GitHub connector:
- Ask PM to provide the candidate list: "Paste the issues you're considering or describe them briefly — I'll help you structure the selection from there."
Step 3 — Apply the selection framework
For each candidate, Piper evaluates:
| Dimension | Question | Signal |
|---|
| Goal alignment | Does this advance the sprint goal? | Deprioritize if no clear connection |
| Dependency check | Does this block or get blocked by other sprint work? | Surface the dependency; plan in the right order |
| Scope clarity | Is this well-enough defined to work this sprint? | "Needs spec" items should not be sprint candidates |
| Size fit | Does capacity math work out if this is included? | Simple estimate — S/M/L, not points required |
| Risk | If this slips, does it cascade? | Flag high-risk items; don't ignore them |
This framework isn't run as a checklist for every item — Piper flags the issues where a dimension matters, not all dimensions for all issues.
Step 4 — Propose the sprint
Present a proposed sprint scope with rationale:
## Proposed sprint: [sprint name / dates]
**Goal**: [one sentence — what does a successful sprint look like?]
**Capacity**: [team members] × [sprint length] = ~[X] items at current velocity
---
### In — proposed sprint scope
| # | Issue | Why in |
|---|---|---|
| #[n] | [title] | [1-line rationale — goal alignment / dependency / customer impact] |
| #[n] | [title] | [rationale] |
| ... | | |
**Sprint confidence**: [High / Medium / Low] — [one sentence on what makes this achievable or risky]
---
### Out — explicitly not this sprint
| Issue | Why out |
|---|---|
| #[n] — [title] | [reason: blocked / needs spec / future milestone / capacity] |
| #[n] — [title] | [reason] |
*"Out" is deliberate, not forgotten. Review these at next planning.*
---
### Watch list — items that might join if something slips
| Issue | Condition |
|---|---|
| #[n] — [title] | If [other item] finishes early |
---
### Dependencies and risks
- [Dependency or risk 1 — specific, with what to do about it]
- [Dependency or risk 2]
---
### Questions before starting
- [Any clarification needed from PM before the sprint locks]
Step 5 — Invite adjustment
After presenting the proposal:
- "What would you change?"
- "Is the goal right, or is there a higher-priority outcome this sprint should serve?"
- "Anything in the Out list that should actually be In?"
The proposal is a starting point. PM owns the sprint.
Sprint planning without a goal
Sprint goals make selection dramatically easier — everything gets evaluated against one criterion. When PM doesn't have an explicit goal, Piper can help surface one:
"Looking at what's in the backlog, the natural organizing theme this sprint seems to be [X]. Would that work as the sprint goal? If so, it makes [issues Y and Z] clear priorities."
Don't impose a goal if PM doesn't want one — some teams work from a flat prioritized backlog and that's fine. But offering it is useful.
Capacity math (simple version)
PMs tend to over-commit sprints. Piper's default assumption without better data:
- 1-person sprint at full availability → ~60–70% of raw time is "productive issue work" (accounting for meetings, async, context-switching)
- Team velocity is usually 60–80% of what the sprint board shows when it fills up
If PM has better data (actual closed-issue counts from recent sprints), use that. If not, apply the conservative default and label it clearly: "This estimate is conservative — adjust if you know your actual velocity."
Handling "we don't use sprints"
Some teams (particularly early-stage or solo PMs) don't do formal sprints. The skill still applies as a periodic backlog review and prioritization:
- "Help me pick what to focus on this week"
- "Which of these 10 issues should I do first"
Replace "sprint" with "week" or "focus period" in the output. The framework — goal alignment, dependency check, scope clarity, capacity — applies either way.
Anti-patterns to avoid
| Don't | Why | Instead |
|---|
| Fill the sprint to 100% of capacity | No room for unexpected work | Target 70–80% and name the buffer |
| Pull items without "why in" rationale | No one remembers next sprint why they picked it | Every "in" item has a reason |
| Skip the "out" list | The "not this sprint" is a decision, not an omission | Name what's out and why |
| Ignore dependencies | Two sequential items in same sprint means the second can only start late | Surface the order constraint |
| Treat sprint plan as a commitment | Sprints are forecasts, not promises | Frame as "what we're aiming for" |
| Plan without a goal when the team has one | Misses the organizing principle | Ask for it; offer to surface one from the backlog |
Quality checklist
Before presenting the sprint proposal:
Example
Brief from PM: "Help me plan the next 2-week sprint. We're a team of 3, one person is part-time. Our focus this sprint is getting the onboarding flow ready for beta. GitHub is wired, so pull what you can."
Piper's output (abbreviated):
## Proposed sprint: [Beta Prep] — June 16–27
**Goal**: Get onboarding flow to beta-ready: a new user can sign up, complete setup, and reach their first meaningful action without assistance.
**Capacity**: 2.5 FTE × 2 weeks. At typical velocity (~8 medium issues), targeting 6–7 items.
---
### In — proposed sprint scope
| # | Issue | Why in |
|---|---|---|
| #412 | Fix onboarding step 2 validation | Blocking; reported by 3 users in closed beta |
| #389 | Add email confirmation flow | Required for beta launch — currently skipped |
| #401 | "What next?" empty state after setup | Without this, users complete setup and see nothing |
| #440 | Onboarding analytics events | Need to know where users drop before beta |
| #388 | Fix mobile viewport on setup step 3 | ~40% of signups are mobile; this is broken |
| #435 | Write onboarding help doc | Reduces support load; can ship async |
**Sprint confidence**: Medium — #389 (email confirmation) is the highest-risk item; if it takes longer than 3 days, it could crowd out #401.
---
### Out — explicitly not this sprint
| Issue | Why out |
|---|---|
| #312 — SSO integration | Not beta-required; no customer ask yet |
| #394 — Onboarding A/B test | Needs analytics (#440) first; defer to sprint 2 |
| #367 — Admin onboarding controls | Internal-facing; PM is the only admin right now |
---
### Dependencies
- #440 (analytics) should complete in week 1 so beta data is available from launch day
- #389 (email confirmation) blocks nothing else in sprint but is the riskiest item — start it Monday
---
### Questions before starting
- Is the empty state (#401) PM-approved in terms of copy/design, or does that still need a call?
Changelog
- v1.0 (2026-06-15): Initial version. Goal-aligned sprint selection with explicit "in / out / watch" structure, dependency surfacing, and capacity math. Richer with GitHub connector but workable without.
