How to find bottlenecks in a software release process
Draw the release process as a flowchart, count what leaves each decision, then show the counts as a Sankey diagram. Find the gate where builds fail, return or wait the longest.
A release bottleneck is the gate where work piles up, fails or comes back. This guide draws the process first, so every gate is a decision with named exits, and then counts releases through those exits.
The short version
- Draw the process as decisions with labelled exits before counting anything.
- Count releases (or builds) through each exit for one period.
- A gate with a wide return branch is a bottleneck, even if it is fast.
- Show the counts as a Sankey diagram, and use the flowchart to explain them.
Start with the gates, not the numbers
Teams usually look for the slow step by averaging durations. That finds slow tasks, but not the gates that send work backwards. A release can spend one day in testing and still lose a week, because a failed test returns it to a fix step and the cycle runs again. The way to see that is to draw the process with its decisions and count how many releases take each exit.
A flowchart gives you the structure: each decision has labelled branches, and each branch has a count. The example is a release process with four decisions: automated tests, go or no-go, production health, and production defects. Once you have counts per branch, a Sankey diagram shows them as widths. See /sankey/ci-pipeline-outcomes for the build stage, and /sankey/pull-request-review-flow for the review stage that comes before it.
Keep the claims modest. Counts show where work leaves a gate, not why. The reason comes from reading the failed items, and from the people who run the gate.
A release process, built in stages
Twenty steps and four decisions. Each decision is a place where a Sankey would show work leaving in two directions.
Build and automated tests
The process starts at code complete, freezes scope and runs the automated tests. The first decision, "Automated tests pass?", has a Fail branch that loops back through a fix step to the build. That loop is the first place to count.
Staging, sign-off and the go decision
A build that passes goes to staging, regression and user acceptance, and the readiness record is assembled and approved. "Go or no-go?" has a No-go branch that returns to the fix step, so a release can come back from late in the process.
Production and the way back
The release is deployed in its window and smoke tested. "Release healthy?" splits to monitoring or to a rollback that returns to the fix step. A rollback is the most expensive exit, so its count matters most.
Monitoring and hotfix
After the soak period, "Production defect found?" sends the release to a hotfix, which re-enters at deployment, or to release notes and close. Count how often the hotfix branch is taken.
How it works
Draw the process with its decisions
Put every gate in as a decision with labelled exits, such as Pass and Fail. A gate drawn as a plain step hides the exit you want to count.
Pick a period and a unit
Take the last quarter and count releases, or builds if you release often. Say which in the data note.
Count what leaves each decision
For each decision, count how many items took each exit. Take the numbers from your CI system, tickets or release log.
Draw the counts as a Sankey diagram
Use the decisions as nodes and the exits as flows. Check that what enters each node equals what leaves it.
Read the widest return branch first
The widest branch that points backwards is the likely bottleneck. Read those items to find out why.
Mistakes to avoid
Counting only the final outcome
If you count only what shipped, the loops disappear. Count at each decision, or the Sankey will show a smooth process that did not happen.
Mixing units
Builds, releases and tickets are different units. Choose one for the whole chart and say so.
Reading counts as causes
A wide Fail branch says tests fail often, not why. Look at the failed items before changing the process.
Open the software release flowchart
Open the release template, adapt the gates to yours and count the exits.
Related guides
Frequently asked questions
Why draw a flowchart if I only want a Sankey?
Because the flowchart decides what the nodes are. Without it the Sankey shows whatever stages your tool happens to export, which are often not the gates people decide at.
How many releases do I need?
Enough that each exit has more than a few items. With fewer than about 20, show the counts in a table rather than a chart.
Does this replace measuring lead time?
No. Lead time says how long; the Sankey says where work leaves or returns. Use both, and compare them for the same period.