In the context of software engineering, let’s talk about why Velocity is an unhealthy metric to measure and why DORA metrics are better.
If you are a product or software engineering leader facing challenges to becoming an effective leader, I can help! I am a fractional CTO, startup advisor, and coach at Mossa Labs. Reach out to me for an online discovery meeting! I provide leadership coaching to senior leaders.
In software engineering, Velocity is often expressed as the rate of work completed per a certain amount of time. Number of lines of code, number of features, how much storage (in KB or MB) is the source code modified, etc.
velocity = work completed / time period
However, is that the suitable unit of measurement for software? Can you assume that everything created will bring you value? Are you certain there will be no bugs in any work generated? And will end users like any of the work produced?
The work we do as software engineers is intelligence work; we solve problems and try to delight the users by choosing the right solution to get the job done with a certain level of quality involves.
And as managers, is Velocity the metric we want to push team members to focus on without also caring about the quality of work? There are other considerations for using Velocity, which makes workplaces less equitable and less inclusive. (This is not a topic we will cover in this article.)
DORA metrics, which stand for DevOps Research and Assessment, are used to measure the performance of software development and deployment processes. Four specific areas of focus in DORA metrics:
- Cycle time
- Deployment frequency
- Change failure rate
- Mean time to recover
Cycle time measures the time it takes from when a code change is committed to when it is successfully deployed to production.
Cycle time = time to deploy - time to commit
Depending on the team’s software methodology, measurements here vary and can be calculated under change lead time as well, from when end users request a change.