Organizations aim to improve their “speed” and so focus on agile velocity as a metric. Velocity is a historical fact, relevant only to the Scrum Team.
When managers ask how to “improve velocity,” they are really asking, “How can we provide greater value more frequently?” Generally speaking, our advice is to focus on removing impediments and waste. When focusing on velocity, you can sacrifice quality in the interest of “accelerating.” Concentrating on removing waste and barriers actually increases quality and gives more time for doing the job correctly while also improving delivery speed.
Velocity is meaningless without context. A Development Team may deliver increased value, more frequently, and with higher quality, while decreasing its velocity, simply by factoring in better methods of working.
focus on removing the limiting factors for the Scrum Team focus stakeholders on “value metrics,” rather than delivery metrics. If you are considering starting to use Scrum, here are a few things nobody had mentioned about Scrum before.
Good Read: Scrum is Easy.Use it as Is
I’ve seen three main types of Agile Velocity misuse. This is a guide for heroes on how to avoid pitfalls and use Agile Velocity for good instead of evil.
1) Agile Velocity abused by Dev Leaders as a team comparison metric
Fortunately, I didn’t do this. Some leaders I know were unlucky.
This is how it works: Your teams are all using Agile Scrum. Velocity is tracked on an iteration-by-iteration basis. Your gut intuition tells you that your teams are “performing better” and “performing worse”. You have the urge to see which teams complete the most storey points per iteration and which teams have the least. You’re curious. And then you start to wonder, who has the “best” velocity? You might show and compare velocity in your management meeting or scrum of scrums.
2) Agile Velocity abused by Executives as a performance metric
No secret… executives love data. Also performance-related metrics.
Our biggest concern as software development leaders is that we don’t have standard metrics for our teams’ health and performance. In comparison to other departments (sales, marketing, finance), we have nothing when it comes to data-driven team performance.
Sales has revenue, pipeline, and sales cycle length. Marketing has: MQLs, SQLs, and CAC. Positive and negative employee engagement and retention rates for the HR
Business leaders get these measurements. They know what looks good and bad. They know the keys to success. To which levers should they pull to help leaders who need assistance?
Most CEOs aren’t trained in engineering, so they don’t have the tools they need to understand engineering as well.
Good Read: The Difference Between Agile and Scrum
3) Velocity in Agile as a false predictor of project delivery date
We’ve survived two of the common pitfalls. Neither should the use of velocity be made in executive boardrooms or at the level of teams.
Now the plot thickens. The project manager is interested in calculating when the project will be finished. Tickety-boo! Too easy. We know the team’s velocity across multiple iterations, all we need to do is analyse epic components and see how long it will take to complete. Done.
Unfortunately, long-term projects spanning multiple sprints cannot be estimated using velocity. I’ve seen numerous attempts, and they all failed. With good intentions, many false expectations are created. Project completion has been intentionally prolonged to require engineering.
Important Tip#
How is the initial velocity estimated?
An agile team’s first iteration should be planned at one-third of available time. Meetings, email, design, documentation, rework, cooperation, research, etc. are all included in determining optimal programmer time. The first iteration is also when velocity emerges. Iteration velocity increases as new features are added, and decreases as features are eliminated if velocity is underestimated. The scrum team should utilise the first iteration as a reference for the second.
