Sprint / cycle planner

Sprint / cycle planner

Invocation: user only.

Plans one iteration, whatever the team's framework is. Supports three:

• Scrum — 1-2 week sprints, velocity-driven, story points, backlog-based
• Shape Up — 6-week cycles, fixed time / variable scope, shaped pitches with appetite
• Kanban — continuous flow, WIP limits, no fixed iteration; this skill then plans a 1-week commitment window

Parse $ARGUMENTS. If framework isn't explicit, ask the user — different frameworks have different plan outputs.

Common workflow (all frameworks)

1. Pull context

• Prior iteration's review — what got committed last time, what actually landed? Velocity, slippage, unplanned work
• Current backlog / pitches / queue — items that are candidates for this iteration
• Team availability — known time off, conflicting commitments, onboarding, new hires not yet at full pace
• Carryover — unfinished work from prior iteration that needs to be reconciled (commit, drop, or push further)
• Cross-team commitments — blockers or dependencies with other teams

2. Set the iteration goal

One sentence. What the team commits to producing or making progress on. Not a list of tasks — a goal.

Good: "Ship the export-to-CSV feature to 10% of customers and validate adoption > 20%." Bad: "Close 8 tickets."

3. Estimate capacity

Scrum:

• Velocity = average story points completed in the last 3-5 sprints
• Capacity = team × days × hours × focus factor (0.6-0.8 is realistic; higher than 0.8 is a fantasy)
• Commit = ~80% of capacity in story points; leave slack for the unplanned

Shape Up:

• Appetite is fixed at the cycle length (2 weeks for small batch, 6 weeks for big batch)
• Capacity is already set by the cycle; this is about which pitches fit
• Plan includes a shaped pitch (bounded problem + solution outline), not a task list

Kanban:

• WIP limits are the commitment mechanism, not a point count
• Plan the week = which items we'll pull in, what WIP limits hold, what priority order

4. Select work

Scrum: build the sprint backlog For each story selected, record: ID, estimate (modified Fibonacci: 1, 2, 3, 5, 8, 13, 20), owner, hard dependencies. Sum estimates ≤ commit target. Stories >13 points should be split or flagged — they hide risk.

Shape Up: shape the pitch For the pitch(es) this cycle, confirm: problem is bounded, appetite is honest, no-gos are explicit, fat-marker sketches of solution exist. Reject anything vague or unboxed. A pitch without clear no-gos will consume the cycle.

Kanban: define the pull priority Ordered list of items. WIP limit per column. Work begins at the top; lower items are context, not commitments.

5. Risk check

For the selected work, identify:

• Dependencies — on other teams, on external services, on in-flight decisions
• Unknown territory — tasks where the approach isn't obvious (flag for spike or research time)
• New-hire learning curve — if a junior owns critical-path work
• Planned time off — absence during iteration that isn't already counted in capacity

If any of these are material, either cut work or acknowledge the risk in the commitment.

6. Define done

For each item selected, the team must agree on the done bar:

• Code merged to main
• Tests passing (which tests?)
• Reviewed by
• Deployed to staging / prod
• Customer-visible or feature-flagged off?
• Documentation updated
• Stakeholder approval if required

Default done-bars per iteration so the team doesn't re-negotiate each item.

Output — Scrum

# Sprint plan: <sprint N>

**Goal:** <one-sentence commitment>
**Duration:** <start — end> (<N days>)
**Velocity (trailing 3 sprints):** <points avg>
**Capacity this sprint:** <hours> (team × days × 0.7 focus factor, minus PTO)
**Commit target:** <points>, ~80% of capacity

## Sprint backlog

| # | Story | Estimate | Owner | Depends on |
| --- | --- | --- | --- | --- |
| 1 | <story> | 5 | <person> | — |
| 2 | ... | | | |

**Total committed:** <points>
**Stretch (if capacity opens):** <1-2 stories>

## Carryover from last sprint
- <item> — status — action (commit / drop / push)

## Risks
- <risk> — mitigation

## Definition of done (this sprint)
- [ ] Code merged to main
- [ ] Tests passing
- [ ] Reviewed by 1 engineer + designer on UI items
- [ ] Deployed to staging
- [ ] Feature-flagged or launched
- [ ] Stakeholder demo at end of sprint

Output — Shape Up

# Cycle plan: <cycle start date>

**Duration:** 6 weeks (or 2-week small-batch) — <start — end>
**Teams:** <list — usually pairs>

## Pitch 1: <name>
**Appetite:** <2w | 6w>
**Problem:** <bounded>
**Solution outline:** <fat-marker sketch, high level>
**No-gos:** <explicit scope exclusions>
**Team:** <pair>
**Risks:** <flagged rabbit holes, dependencies>

## Pitch 2: ...

## Cooldown (after cycle)
<what we'll do in the 2 weeks between cycles — maintenance, exploration, team rest>

Output — Kanban

# Week commit: <week start>

**Goal:** <one sentence>
**WIP limits:** To Do ∞ / In Progress 3 / Review 2 / Done ∞

## Pull priority (top-down)
1. <item> — owner
2. <item> — owner
3. ...

## Hard dependencies and ordering
- <item> must precede <item> because <reason>

## Expected done by end of week
<which items we expect to hit "done" — realistic given WIP limits>

## Risks
- <risk>

Review and publish

Show the draft. Common edits:

• Reduce commit (too ambitious)
• Add a risk the user sees
• Swap in/out specific items
• Adjust iteration goal

On approval: publish to the team's tracker (Notion / Jira / Linear via the appropriate MCP if connected), post kickoff summary to Slack via /team-core:draft-email flow. The kickoff post should be short — the goal, the commitment, the top risks. Team members check the tracker for detail.

Don't

• Don't commit to 100% of capacity. No team actually runs at 100%; the plan pretends otherwise.
• Don't accept "we'll figure it out" on a story > 13 points. Break it or flag it as a spike.
• Don't skip carryover reconciliation. Silently letting items slide is how sprints lose meaning.
• Don't pick a framework because it's trendy. If the team genuinely runs Shape Up, plan cycles. If they run Kanban, don't force story points.

---

Methodology inspired by the shubhamsaboo "sprint-planner" skill, extended for Shape Up and Kanban frameworks.