Velocity metrics: Respond to market needs
Predictability and speed to market are desirable for businesses. Velocity measures story points and represents the amount of work for a team to accomplish in a given sprint—noting the key milestones of the build. With an estimated backlog measured in story points, divide the total points by sprint velocity and project the number of sprints necessary to release desired scope to market.
Velocity helps the team project key milestones of the build. Using the estimated backlog size in story points divided by the average sprint velocity determines the number of sprints to release.
The quality and maturity of the organizational processes (e.g., mature DevOps featuring automated builds, tests, and code standards) influence velocity and prevent developers from shipping defective software.
Velocity is not an absolute metric and should not be used as a means of comparison across multiple product teams. Story point estimates are based on arbitrary numbers from the Fibonacci sequence to indicate the anticipated complexity of a given feature. Estimation standards vary by team. For example, one team chooses to estimate a complex feature in nine points, whereas another uses fifteen.
No two teams are identical. Use velocity in historical context for a single team. The sprint velocity depends on the number of team members. There are a variety of tactics to manage teams at scale, including a velocity trending report, a cost per story trending report, a backlog aging report, and an estimate velocity report.
Velocity trending report
Each team should monitor its velocity over time. Sprint 0 normally starts slow. Building momentum takes time. After a few first sprints, a long-term stable velocity should emerge. Realistically, the report will have outliers. For example, a complex highly integrated feature throws off the data.
To monitor velocity over time, consider adopting the following tactics:
Analysis: Analyze the root cause for spikes and dips of velocity. While normal, it’s important to understand and anticipate shifts.
Trends: Game velocity by assigning larger story point estimates to smaller features. Try to review estimates in parallel to the velocity trends.
Change: When evaluating product maturity, there tends to be a slight drop in velocity once a product reaches a certain point of maturity. This often happens around the year or year and a half mark for a greenfield initiative. Normal and expected saturation of functionality, interdependencies, size, and number of teams all have an impact. There is a price to pay at scale.
Reporting velocity adds value by demonstrating ROI when an organization is going through a transformation effort. It’s important to note activities that boost team productivity or increase adoption. Take time to document implementation of best practices (e.g., automated testing, CI/CD, code standards) that manifest higher velocity.
Cost per story point trending report
Track the cost per story point to evaluate the efficiency of work being completed. To measure, divide the total cost (i.e., burn) of running a team for a sprint by the number of story points delivered in the sprint. This report monitors velocity trends offset by adding or removing team members (e.g., difficulty identifying velocity gaming or loss of productivity because a team adds two engineers after eight sprints).
Accounting for both the cost of running the team and the scope shipped increases the average cost of a story point through time. The cost per story point typically experiences a slight uptick as the product matures or reaches a saturated state. Take time to analyze the root cause of these shifts. Left unchecked, the changes have the potential to cause damage or lead to inefficiencies that accrue over time (e.g., a testing strategy that no longer services the product adequately, outdated code standards, or slow build pipeline).
Backlog aging report
Backlog aging becomes useful when releasing a new version of a product to market, and new features start queueing up in the backlog. The report tracks how long a feature sits in the backlog before being shipped into production. Use this report to capture a snapshot in time.
Was the business more or less responsive to market needs?
Is the backlog growing too fast for the delivery teams to manage?
Is the delivery team able to keep pace with demands and ship in a timely manner?
Estimate volatility report
Especially for custom product builds, developing sound estimates relies on forming educated guesses based on a variety of unique factors (e.g., prior experience, projected team size, project goals). Be sure to reflect on estimate accuracy as a healthy best practice. The data helps craft better projections going forward, especially for teams unable to reach Definition of Done within a designated sprint.
Track estimate volatility at the feature level. Individual stories tend to be too granular to showcase trends. Compare the original estimate to the actual effort required to ship the feature, MVP, or product. Here are a couple of insights from one of our teams:
Teams owning a feature from start to finish outperform teams with partial ownership of features both in velocity and estimate accuracy.
Highly volatile teams require additional domain education to grasp context. Once implemented, volatility decreases significantly.