Overview, focus and working agreements

New to DORA? Start with What is DORA?, then come back here.

The Overview page is the first thing you see in Engineering Delivery. It tells you, in one screen, whether delivery got better or worse in the period you chose, which one thing your teams are working on, and whether they are keeping the working agreements they set. This guide explains everything on it, answers the questions it raises, and then covers the part that matters most: how to actually improve, one constraint at a time.

You find it under Brief, the first place on the app's rail. New to the app as a whole? What is Engineering Delivery? explains how it is laid out.

What the Overview page shows

The page has these parts, from top to bottom: the update and the focus card side by side, the headline measures, your teams (when you can see more than one team), focus areas, and worth a look.

The update and its status

At the top, the Delivery update sums up the period in a sentence, such as "You're shipping faster, 4 deploys a week and 3 days to customers, and fixes fell to one deploy in eight." Next to it sits a status word, so the status never depends on colour alone. When nothing was deployed or merged in the period, there is no status word at all, only the sentence "Nothing was deployed or merged in this period, so there is nothing to measure yet."

"Speed" here means deployment frequency and change lead time. "Fixes" means change fail rate, the share of deploys that were rolled back or hotfixed, which the update puts in words such as "one deploy in eight". Every comparison is with the period before, never with other teams or an outside grade.

When a measure your team set a goal for is on the wrong side of it, the update says so first. And when a goal is missed or a measure got worse than the team's own last 90 days, the update shows What to improve next: a short "Where", "Why" and "Try" for the team, written by the app's fixed rules, with a link to the published source each "Why" rests on. Goals, alerts and Scout explains both.

The focus card

The Focus card holds the one constraint your teams are improving right now. A constraint is the step that holds everything else back; Find your biggest constraint below explains the idea. An admin picks it in Settings, and anyone who can edit sees a Change focus button.

When the focus has a goal, the card shows how far along the team is, and "Met" once it gets there.

The headline measures

Below the update come the headline tiles: Deployment frequency, Change lead time, Change fail rate, Failed deployment recovery time and AI spend. The first four are DORA metrics; The five DORA metrics explains them all. Each tile shows the value for the period, how it moved against the period before, and opens the page that explains it in detail: Speed for deploys and lead time, Quality for fail rate, Incidents for recovery time and AI for spend. A tile the app cannot read yet, because a tool is not connected, says what it needs instead of guessing; see why a tile says it is not measured.

The row "How these are measured" opens a short guide for each tile: why it matters, how it is measured, what good looks like and where to start.

Your teams

When you can see two or more teams and have not chosen one, the Brief shows Your teams: one row for each team, so you can see at a glance which team is fine and which could use a conversation. Each team is read against its own goals and its own last 90 days, never against another team. Teams do different work, so the table is not a ranking.

Only teams at least as large as Smallest team shown on its own in Settings (3 engineers unless an admin changes it) get a row, so no one can be singled out. While Names on items or Claude Code by person is on, people are shown by name anyway, so every team gets a row. The teams left out are named once under the table, and an admin gets a link to the setting. Choose a row to open that team's own view.

The status reads every goal set in Settings against the team's own figure for the period. It also reads the throughput and instability measures, and the wait for a first review, against the team's own 90 days before the period.

A measure only counts as worse when it moved by more than ordinary noise, and only when both windows had enough changes or deploys to read it. When a measure moves gives the exact rule.

Where to start: open the team that needs attention first, and ask the team what would help before comparing anyone.

Team badges

A good run or a real improvement is worth saying out loud. Badges are for teams, never people, and only for a team doing well against its own past. Each badge is given by a fixed rule, the same for every team, and says exactly why when you point at it.

When teams tie at the top, they all get the badge, so none is picked at random. A team shows at most two badges, in the order of the table. No published source gives a figure for any of these: they mark a team doing well against its own past.

A good way to use them: ask the team with a badge what changed, and share it with the others.

Focus areas

Focus areas lists "the working agreements your teams set, and where they are slipping. Misses list changes, never people." Each agreement shows its status and trend. Working agreements below explains them in full.

Worth a look

Worth a look picks out the few things in the numbers that deserve a second look. An item only appears when its trigger fires:

• Review wait appears when the wait for a first review is more than half of the time to merge. It reads like "14h of the 20h to merge is the wait for a first review", and opens Review.
• "{service} fixes", for example "Payments fixes", appears when one service's deploys needed a fix at least 5 percentage points more often than every other service's. It opens that service's releases.
• Unreviewed merges appears when more changes were merged with no approving review than in the period before. It needs attention once they reach 10% of merges.
• Change size appears, as good news, when the median change got smaller.

The list shows only the items that need attention or are mixed. Good news, such as Change size, waits behind a line "N more with nothing that needs you" until you choose to show them all.

Underneath, a footnote states the rules the whole app follows: "Every figure is read against your own recent past, never an outside grade. Quality is shown per service, everything else by team. No one is ever named." When an admin has turned on Names on items, its last sentence reads "No one is ever ranked: names show only on the items a figure opens." instead.

Questions the app raises

The status says Mixed. What does that mean?

It means the period brought good and bad news together, so neither "Improving" nor "Needs attention" would be fair. The usual cases: you deploy more often but more deploys needed a fix, or changes reach customers faster but you deploy less often. Read the sentence next to the status; it names which numbers went which way. Then open the measure that got worse. Faster with more fixes usually points at change size or review, so start with Review.

The status says Needs attention. Is something broken?

Not necessarily. It means delivery slowed or more deploys needed a fix compared with the period before. A holiday month or a big migration can do that. Check the update sentence for which measure moved, open its tile, and look at the items behind it before drawing conclusions. If it stays there for a second period, make it the team's focus.

What does Worth a look: Review wait mean, and how do I fix it?

It means most of the time a change takes to merge is spent waiting for someone to start reviewing it, not in the review itself. The fix is picking reviews up sooner: agree a review window as a team (one working day is the most common), review before starting new work, and keep changes small so they fit between other tasks. Set "The queue before code review" as your focus and add a "First review within 24 hours" working agreement to make it stick. Time to first review has the detail.

Worth a look names one service's fixes. What should we do?

That service's deploys needed a fix clearly more often than any other's. Open its releases from the item, take the last few that needed a fix and look, without blame, for what they share: size, a missing test, one fragile area. Add an automated check for the most recent failure. Change fail rate by service explains how to read it.

Which focus should we pick?

Pick the step where changes wait longest. Open Speed and look at where the time goes: if waiting for review is the longest step, choose "The queue before code review". If changes are large and often need fixing, choose "Smaller changes". If deploys keep needing rollbacks or hotfixes, choose "Safer releases". Keep one focus for at least a month, so a change has time to show.

Why does the focus card show no figure?

"Time spent building" and "The wait to deploy" are not measured yet, so the card can only describe them. If you want a number to track, pick one of the other three.

An agreement says Slipping. What now?

Slipping means the share of changes keeping the agreement is below the team's goal and falling. Open the misses from the agreement and talk about them in the retro: why did each of these changes wait, or grow so large? Often one cause explains most of them, such as a reviewer away or one large piece of work. If the threshold is simply unrealistic for now, adjust it. Working agreements covers how to use them well.

A tile says Not connected or not measured. Why?

The app only shows what it can read from a connected tool, and never estimates. Setting it up lists what each measure needs.

How to improve delivery

The rest of this guide is about the part the Overview page cannot do for you: changing how the team works so the numbers move.

You improve software delivery by finding the one thing that slows your team down most, changing it, and checking whether the numbers moved. The DORA metrics tell you how delivery is going; the practices behind them, which DORA calls capabilities, are what you actually change.

Why the metrics alone do not improve anything

The metrics are a gauge, not a lever: they show how delivery is going, but you change them by changing how the team works.

DORA's research describes a chain. A team's practices and conditions, such as automated testing, small changes or a healthy culture, drive its software delivery performance. Delivery performance in turn drives how well the organisation does and how the people in it feel. DORA calls these practices capabilities. The capabilities its research supports most firmly, together with the metrics and the outcomes, are called DORA Core.

The 2025 DORA report puts it plainly: the five metrics "are ultimately outcomes. They tell you what is happening, but they don't explain why." A low deployment frequency might come from technical debt, from slow approval processes or from a tired team, and the number alone cannot tell you which.

So the useful question is never "how do we raise the number?". It is "what is in our way, and which practice removes it?".

Note: If you have not met the five metrics yet, read The five DORA metrics first. This page assumes you know roughly what change lead time and change fail rate mean.

Find your biggest constraint

The fastest way to improve is to find the single biggest bottleneck in how a change reaches your customers, fix that one thing, and then look again.

A constraint is the step that limits everything else. If every change waits two days for someone to review it, making the tests ten minutes faster will not help much: the work still piles up in front of review. Improving anywhere other than the constraint mostly moves the queue around.

DORA describes the same loop in its metrics guide and in the 2024 report (page 16). Here it is in plain steps.

1. Pick one application or service

Choose the application or service you want to improve, and measure that, not a blend of everything the department owns. DORA's metrics guide warns against comparing very different systems: a payments service and an internal admin tool have different risks and different rhythms.

2. Gather the people who build and run it

Bring together the cross-functional team responsible for it: the developers, and whoever tests, releases and operates it. DORA's guide lists "siloed ownership" as a common pitfall. If only the developers look at the numbers, the parts of the process that sit with other people stay invisible.

3. Agree where you are today

Measure your current performance and agree on it as a team. This is your baseline. DORA's free Quick Check is five multiple-choice questions that help start this conversation, compare your answers with others and suggest which capabilities to look at. If you already measure the metrics from your tools, use those numbers instead.

4. Map how work flows

Draw out every step a change goes through, from someone starting work to it running in production. DORA recommends a value stream mapping exercise for this, and its value stream management guide breaks it into steps:

1. Agree a clear outcome first. "Improve delivery" is too vague. "Cut production deployment failures below 10% within three months" is the kind of goal DORA suggests.
2. Map the steps, starting simple, from commit to production.
3. Mark where work waits between steps and where it is handed from one team to another. Handoffs are where delays tend to hide.
4. Collect rough numbers for lead time, cycle time and deployment frequency. DORA notes that low precision is fine at first: you are looking for the big bottleneck, not a perfect measurement.
5. Pick the friction point that most affects your outcome and is realistic to fix.

5. Commit to one change, then re-measure

Agree on an improvement, give it real time in the team's plans, and do the work. After it has had a chance to take hold, measure again. Did the metrics move? What did you learn? Then repeat the loop. DORA's 2024 report reminds readers that "change does not happen overnight".

A worked example

The 2025 DORA report (page 22) walks through a made-up but typical team. In a retrospective, they notice that their lead time for changes is starting to grow. They might have seen it on a dashboard, or simply noticed it; DORA points out that precision is not always needed. Looking at data from their code repository, they find that code reviews seem to be taking longer. They agree to make reviewing part of everyone's daily work and to aim for smaller changes that are easier to review, and to look at change approval times and all the delivery metrics again in a month.

Our own fictional example works the same way. A team of six builds an online booking app. Their median change lead time is five days. When they split it into steps, a typical change spends half a day being written, two and a half days waiting for a first review, a day in review and a day waiting for the weekly release. The biggest wait is the queue before review, so that becomes their one focus for the next month. Faster tests can wait.

Tip: In the app, Where the time goes on the Speed page breaks lead time into steps like this for you.

The practices that move the metrics most

DORA's research has identified a few dozen capabilities, and it keeps a catalogue of them. You do not need them all at once. These are the ones most teams meet first, explained without jargon.

Working in small batches

Ship work in small pieces that each take hours or a couple of days, rather than big pieces that take weeks. Small changes are easier to review, test and undo, and you learn sooner whether they work. DORA's working in small batches page says that a feature taking more than a week to complete is too large, and that recombining small pieces into one big release before testing throws the benefit away. Hiding unfinished work behind a feature flag lets you merge small pieces before the whole feature is ready. Small batches are part of DORA Core and also one of DORA's seven AI capabilities, because AI tools tend to produce large changes.

Continuous integration

Everyone merges their work into the shared main line of code often, and an automated build and test run checks each change. Problems show up within minutes instead of at the end of a long project. See DORA's continuous integration page and the glossary.

Test automation

Tests that run by themselves on every change, so people do not have to check everything by hand before a release. Without them, every deploy needs a slow manual check, and teams start batching changes to reduce the number of checks. See test automation.

Deployment automation

Getting a change into production with one command or one click, the same way every time, instead of following a long manual checklist. It makes deploying cheap enough to do often, and makes rolling back just as easy. See deployment automation.

Trunk-based development

Developers work on short-lived branches, or straight on the main line, and merge back quickly, instead of keeping long-running branches that drift apart and cause painful merges. See trunk-based development and the glossary.

Streamlining change approval

Many organisations make every change wait for approval from a change approval board, a group outside the team that reviews releases. DORA's research found that this kind of heavyweight external approval hurts delivery performance and found no evidence that it lowers change fail rates. Boards like this tend to push teams towards larger, less frequent and riskier releases. DORA's streamlining change approval page suggests peer review inside the team's normal workflow, automated testing and monitoring to catch bad changes, and turning the board into a group that coordinates and improves the process rather than reviewing each change.

Work in process limits

Agreeing a maximum number of things the team works on at once, and finishing work before starting more. DORA's work in process limits page warns that giving people several tasks at once in the hope of getting more done makes everything take longer and burns the team out. The Flow of work guide covers this in detail.

Loosely coupled teams

Teams that can change, test and release their part of the system without waiting for other teams. If shipping a small change needs three other teams to coordinate, every change is slow no matter how good each team is. See loosely coupled teams.

Monitoring and observability

Being able to see how your system behaves in production, so you notice problems quickly and can work out why they happen. That is what lets a team find and fix a bad deployment fast, which is what failed deployment recovery time measures. See monitoring and observability.

Documentation quality

Internal documentation that is accurate, up to date and easy to find. It sounds unglamorous, but DORA treats it as a Core capability, and the 2024 report found that more AI adoption went together with better documentation. See documentation quality.

Generative culture

A culture where information flows freely, people cooperate across teams, failures lead to learning rather than blame, and bad news can be raised safely. See generative organizational culture.

User-centric focus

Keeping the needs of the people who use the software at the centre of what the team builds. The 2024 DORA report called user-centricity "the ultimate driver of performance", and the 2025 AI Capabilities Model found that AI tools can harm teams that lack this focus: they can end up moving fast in the wrong direction. See user-centric focus.

Note: You will not fix all of these at once, and you should not try. Use the constraint you found in the previous section to choose which one to work on first.

Working agreements

A working agreement is a simple promise a team makes about how it works, such as "every change gets a first review within 24 hours", which turns a retro conversation into something the team can check.

Retrospectives often end with good intentions like "let's review faster" that fade within a week. A working agreement makes the intention concrete: a threshold, and a goal for how often the team keeps it.

Good first agreements

Most teams start with one of these:

• First review within 24 hours. Google's engineering practices say one business day is the maximum time it should take to respond to a code review request. See Code review speed and size.
• Changes under 400 lines. Smaller changes are reviewed faster and more carefully, and break less often. See Change size.
• Merged within 7 days of opening. A change that sits open for weeks drifts away from the main line and becomes hard to merge.

For each one, the team also sets a goal for the share of changes that should keep it. "90% of changes get a first review within 24 hours" leaves room for the occasional change that genuinely needs longer.

How to use them well

1. Start with one or two agreements. More than that and nobody remembers them.
2. Look at the misses in the retro. A miss is not a failure to punish. It is a change worth talking about: why did this one wait, and what would have helped?
3. Adjust as the team learns. If the team keeps an agreement easily, tighten the threshold or raise the goal. If it never does, the threshold may be unrealistic for now, or something else is in the way.

No published source gives a share of changes that a team should keep. Set each goal from your own recent past and raise it as the team gets there.

Warning: An agreement is about how the team works, never a way to single out a person. Talk about the change that missed, not who made it.

How Solidafy checks working agreements

In Solidafy's Engineering Delivery app, a team sets its agreements in Settings. The app checks each agreement against every change the team merged in the 8 weeks up to the end of the period you are looking at, and shows the share that kept it, week by week, against the team's goal. Changes opened by bots, such as Dependabot, are left out, and so is any change the agreement cannot be read for, such as one whose tool reports no size.

Each agreement gets a status:

• Kept: at or above the goal.
• Close: below the goal, but within 5 points of it.
• Slipping: below the goal and falling.
• Below goal: below the goal, and not close.

The trend compares the later four weeks with the earlier four. Misses are listed as changes, never as people, so the retro can open them one by one.

How Engineering Delivery helps

The app is built around the loop on this page: one constraint at a time, measured against your own past.

• The focus card keeps the one constraint in front of everyone, with the measure that tracks it and a button to the changes or releases behind it.
• What to improve next gives each section a short, team-level suggestion when something is off, written by the app's fixed rules and citing the figures and the published research it rests on.
• Goals and alerts turn a target into something the app checks, starting from a suggestion with its source, never a grade. See Goals, alerts and Scout and, for benchmarks, Performance levels and benchmarks.
• Working agreements are checked against every merged change, as described above.

Common mistakes

• Chasing the number instead of the cause. DORA's metrics guide warns about Goodhart's law: when a measure becomes a target, it stops being a good measure. A team told to deploy more often can split one deploy into five without delivering anything faster.
• Improving everything at once. Spreading effort across ten initiatives usually means none of them takes hold. Pick the constraint.
• Comparing teams. Different systems carry different risks. Compare a team with its own past.
• Adding process after an incident. DORA's change approval research lists "adding more process in response to production problems" as a common pitfall. It usually makes releases bigger and riskier.
• Giving up during the dip. Many changes make things a little worse before they make them better, while people learn. DORA calls this the J-curve; the AI and software delivery guide explains it.

Learn more

Official sources:

• DORA's software delivery performance metrics, including the improvement process and common pitfalls
• DORA capabilities catalogue
• DORA Quick Check
• DORA value stream management guide
• Accelerate State of DevOps Report 2024, "Using the software delivery performance metrics", page 16
• State of AI-assisted Software Development 2025, "Putting software delivery performance into practice", page 22
• Google engineering practices: speed of code reviews

Related Solidafy guides:

• What is DORA?
• The five DORA metrics
• Change lead time
• Code review speed and size
• Flow of work
• DORA performance levels
• Throughput and instability
• Team profiles
• Connecting Claude Code