PR-01

Sprint Planning Advisory Card

Planning Recommendations

Default severity: medium
PrioritizationEstimationOutputBusiness ValueEffort

What it detects

Generates a structured planning advisory card for the Product Owner and Scrum Master before each sprint. Provides concrete recommended numbers across all three velocity dimensions, with confidence interval and supporting rationale. Designed to prevent both over- and under-planning without requiring the team to interpret raw data.

Detection formula

BASE: team_velocity_baseline (VL-01) for current team FOR each_dimension D: advisory(D) = { do_not_plan_below: baseline(D).plan_low, // empirical floor recommended_target: baseline(D).plan_optimal, // median — most likely sustainable do_not_plan_above: baseline(D).plan_high, // empirical ceiling last_sprint: completed(D, last_sprint), // recent reference trend: slope_direction(D), // \'improving\' \| \'stable\' \| \'declining\' confidence: 100 - (baseline(D).cv * 100) // lower cv = higher confidence } IF baseline_sprints \< config.vl.baseline_sprints THEN note: \'Confidence low — fewer than N completed sprints available\' FORMAT: plain-language card readable by non-technical stakeholders EXAMPLE OUTPUT: Issues: plan 6–10 items (optimal: 8, last sprint: 7) Story Points: plan 24–40 SP (optimal: 32 SP, last sprint: 29 SP) Hours: plan 64–104h (optimal: 84h, last sprint: 78h) Trend: SP velocity stable. Issue velocity slightly declining — consider smaller items. **Info** velocity_baseline output — no Jira read required beyond VL-01 Planning Recommendations **PR-02** **Weekly Planning Advisory (Kanban / Flow Teams)** For teams using a weekly planning cadence rather than sprints, generates a weekly throughput advisory based on historical weekly completion rates. Covers issue count per week, SP per week, and hours per week across the last N weeks (configurable). N = config.pr.weekly_baseline_weeks // default: 8 weeks weekly_completed = \[completed(D, week=W) FOR W IN last N weeks\] FOR each_dimension D: weekly_advisory(D) = { floor: MAX(MIN(weekly_completed(D)), MEDIAN(weekly_completed(D)) - STDDEV(weekly_completed(D))), target: MEDIAN(weekly_completed(D)), ceiling: MIN(MAX(weekly_completed(D)), MEDIAN(weekly_completed(D)) + STDDEV(weekly_completed(D))) } FORMAT: \'Weekly throughput advisory: complete 2–4 features per week (target: 3). Do not load more than 4 features per week into WIP.\' **Info** Jira resolved dates (weekly aggregation over last N weeks) Planning Recommendations **PR-03** **Monthly Planning Advisory** Generates monthly delivery capacity advisory for operational planning and stakeholder communication. Aggregates sprint-level baselines into monthly equivalents. Accounts for the number of sprints per month (configurable). sprints_per_month = config.pr.sprints_per_month // default: 2 (2-week sprints) FOR each_dimension D: monthly_floor = baseline(D).plan_low * sprints_per_month monthly_target = baseline(D).plan_optimal * sprints_per_month monthly_ceiling = baseline(D).plan_high * sprints_per_month FORMAT: \'Monthly delivery advisory: expect 12–20 features and 48–80 SP delivered per month (target: 16 features / 64 SP). Use for roadmap communication and capacity planning.\' **Info** velocity_baseline × sprints_per_month Planning Recommendations **PR-04** **Quarterly Planning Advisory (PI Level)** Generates quarterly / PI-level planning advisory for programme increment planning. Provides expected delivery ranges in all three dimensions across the PI horizon, adjusted for planned team capacity changes, holidays, and IP sprint if configured. This is the primary input for PI commitment sizing. pi_weeks = config.planning.pi_duration_weeks // default: 12 weeks (6 × 2-week sprints) ip_sprints = config.planning.ip_sprints_per_pi // default: 1 (IP/hardening sprint excluded from velocity) delivery_sprints = FLOOR(pi_weeks / config.sprint.duration_weeks) - ip_sprints FOR each_dimension D: pi_floor = baseline(D).plan_low * delivery_sprints pi_target = baseline(D).plan_optimal * delivery_sprints pi_ceiling = baseline(D).plan_high * delivery_sprints // Adjust for known capacity reductions (holidays, team changes): capacity_factor = config.pr.pi_capacity_factor // default: 0.85 (15% reduction for PI overhead) pi_adjusted_target = pi_target * capacity_factor FORMAT: \'PI planning advisory (10 delivery sprints): commit 240–400 SP (target: 320 SP adjusted for PI overhead). Do not accept more than 400 SP into PI scope.\' **Info** velocity_baseline × delivery_sprints × capacity_factor Planning Recommendations **PR-05** **Backlog Refinement Depth Advisory** Advises the Product Owner on how many items should be refined and ready (DoR-compliant) at any point in time to support the next N sprints without last-minute scrambling. Based on throughput and typical refinement-to-sprint lag. sprints_to_buffer = config.pr.refinement_buffer_sprints // default: 2 (keep 2 sprints ready ahead) FOR each_dimension D: required_ready_items(D) = baseline(D).plan_ceiling * sprints_to_buffer current_ready = COUNT(issues WHERE status IN config.workflow.preparation_stages AND dor_score >= config.dod.stages\[\'Ready\'\].threshold) IF current_ready \< required_ready_items(issue_count) THEN FLAG refinement_backlog_thin FORMAT: \'Refinement advisory: keep at least 16–20 items in Ready state at all times (currently: X items ready). Prioritise refinement sessions to replenish.\'

Examples in practice

  • A team shows generates a structured planning advisory card for the product owner and scrum master before each sprint while baseline sprints is set to 8.
  • Example signal: Generates a structured planning advisory card for the Product Owner and Scrum Master before each sprint.

Suggested response

Use the advisory outputs to tune refinement, WIP, and planning cadence with data.

Coaching playbook

Symptom

Generates a structured planning advisory card for the Product Owner and Scrum Master before each sprint. Provides concrete recommended numbers across all three velocity dimensions, with confidence interval and supporting rationale. Designed to prevent both over- and under-planning without requiring the team to interpret raw data.

Why it matters

When "Sprint Planning Advisory Card" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.

What you can achieve

Use the advisory outputs to tune refinement, WIP, and planning cadence with data.

Facilitation questions

  • What system change would stop "Sprint Planning Advisory Card" from firing again?
  • What do the cited issues have in common — same root cause or same workaround?
  • Who owns the two-week experiment and how will we verify on the next import?

Run this rule against your own tracker data with Flow Analyzer.

Product tourSign in
PR-01: Sprint Planning Advisory Card — FlowAnalyzer