Velocity is one of the most misused and misunderstood terms in agile. Therefore, it is essential to understand what velocity is for and what it is not to avoid having fake metrics, creating unnecessary stress, and destroying motivation. In this mini-series, I’m sharing my view and experience about the topic.
Senior manager to Scrum Master:
“...the team didn’t deliver in line with their expected velocity...”
Scrum master to Team:
“Hey, Team, the management is not satisfied with our actual velocity.”
Team:
“Ok, guys, we’ll make sure that in the next Sprint, we will deliver the expected amount of story points.”
Velocity: your most important goal and KPI? NOOOOOOO! Or…?
Lately, when working with a team, I observed that the surrounding organization had heavily misunderstood the concept of “velocity.” The management started to monitor the velocity to see whether the team is delivering enough. However, the management didn’t rigorously measure the RoI (Return on Investment) of the product and the team’s real business outcome.
It’s risky because - you know how it works - what the team is measured by can quickly become a goal for them, and that’s when the “window dressing” begins. There’s a good chance that the team starts making the charts look better than they are, and believe me, faking the figures is the last thing you want to have in your organization.
I even heard statements from managers, like “It’s my expectation towards the team to increase their velocity by 15% every Sprint”, or “the expected velocity for this team is…”
So, suppose a team is measured by their velocity, and they want to meet the expectation of increasing it every Sprint. To deliver “more,” they either
- start altering their estimation scale via over-estimating items (“oh, let’s give this type of backlog item a bigger estimate this time…”), or
- compromise quality (“...we will not be able to deliver this story if we do proper unit-testing, so, let’s skip unit-testing…”).
Acting like this prevents the team from using velocity with the original intent of having a helpful metric for self-reflection and a tool for planning. Most importantly, it will make the release plans lie to the Product Owner and make false promises to customers and stakeholders. On top of that, it leads to degrading product quality and motivation issues.
Velocity should never become a goal or a KPI for measuring productivity.
It kills agility.
So, what is velocity, and what to use it for?
Velocity is a metric that measures the amount of (unit of) work a team can deliver in a particular timeframe.
The “unit of work” is often expressed in ”points” or “story points” and reflects the estimated “size” of the work. The timeframe or time-box is the length of iteration, or Sprint if the team is following Scrum.
The velocity typically measures the team's output and does not necessarily measure the team's outcome. Simply put, the output is how much the team can deliver, and the outcome is the value delivered.
The Product Owner’s immense responsibility is to maximize the team's outcome by assuring that the team works on backlog items representing the highest (business) value.
The Scrum Master ensures that the team is fully functional and can maximize its output without over-committing given circumstances. (Note: don’t get me wrong here, the Scrum Master also helps the Product Owner and the team find the most valuable backlog items by providing the PO with techniques, like story mapping, etc.)
Measuring both the outcome and output is essential. Focusing only on the "business" outcome can endanger sustainability (e.g., decreased quality due to increased technical debt). Measuring only the output ignores the real reason behind agile: to support achieving business goals and making an impact.
Velocity can and should only be used for:
1. Planning the amount of work to be done in the next sprint
Based on the average velocity of the last 3-5 Sprints, the team forecasts (and does not commit to!!!) the work they plan to accomplish in the next iteration. They can give a more realistic prediction using the historical data (measured velocity), so they neither bite too much nor too little.
2. Planning the release and helping forecast the scope and timing
Based on the current measured velocity trend, the team can forecast the number of iterations they need to deliver a given amount of work or how far they can get on the backlog by a given date.
3. Monitoring the "health status" of the team and the product
The velocity trend shows how stable the team’s output is. Suppose the velocity fluctuates from Sprint to Sprint or shows a degrading trend. In that case, it might indicate that the team has serious impediments that prevent them from completing the work they forecasted. Unfinished work results in leftovers (backlog items brought to the next Sprint), "failed" Sprints, not to mention the demotivating feeling of “unsuccessful” delivery.
SUMMARY
- Velocity is a helpful tool for planning the next iteration, forecasting the release both scope- and time-wise, and checking the “health” of the product and the team.
- Velocity should never become a goal or KPI for measuring productivity. It leads to “window dressing,” which destroys predictability and results in fake release plans.
- Measuring both the output and the outcome is essential to handle the system as a whole.
Check out the other posts in the velocity mini-series for details about using the velocity for the three purposes mentioned above.