Velocity helps the team figure out how much work they can accomplish in the next iteration if appropriately measured. ...and that's the tricky part here.
Velocity is one of the most misused and misunderstood terms in agile. Therefore, it is essential to understand how velocity should be used 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.
Scrum master to Team:
- “Hey, Team, looking back at the last 3 Sprints, it seems that we continuously undertook more than we could deliver.”
Team:
- “Hm, right, how can we improve?”
Scrum master to Team:
- “Let’s check the potential root causes during the retrospective, and let’s start using our historical data to adjust our forecast.”
Forecasting the work for the next iteration
Why is forecasting needed?
In most cases, the Product Owner (or the stakeholders) would like to know what can likely be delivered in the next iteration (assuming that the team works in iterations) so it can be communicated to the stakeholders (end users, marketers, etc.). In Scrum, it is even mandatory to address the topic “What can be done in this Sprint?” during the Sprint Planning. The answer also affects the Sprint Goal, which has to be finalized by the end of the Sprint Planning event.
Why is realistic forecasting needed?
Neither including less nor including more in the upcoming Sprint is a good idea.
- If the team undertakes more than they can finish, there’s a good chance that they will not achieve the Sprint Goal.
- If they are conservative in their forecast, they might not perform at their full potential.
Either case can lower both predictability and motivation.
Yesterday’s weather (wtf?)
They say that the best predictor of today’s weather is yesterday’s weather. But wait, how does it belong to this velocity thingy? Easy as pie.
The most realistic forecast a team can give about how much work they can tackle and likely finish by the end of the iteration is backed by the measured data of their past performance. So I like to take the moving average of the velocity of the last 3-4 iterations as the basis for planning the next one.
EXAMPLE
Suppose the team’s velocity in the last 3 Sprint was:
- Sprint 1: 24
- Sprint 2: 19
- Sprint 3: 27
Based on this, the average velocity of the last 3 Sprints is 23,33. So the team gives a realistic forecast of about 23 units of work. In agile, the forecast should always be based on historical data. No “expert guess” excel wizardry!
DATA BEATS OPINION.
IN AGILE, WE ALWAYS FORECAST BASED ON HISTORICAL DATA.
What about absences or overtime? The answer: normalized velocity.
Say the team just finished the previous Sprint. One out of six team members was on sick leave during the last Sprint, and another one participated in a vital AWS training for half of the Sprint. So the real velocity - the amount of work fully completed given circumstances - of the Sprint is 22.
We are at the Sprint Planning event. The two teammates mentioned above are now back from their “absences,” They will be fully available in the upcoming Sprint. Does it make sense to plan the next Sprint with 22, knowing that two colleagues were away from a significant amount of time? Of course not. We normalize the real velocity with their absences, and we get the (hm, surprise!) normalized velocity.
CALCULATION
6 team members fully present = 100% capacity
4,5 team members fully present = 75% capacity
The real velocity of 22 was achieved with a 75% capacity
Normalized velocity: 29.3 (rounded 29).
Overtime should be treated similarly. To get to a realistic forecast, we should deduct the respective portion of the overtime from the real velocity. (Note: I know, I know..., in the name of sustainability, we undoubtedly don’t like having overtime in an agile organization, but let’s be honest here, it happens sometimes.)
Besides using the moving average of the normalized velocity, there’s one more input to consider when forecasting: the planned absences for the next iteration. So ideally, the Scrum Master starts the Sprint Planning by collecting absences planned for the next Sprint to see the available capacity in the team.
No partial credit! (i.e., how to calculate velocity?)
The velocity is calculated at the end of the iteration by adding up the estimations of the fully completed backlog items. Fully completed means the backlog item meets the Definition of Done and is accepted.
What happens with the backlog items the team almost finished? Are these items counted partially in the velocity, and if not, why not?
We don’t count partially done items in the velocity because
- we prefer finishing things by the end of the iteration, especially in Scrum, where a potentially shippable product increment should be delivered latest by the end of the Sprint, and
- the goal is not to measure how hard the team worked but how much they can finish given circumstances to create a more accurate release plan based on the real velocity.
- Partial credit gives the team the false impression of completed work, stopping them from improving their practice of providing forecasts and splitting large backlog items into digestible ones.
Giving partial credit overstates velocity, decreases predictability and transparency as well.
NO PARTIAL CREDIT!
Help! The team fell in love with their velocity!
I’ve seen it happen that the team considered velocity as a 100% accurate metric, so they never challenged themselves, never wanted to go beyond their beloved speed.
It shouldn’t be like this. In such cases, the Scrum Master can teach and challenge the team. Sometimes it’s ok to take 28 if this is the way to achieve the Sprint Goal, even if the average velocity is 25.
Velocity helps give a good enough forecast and prevents unrealistic plans.
Team vs. individual velocity!
“Oh, this Sprint was really-really crappy. I could deliver only 3 points.” - senior developer.
….eeeehh. First of all, the product (outcome) should be delivered, not the points (output).
Second, there’s no such thing as individual velocity. It’s meaningless. The team’s velocity is not calculated by summing up individual velocities. The team is intended to produce more than its individual “one-man-show” parts. Teamwork makes agility work.
SUMMARY
- The reason behind forecasting the amount of work for the next iteration is the need for predictability and transparency. It helps finalize a realistic Sprint Goal.
- In agile, historical data is used for forecasting. Speaking of velocity, the last 3-4 iterations’ moving average of the normalized velocity is a good starting point.
- When forecasting the next iteration, the planned absences also need to be considered.
- No partial credit! Giving partial credit overstates velocity, decreases predictability and transparency as well.
- Don’t treat velocity as a 100% accurate measure. Being roughly right is ok.
- Individual velocity is meaningless. Agile is about collaboration. Only the team velocity matters.
Check out the other posts in the velocity mini-series for details about the velocity.