PR-02
Weekly Planning Advisory (Kanban / Flow Teams)
Kanban / Flow Teams
Default severity: medium
PrioritizationEstimationOutputBusiness Value
What it detects
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).
Detection formula
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 for teams using a weekly planning cadence rather than sprints, generates a weekly throughput advisory based on historical weekly completion rates while weekly baseline weeks is set to 8 weeks weekly_completed = \[completed(D, week=W).
- Example signal: For teams using a weekly planning cadence rather than sprints, generates a weekly throughput advisory based on historical weekly completion rates.
Suggested response
Use the advisory outputs to tune refinement, WIP, and planning cadence with data.
Coaching playbook
Symptom
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).
Why it matters
When "Weekly Planning Advisory (Kanban / Flow Teams)" 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 "Weekly Planning Advisory (Kanban / Flow Teams)" 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.