Velocity Analysis
Analyze velocity trends and predict capacity for "$ARGUMENTS". Chart historical velocity, calculate statistical measures, correlate changes with events, and recommend sprint commitment ranges.
Prerequisites
Check that .project/$ARGUMENTS/00-initiate.md exists. If it does not, tell the user to run an Initiate skill first (e.g., project-charter) and stop.
If the user passes --skip-checks, skip the prerequisite check and log the skip to .project/$ARGUMENTS/skip-log.md with a timestamp and reason.
Process
Read existing context:
- Read
.project/$ARGUMENTS/00-initiate.md for project context, team size, and sprint cadence
- Read
.project/$ARGUMENTS/03-review.md if it exists (for sprint review results, sprint metrics, and historical velocity data)
- Read
.project/$ARGUMENTS/04-improve.md if it exists (for retrospective action items and process changes that may have affected velocity)
- Read
.project/$ARGUMENTS/01-plan.md if it exists (for sprint planning data, committed points, and estimation approach)
- Read
.project/$ARGUMENTS/02-sprint.md if it exists (for sprint execution data and blocker history)
Chart velocity over last 5-10 sprints:
- Collect completed story points for each of the last 5-10 sprints (or as many as are available)
- Present velocity data as a table: sprint name/number, committed points, completed points, commitment ratio
- Create a text-based chart showing velocity per sprint (horizontal bar chart or similar visualization)
- If fewer than 5 sprints of data are available, note this limitation and adjust analysis accordingly
- Separate velocity into categories if possible: new features, bug fixes, tech debt, unplanned work
Calculate average velocity and standard deviation:
- Calculate the arithmetic mean of completed points across all available sprints
- Calculate the standard deviation to measure velocity consistency
- Calculate the coefficient of variation (standard deviation / mean x 100%) to express variability as a percentage
- Interpret variability:
- < 15% — highly predictable team, estimates are reliable
- 15-30% — normal variability, plan with a range
- > 30% — high variability, investigate causes before relying on velocity for planning
- If available, calculate a weighted moving average (more recent sprints weighted higher) for a more current picture
Identify trends:
- Determine the overall velocity direction: improving, declining, or stable
- Use linear regression direction across the data points to classify the trend:
- Improving — positive slope, team is delivering more over time
- Declining — negative slope, team is delivering less over time
- Stable — slope near zero (within +/- 5% of average), consistent delivery
- If the trend is improving, identify likely causes: team maturity, better estimation, process improvements, reduced tech debt
- If the trend is declining, flag for investigation: team changes, increasing tech debt, morale issues, scope complexity growth
- Note any outlier sprints (more than 2 standard deviations from the mean) and explain them separately
Correlate velocity changes with events:
- Review the project timeline for events that may explain velocity changes:
- Team member changes — new joins (ramp-up period reduces velocity), departures (knowledge loss)
- Holidays and vacations — reduced capacity sprints
- Incidents and outages — unplanned work displacing planned work
- Process changes — new practices from retrospectives or process improvements
- Technical changes — major refactors, platform migrations, new tools
- Map each significant velocity change to its likely cause
- Distinguish between temporary dips (holidays, incidents) and structural shifts (team size change, process change)
- Note which events had the largest impact on velocity and how long recovery took
Calculate sustainable velocity range:
- Define sustainable velocity as the range the team can reliably deliver without burnout
- Calculate the range: average velocity +/- 1 standard deviation
- This gives a low estimate (conservative) and high estimate (optimistic)
- Exclude outlier sprints from the calculation if they were caused by one-time events
- If the team has been consistently above average for 3+ sprints, consider updating the baseline upward
- If the team has been consistently below average, investigate whether the average is still realistic
Predict capacity for next 3 sprints:
- For each of the next 3 sprints, estimate expected capacity:
- Start with the sustainable velocity range
- Adjust for known factors: planned vacations, holidays, team changes, expected incidents
- Express as a range: conservative (low end minus known reductions) to optimistic (high end with ideal conditions)
- Flag any sprints with significantly reduced capacity (holidays, team members out)
- If the team is mid-trend (improving or declining), factor the trend direction into predictions
- Note confidence level for each prediction: high (stable team, good data), medium (some unknowns), low (major changes expected)
Recommend sprint commitment range:
- Based on the analysis, recommend how many story points to commit to in the next sprint
- Provide two numbers:
- Conservative commitment — what the team can almost certainly deliver (low end of sustainable range, rounded down)
- Optimistic commitment — what the team could deliver if everything goes well (average velocity, rounded to nearest whole number)
- Recommend which number to use based on the team's situation:
- Use conservative when: team is rebuilding confidence, new members are ramping up, high-risk work ahead
- Use optimistic when: team is stable and predictable, work is well-understood, team has momentum
- Note that velocity is a planning tool, not a performance metric — do not use it to pressure the team
Write the artifact — append to .project/$ARGUMENTS/04-improve.md under a ## Velocity Analysis section:
- Velocity History — table and chart of velocity over last 5-10 sprints
- Statistical Summary — average velocity, standard deviation, coefficient of variation
- Trend Analysis — direction (improving/declining/stable) with supporting data
- Event Correlation — velocity changes mapped to team and project events
- Sustainable Velocity Range — calculated range with methodology
- Capacity Predictions — next 3 sprints with expected ranges and confidence levels
- Commitment Recommendation — conservative and optimistic commitment for next sprint with guidance on which to use
Output
Velocity analysis appended to .project/$ARGUMENTS/04-improve.md. Present a summary highlighting:
- Average velocity and variability (coefficient of variation)
- Trend direction with key contributing factors
- Sustainable velocity range
- Recommended commitment for next sprint (conservative and optimistic)
- Any sprints with reduced capacity in the next 3-sprint window
1---2name: velocity-analysis3description: Analyze velocity trends, predict capacity, and identify patterns4---56# Velocity Analysis78Analyze velocity trends and predict capacity for "$ARGUMENTS". Chart historical velocity, calculate statistical measures, correlate changes with events, and recommend sprint commitment ranges.910## Prerequisites1112Check that `.project/$ARGUMENTS/00-initiate.md` exists. If it does not, tell the user to run an Initiate skill first (e.g., project-charter) and stop.1314If the user passes `--skip-checks`, skip the prerequisite check and log the skip to `.project/$ARGUMENTS/skip-log.md` with a timestamp and reason.1516## Process17181. **Read existing context:**19 - Read `.project/$ARGUMENTS/00-initiate.md` for project context, team size, and sprint cadence20 - Read `.project/$ARGUMENTS/03-review.md` if it exists (for sprint review results, sprint metrics, and historical velocity data)21 - Read `.project/$ARGUMENTS/04-improve.md` if it exists (for retrospective action items and process changes that may have affected velocity)22 - Read `.project/$ARGUMENTS/01-plan.md` if it exists (for sprint planning data, committed points, and estimation approach)23 - Read `.project/$ARGUMENTS/02-sprint.md` if it exists (for sprint execution data and blocker history)24252. **Chart velocity over last 5-10 sprints:**26 - Collect completed story points for each of the last 5-10 sprints (or as many as are available)27 - Present velocity data as a table: sprint name/number, committed points, completed points, commitment ratio28 - Create a text-based chart showing velocity per sprint (horizontal bar chart or similar visualization)29 - If fewer than 5 sprints of data are available, note this limitation and adjust analysis accordingly30 - Separate velocity into categories if possible: new features, bug fixes, tech debt, unplanned work31323. **Calculate average velocity and standard deviation:**33 - Calculate the arithmetic mean of completed points across all available sprints34 - Calculate the standard deviation to measure velocity consistency35 - Calculate the coefficient of variation (standard deviation / mean x 100%) to express variability as a percentage36 - Interpret variability:37 - **< 15%** — highly predictable team, estimates are reliable38 - **15-30%** — normal variability, plan with a range39 - **> 30%** — high variability, investigate causes before relying on velocity for planning40 - If available, calculate a weighted moving average (more recent sprints weighted higher) for a more current picture41424. **Identify trends:**43 - Determine the overall velocity direction: improving, declining, or stable44 - Use linear regression direction across the data points to classify the trend:45 - **Improving** — positive slope, team is delivering more over time46 - **Declining** — negative slope, team is delivering less over time47 - **Stable** — slope near zero (within +/- 5% of average), consistent delivery48 - If the trend is improving, identify likely causes: team maturity, better estimation, process improvements, reduced tech debt49 - If the trend is declining, flag for investigation: team changes, increasing tech debt, morale issues, scope complexity growth50 - Note any outlier sprints (more than 2 standard deviations from the mean) and explain them separately51525. **Correlate velocity changes with events:**53 - Review the project timeline for events that may explain velocity changes:54 - **Team member changes** — new joins (ramp-up period reduces velocity), departures (knowledge loss)55 - **Holidays and vacations** — reduced capacity sprints56 - **Incidents and outages** — unplanned work displacing planned work57 - **Process changes** — new practices from retrospectives or process improvements58 - **Technical changes** — major refactors, platform migrations, new tools59 - Map each significant velocity change to its likely cause60 - Distinguish between temporary dips (holidays, incidents) and structural shifts (team size change, process change)61 - Note which events had the largest impact on velocity and how long recovery took62636. **Calculate sustainable velocity range:**64 - Define sustainable velocity as the range the team can reliably deliver without burnout65 - Calculate the range: average velocity +/- 1 standard deviation66 - This gives a low estimate (conservative) and high estimate (optimistic)67 - Exclude outlier sprints from the calculation if they were caused by one-time events68 - If the team has been consistently above average for 3+ sprints, consider updating the baseline upward69 - If the team has been consistently below average, investigate whether the average is still realistic70717. **Predict capacity for next 3 sprints:**72 - For each of the next 3 sprints, estimate expected capacity:73 - Start with the sustainable velocity range74 - Adjust for known factors: planned vacations, holidays, team changes, expected incidents75 - Express as a range: conservative (low end minus known reductions) to optimistic (high end with ideal conditions)76 - Flag any sprints with significantly reduced capacity (holidays, team members out)77 - If the team is mid-trend (improving or declining), factor the trend direction into predictions78 - Note confidence level for each prediction: high (stable team, good data), medium (some unknowns), low (major changes expected)79808. **Recommend sprint commitment range:**81 - Based on the analysis, recommend how many story points to commit to in the next sprint82 - Provide two numbers:83 - **Conservative commitment** — what the team can almost certainly deliver (low end of sustainable range, rounded down)84 - **Optimistic commitment** — what the team could deliver if everything goes well (average velocity, rounded to nearest whole number)85 - Recommend which number to use based on the team's situation:86 - Use conservative when: team is rebuilding confidence, new members are ramping up, high-risk work ahead87 - Use optimistic when: team is stable and predictable, work is well-understood, team has momentum88 - Note that velocity is a planning tool, not a performance metric — do not use it to pressure the team89909. **Write the artifact** — append to `.project/$ARGUMENTS/04-improve.md` under a `## Velocity Analysis` section:91 - **Velocity History** — table and chart of velocity over last 5-10 sprints92 - **Statistical Summary** — average velocity, standard deviation, coefficient of variation93 - **Trend Analysis** — direction (improving/declining/stable) with supporting data94 - **Event Correlation** — velocity changes mapped to team and project events95 - **Sustainable Velocity Range** — calculated range with methodology96 - **Capacity Predictions** — next 3 sprints with expected ranges and confidence levels97 - **Commitment Recommendation** — conservative and optimistic commitment for next sprint with guidance on which to use9899## Output100101Velocity analysis appended to `.project/$ARGUMENTS/04-improve.md`. Present a summary highlighting:102- Average velocity and variability (coefficient of variation)103- Trend direction with key contributing factors104- Sustainable velocity range105- Recommended commitment for next sprint (conservative and optimistic)106- Any sprints with reduced capacity in the next 3-sprint window