Why Software Releases Slip: 8 Root Causes and a 30-Day Plan to Regain Predictability

Every delivery leader knows the feeling. The release was "on track" at the last steering meeting, and two weeks before the date someone mentions that integration testing has found problems, a dependency is late and a few stories are "nearly done". The date moves. Then it moves again.

When software projects are always late, the cause is rarely laziness or poor engineers. It is almost always the system the team works in. The good news is that the system can be changed, usually faster than people expect. This article sets out the eight root causes we see most often, how to work out which ones you have, and a practical 30-day plan to get predictability back.

Why release dates slip: it is the system, not the people

A release date is a forecast. It is based on how much work there is, how fast the team finishes work, and how much new work will arrive in the meantime. A date slips when one of those three things turns out to be different from what everyone assumed.

Most organisations try to fix slipping dates with more pressure: tighter deadlines, more status meetings, longer hours. That treats the symptom. In our experience, the teams that become predictable do something different. They make work smaller, finish things before starting new things, find problems earlier, and measure how work actually flows instead of how it was planned to flow.

Before you can do that, you need to know which causes are hurting you. Most teams have two or three of the following at once.

The 8 most common root causes of missed release dates

1. Work items are too big

Large stories and epics hide uncertainty. A piece of work estimated at "two weeks" often contains a dozen unknowns that only appear once someone starts building it. Big items also make progress invisible: a ticket that is "in progress" for three weeks tells you nothing about whether it will finish next week or next month.

Small items, ideally a few days of work each, surface problems early and give you frequent, honest signals of progress.

2. Too much work in progress

When every developer has three or four things on the go, everything moves slowly and nothing finishes. Context switching eats time, reviews queue up, and work sits waiting for someone to pick it up again. The board looks busy, but the release is no closer.

This is one of the most common causes and one of the cheapest to fix. Limiting work in progress (WIP) almost always shortens the time each item takes to finish.

3. Testing happens at the end

If quality is checked in a "testing phase" after development, defects are found late, when they are most expensive to fix and when there is least time left. The release date then depends on how many bugs testing finds, which nobody can know in advance.

Teams that build testing into each item, with automated checks, test cases agreed before coding starts and testers working alongside developers, turn a big unpredictable phase into small, routine steps.

4. Unclear priorities and too many stakeholders

When sales, operations, the CEO and two product managers can all add work to the team's plate, the team ends up serving whoever shouted last. Priorities change mid-sprint, half-finished work is abandoned, and the original release scope quietly grows.

Predictable teams have one clearly ordered backlog and one person (or a small, named group) who decides the order. Everyone else feeds requests into that process rather than around it.

5. Hidden dependencies

A feature that needs an API change from another team, a decision from legal, or access to a client's test environment is only as fast as its slowest dependency. These are often not visible on the team's board until they block something.

Mapping dependencies at planning time, and tracking them in a simple RAID log (risks, assumptions, issues, dependencies), turns surprises into managed risks.

6. Estimates treated as commitments

An estimate is a guess made with the information available at the time. When leadership treats it as a promise, teams respond in predictable ways: they pad estimates, hide bad news, or cut quality to hit the number. None of these make delivery more predictable.

A better approach is to forecast from real delivery data and express dates as ranges with a confidence level, for example "very likely by mid-March, possible by end of February".

7. A weak definition of done

If "done" means "the code is written", a lot of work is left over: code review, testing, documentation, security checks, deployment. That leftover work piles up and lands just before release. We often see boards where items move to "done" and then quietly reappear as bugs or "hardening" tasks.

A clear, shared definition of done that includes testing and being releasable means that what is done is truly done.

8. No flow metrics

Many teams track velocity or story points and little else. Those numbers say how much was estimated, not how long work actually takes to get through the system. Without flow metrics, nobody can see the queues and bottlenecks that cause slips until it is too late.

How to diagnose which causes you have

You do not need a large transformation programme to find out what is wrong. You need a few weeks of honest data and a willingness to look at it. Start with the warning signs, then confirm with metrics.

Warning signs to look for

• Items regularly stay "in progress" for longer than a sprint.
• Most stories are completed in the last two or three days of the sprint.
• Each developer is assigned to several tickets at once.
• Sprint goals change after the sprint has started.
• There is a "stabilisation" or "hardening" phase before every release.
• Status reports say "green" until shortly before the date, then turn red.
• Teams say they are "waiting on" another team or person every week.
• Nobody can say, with data, how long a typical item takes from start to finish.

What to measure

Five measures cover most of what you need. You can pull most of them from your existing work tracking and deployment tools.

Metric	What it tells you	Points to
Cycle time	How long an item takes from "started" to "done". Look at the spread, not just the average.	Oversized items, waiting time, late testing
Throughput	How many items the team finishes per week. The basis for honest forecasts.	Capacity, estimates treated as commitments
Work in progress	How many items are started but not finished at any one time.	Too much WIP, context switching
Carry-over	How much planned work rolls into the next sprint or iteration.	Overcommitment, unclear priorities, big items
Change failure rate	The share of releases that cause a failure needing a fix or rollback (one of DORA's four key metrics).	Late testing, weak definition of done

Read these together. For example, a team of eight with twenty items in progress, long and widely spread cycle times, and a third of each sprint carried over almost certainly has a WIP and work-size problem before it has an estimation problem. A team with short cycle times but frequent failed releases should look first at testing and its definition of done.

If you would like a structured way to run this check, download our free Agile & AI Delivery Health Check. It walks you through the warning signs and metrics above and helps you rank which causes to tackle first.

For a deeper look, a formal software delivery assessment analyses your actual delivery data, from tickets to deployments, and identifies where time is really being lost.

A 30-day plan to improve delivery predictability

You will not fix everything in a month, but you can make dates noticeably more reliable and build the habits that keep them that way. Here is the plan we typically use as a starting point.

Week 1: Get a baseline

• Export the last two or three months of work items and record when each was started and finished.
• Calculate cycle time, throughput, current WIP and carry-over for each team.
• Count failed or rolled-back releases over the same period.
• Walk the board with each team and list every item that is blocked or waiting, and on whom.
• Write down who can currently add work to each team's backlog. Many leaders are surprised by how long this list is.

Week 2: Stop starting, start finishing

• Agree a WIP limit for each team. A simple rule of thumb is fewer items in progress than there are people on the team.
• Name one person who orders each team's backlog and agree how other stakeholders submit requests.
• Split any item expected to take more than about a week into smaller, independently testable pieces.
• Write or tighten the definition of done so it includes review, testing and being ready to release.

Week 3: Move quality and dependencies forward

• Agree acceptance criteria and test cases before development starts on each item.
• Pair testers with developers on new work rather than handing over at the end.
• Add the most valuable automated checks to the build pipeline, starting with the areas that break most often.
• Start a lightweight RAID log for each release, and review dependencies in a short weekly cross-team session.

Week 4: Forecast from data and set the rhythm

• Use throughput from the last few weeks to forecast remaining work as a date range, not a single date.
• Replace "percentage complete" status reporting with a short flow report: cycle time, throughput, WIP, carry-over and change failure rate.
• Hold a retrospective on the 30 days. Keep what worked, drop what did not and pick the next one or two causes to address.
• Agree a monthly review of the metrics with leadership so improvements stick.

Mistakes that make slipping worse

Some well-intended responses tend to make the problem worse. Watch out for these.

• Adding people late in a project. New joiners need onboarding and add communication overhead, so they rarely speed up a release that is already late.
• Measuring individuals instead of flow. Comparing developers' output encourages people to start more work and avoid helping each other, which increases WIP.
• Changing the process for everyone at once. Start with one or two teams, prove the approach and then spread it.
• Buying a tool to fix a behaviour problem. A new board or dashboard will not limit WIP or settle priorities. Agreements between people do that.
• Using AI tools to write more code faster without fixing flow. AI coding assistants can speed up parts of the work, but if testing and review are the bottleneck, more code simply creates longer queues. Our guide to AI in software delivery covers where AI genuinely helps.

Making predictability last

The first 30 days build momentum. Keeping it requires some structure. Predictable organisations usually have three things in place.

First, clear governance: a simple way to decide priorities across teams, track cross-team risks and handle scope changes. For many companies between 30 and 500 people, a lightweight PMO does this job well. Our article on how to set up a PMO explains how to do it without adding bureaucracy, and our PMO setup services can put the operating model, RACI and RAID templates in place for you.

Second, skilled teams and leaders. Product owners need to be able to split work and say no. Scrum Masters and delivery managers need to read flow metrics and coach teams through bottlenecks. Targeted Agile coaching and training builds these habits faster than documents alone.

Third, regular inspection of the data. A monthly look at cycle time, throughput, WIP, carry-over and change failure rate keeps conversations grounded in facts rather than opinions. If you are running a wider change programme, connect these measures to your goals, for example through OKRs, as part of an Agile transformation.

Get your release dates back under control

Slipping releases are a signal, not a verdict. They tell you something in the delivery system needs attention. Find the two or three causes that matter most for you, measure them, and work through them steadily. Most teams see their forecasts become more reliable within a few sprints.

If you would like an experienced view on where your delivery is losing time, book a free discovery call. We will talk through your situation, with no obligation, and suggest the most practical next step.