What is it?
Dora stands for:
- Dev
- Ops
- Research
- Assessment
Useful Resources:
DORA | Get Better at Getting Better
It’s a team supported by Google, set up to study, survey and draw insights from 1000s of development teams across a wide range of industries and businesses.
The body of work aims to answer the question:
What makes a high performing team different to a low performing team?
The DORA metrics are broken down to cover two core areas:
- Stability is a measure of the quality of the software that we produce.
- Throughput/speed is a measure of the efficiency of our approach.
When you look at the metrics holistically covering both areas, it’s better because you get a much better balance of the overall system. For instance, if you were to only measure throughput (number of items or points moved to done in a given period of time), quite often quality could be forgotten or an afterthought.
Through six years of research, the DevOps Research and Assessment (DORA) team identified four key metrics that indicate the performance of a software development team:
| Metric | What it aims to answer | Why its important | |
|---|---|---|---|
| THROUGHPUT | Deployment Frequency | How frequently are we releasing? Can we understand the size of the releases as well as the frequency?Measure by the number or releases to production. | The more you deploy the smaller the size will be and with that the risk associated with making the change will be reduced. |
| Change Lead Time (CLT) | How long does it take for a commit to go from being authored to being deployed? Measured from the moment a developer starts working on a change to when it is shipped to production. You can break this out and identify queues and bottlenecks. | If you know where time is spent you can look to optimise it. To improve CLT, remove bottlenecks. It measures how quickly teams can respond to change in events or needs. Companies that are able to deliver quicker tend to be more successful than their competitors. | |
| STABILITY | Mean time to recovery (MTTR) | How long on average does it take to resolve an incident?Measured from when you detect there is a problem to getting the change out that fixes it. | Feature flags allow you to reduce your MTTR time down to seconds. |
| Change Failure Rate (CFR) | How often does a change cause a failure? Measured as a ration of the number of failures divided by the total number of deployments for a given period of time. To start we need to know, what defines a failure? |
- These metrics are more gages than targets – how we interpret them will depend on context.
- They’re a benchmark for helping to better understand the software development process.
- They provide measurable and meaningful data that can promote improvements in the lifecycle of shipping software changes in products and features.
- They can help engineering teams to ship more frequently, reduce mistakes and testing time, and get updates to end users faster.