VL-01
Velocity Baseline Computation — Rolling Window
Velocity
Default severity: medium
PrioritizationEstimationOutputEffort
What it detects
Computes the velocity baseline for each team across three dimensions (issue count, story points, hours logged) using the last N completed sprints. Derives min, max, average (mean), and median — these four values define the recommended planning range and are the reference for all other VL rules. This rule is a computation rule: it always runs and produces the baseline record; it does not fire a finding on its own.
Detection formula
N = config.vl.baseline_sprints // default: 8 sprints completed_sprints = sprints WHERE end_date \<= today AND status = \'closed\', ORDER BY end_date DESC, LIMIT N FOR each_dimension D IN \[issue_count, story_points, hours_logged\]: values(D) = \[completed(D, S) FOR S IN completed_sprints\] baseline(D).min = MIN(values(D)) baseline(D).max = MAX(values(D)) baseline(D).avg = AVG(values(D)) baseline(D).median = MEDIAN(values(D)) baseline(D).stddev = STDDEV(values(D)) // Recommended planning range: baseline(D).plan_low = MAX(baseline(D).min, baseline(D).median - baseline(D).stddev) baseline(D).plan_high = MIN(baseline(D).max, baseline(D).median + baseline(D).stddev) baseline(D).plan_optimal = baseline(D).median Store as team_velocity_baseline\[team\]\[dimension\] **Info** Jira completed sprint data (issue count, SP, worklog) — last N sprints Velocity **VL-02** **Over-Planning — Sprint Commitment Exceeds Historical Maximum** The current sprint\'s committed work in any dimension exceeds the team\'s historical maximum across the last N sprints — the team has committed more than they have ever delivered. This is the strongest planning red flag: if you never delivered X, committing X+n is statistically unjustifiable. FOR each_dimension D: committed(D, current_sprint) = SUM(D, issues IN sprint AT sprint.start) IF committed(D) > baseline(D).max * config.vl.max_overrun_buffer // default: 1.05 (5% tolerance above max) THEN CRITICAL over_planning_beyond_max Report: committed vs max vs median, all three dimensions side by sideExamples in practice
- PR-01
- A team shows computes the velocity baseline for each team across three dimensions (issue count, story points, hours logged) using the last n completed sprints while baseline sprints is set to 8 sprints completed_sprints = sprints WHERE end_date \<= today.
- Example signal: Computes the velocity baseline for each team across three dimensions (issue count, story points, hours logged) using the last N completed sprints.
Suggested response
Plan to historical capacity—avoid repeated over or under-commitment and unstable velocity.
Coaching playbook
Symptom
Computes the velocity baseline for each team across three dimensions (issue count, story points, hours logged) using the last N completed sprints. Derives min, max, average (mean), and median — these four values define the recommended planning range and are the reference for all other VL rules. This rule is a computation rule: it always runs and produces the baseline record; it does not fire a finding on its own.
Why it matters
When "Velocity Baseline Computation — Rolling Window" 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
Plan to historical capacity—avoid repeated over or under-commitment and unstable velocity.
Facilitation questions
- What system change would stop "Velocity Baseline Computation — Rolling Window" 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.