AI
Cumulative Flow Diagram: Why Your Team Keeps Missing Deadlines
Teams fall behind when they start tasks faster than they finish them, and when new requirements and bug fixes arrive faster than old ones close, so work piles up in the middle of the process and each new task waits longer than the last. A cumulative flow diagram makes this visible - a chart where tasks in each status accumulate week by week. The fixes are a work-in-progress limit and a clear decision about which tasks not to take on at all.
Why everyone is busy and deadlines still slip
Busyness and throughput are not the same thing. Throughput is how many tasks the team actually completes per week. A person can be fully occupied all day while their tasks sit completely still.
Here is an episode reconstructed from one company's internal messages. At 10:00, a product manager sent a task to a designer. The designer was busy and opened it three hours later, read it for ten minutes, then asked questions because something was unclear. The product manager was in meetings and replied three hours after that. By then the designer was out of time - the workday had ended. They got on a call the next morning, and only then did a draft appear. Two hours of actual work stretched across three days and still came back with mistakes. The task spent far more time waiting than being done.
At a different company, the first pilots of new products sold well - so two teams were hired for the scale-up. They worked for six months and cost a lot. The scale-up failed. Almost everything got scrapped and rebuilt by a smaller core team in a month and a half. That version worked fine. More people did not mean more speed.
Full utilization tells you nothing about when a task will be ready.
How a cumulative flow diagram works
A cumulative flow diagram is a chart where the horizontal axis shows weeks and the vertical axis shows the total number of tasks that have entered each status since tracking began. Each status is drawn as a separate band.
There are as many bands as there are statuses in the process. In a task tracker those might be: backlog (tasks not yet started), "to do," "in progress," "review," "blocked," "done." Order fulfillment, deals in a CRM (customer relationship management system - software that tracks sales interactions), marketing tasks - any process with statuses can be drawn this way.
The bottom band, "done," only ever grows: tasks closed once stay closed. The top edge of the whole shape is everything that has arrived since tracking began. The thickness of any band in a given week shows how many tasks are in that status right now. The thickness of the "in progress" band is the number of tasks in progress - often called WIP, short for work in progress.
Two things help you read the diagram. The slope of a line shows speed: how many tasks cross that boundary per week. The horizontal distance between two lines shows how long the average task spends on that stretch. If the "started" line rises steeper than the "done" line, the team is picking up tasks faster than it closes them. One picture like that shows exactly where time is being lost.
Teaching example: a week-by-week table
The numbers here are illustrative. In week one, 20 tasks arrive; after that, 12 per week arrive. The team starts 10 per week and finishes 5.
| Week | Total arrived | Total started | Total done | In queue | In progress |
|---|---|---|---|---|---|
| 1 | 20 | 10 | 5 | 10 | 5 |
| 2 | 32 | 20 | 10 | 12 | 10 |
| 3 | 44 | 30 | 15 | 14 | 15 |
| 4 | 56 | 40 | 20 | 16 | 20 |
| 5 | 68 | 50 | 25 | 18 | 25 |
| 6 | 80 | 60 | 30 | 20 | 30 |
"In queue" is Total arrived minus Total started. "In progress" is Total started minus Total done.
To draw the diagram from this table you need three lines: one for each of Total arrived, Total started, and Total done. The band between the first and second line is the queue; between the second and third is work in progress. That WIP band grows by 5 tasks every week - the first of three patterns: a widening band. The top line rises by 12 per week, the bottom by 5 - the second pattern, diverging slopes. If 5 tasks arrived, started, and finished every week, all three lines would run parallel and band widths would stay constant - the third pattern, a healthy flow.
Three patterns you can spot immediately
In the table below, a defect is an error in work already completed - it has to be fixed and rejoins the queue.
| What the diagram shows | What it means | What to do |
|---|---|---|
| The "in progress" band widens | Tasks are being started faster than finished; each new one waits longer than the last | Set a WIP limit and finish what is already started before picking up anything new |
| The top line is steeper than the bottom | New requirements and defects arrive faster than they close; the queue grows and the team's internal pace cannot catch up | Count inflow separately by type, decide what to drop, remove the causes of defects |
| Bands run flat and parallel | Healthy flow: arrivals, starts, and completions match; lead time is predictable | Hold the WIP limit and check the diagram once a week |
What this looked like for one team
One team's diagram was built from its task tracker export. At the start it already had around 100 tasks in the system. Over the first five weeks the team picked up roughly eight tasks per week. The "started" and "done" lines diverged visibly: every week the team took on more than it finished properly - and that was obvious without any calculation.
A failure counter climbed in parallel. Some people produced a lot early on, then generated a lot of rework for others. For users nothing changed: complaints and support requests stayed constant no matter how many tasks the team took on.
Later the team started taking fewer tasks at a time. But the accumulated work had already done its damage - a task started around week four reached completion around week sixteen, about 12 weeks for a single item. Some tasks finished in a day; others took a month, reflecting the presence of large projects in the mix.
Little's Law: how long will a task take
The formula is called Little's Law. It connects three numbers.
Average lead time = average number of tasks in progress / throughput
Units must match: if throughput is tasks per week, lead time comes out in weeks. The formula holds for averages over a period when flow is roughly stable.
But the same division also gives a quick forecast for right now. Take the teaching data from the table above: if tasks are taken in order, a task started in week six has 30 tasks ahead of it, and the team completes 5 per week.
30 / 5 = 6 weeks from start to delivery
To forecast from the moment a request arrives, add the queue to the in-progress count. A request that arrives in week six has 20 tasks in the queue and 30 in progress ahead of it.
(20 + 30) / 5 = 10 weeks
About four of those weeks the task simply sits waiting.
This is a forecast at the current pace, not a Little's Law average. In this teaching example, flow is not stable - the queue and WIP keep growing, so the law itself does not apply here in its exact form. When 12 tasks arrive per week and only 5 finish, every new task waits longer.
The formula also explains the team story above: when the number of tasks in progress is large relative to weekly completions, a single task can take months.
Inflow vs. closures: why the backlog plan does not add up
A typical plan sounds like this: 150 units of work to do, the team closes 15 per week - so everything is done in 10 weeks.
150 / 15 = 10 weeks
But work keeps arriving: defects, clarifications, new requirements. In the teaching example: if 5 units are added each week, the backlog shrinks by 10 per week, not 15.
150 / 10 = 15 weeks
Five weeks behind plan. And if 15 units arrive per week, the backlog never shrinks at all.
Picture a bathtub: when water pours in as fast as it drains, the level stays the same. Rushing speeds up task closures and simultaneously generates new defects - ones nobody has noticed yet. A product's backlog can diverge: the count rises even though everyone is busy closing tickets.
Requirements at the start are always incomplete. Two to four weeks in, the team knows more about a task than it did at kickoff. Each clarification adds to the backlog.
A simple thought experiment. One interesting new task every three months - welcome. One per month - timelines are tight but manageable. One per week - the previous one is unfinished when the next one lands. One per day - there is no time to think before the next arrives. That kind of load is something organizations create through their own structure.
Inflow gets managed separately: count it by type - new requirements, defects, urgent requests - decide what to decline, and eliminate the root causes of defects so they stop returning to the queue.
Counting closed tasks alone shows only half the picture.
WIP limits: how to introduce them without a revolution
A WIP limit is an agreement on the maximum number of tasks allowed at a stage or per person at any one time.
How to do it in practice:
- Count how many tasks are currently in progress at each stage or per person.
- Agree on a limit lower than that number.
- A new task is picked up only when one current task is finished.
- Keep the queue visible and decide once a week what to work on first and what to drop.
- At a short daily check-in, ask one question: what is blocking you right now.
- Check the diagram weekly: the "in progress" band should stop widening.
A teaching calculation: the team closes 5 tasks per week, WIP limit is 10.
10 / 5 = 2 weeks from start to delivery
Compare that to 6 weeks with 30 tasks in progress from the earlier example - at exactly the same throughput.
Three caveats come with the limit.
Total lead time from request to result only shortens if the queue is actively managed: someone decides what comes first and what gets dropped. Otherwise waiting just moves from the "in progress" band into the queue, and the total time stays the same.
If 12 tasks arrive per week and the team closes 5, a WIP limit does not fix that imbalance. Inflow has to come down, throughput has to go up, or both.
After inflow drops, lead times do not fall immediately. The work that had already accumulated has to clear first - this shows up clearly in the team story above: the team started taking fewer tasks, but lead time had already grown to 12 weeks.
What AI changes and where to start
AI accelerates both flow and chaos. If one person with AI agents suddenly speeds up dramatically, they will hit the surrounding system - and that system's pace will slow them back down.
Automating a broken process produces the same broken process, only faster and at greater scale. That implementation mistake is examined in the article why AI projects miss their goals.
A flow diagram can be built automatically. An AI agent - software that carries out a defined task sequence - generates one from a tracker export with status-change timestamps, cheaply and quickly. The output still needs to be checked the same way as any other agent report. How AI handles complex spreadsheets and where to verify its numbers is covered in how AI reads a complex Excel file and builds a dashboard.
When agents do work that nobody reviews, their quiet errors become a defect inflow of their own: one thing gets fixed, two others break. Process quality matters more when agents work fast.
The first reaction to a cumulative flow diagram is usually: "probably every team looks like this." In practice nobody had measured it before. What you do not measure, you cannot manage - and many decisions that feel effective turn out, on the numbers, not to be.
Majento implements AI in working processes and starts with a single process: you need a process owner, data, access, and criteria - a definition of what a good result looks like. For an initial conversation, it helps to describe one process, the systems it runs on, and the change you want to measure. Average task lead time and number of tasks in progress are a solid starting point. The full approach is on the AI implementation page. How a team's working task becomes an implementation project is shown in the pilot demonstration.
Questions and answers
How is a cumulative flow diagram different from a burndown chart?
A burndown chart shows one number: how much work remains. When the remaining count stops falling, the chart cannot tell you whether the team slowed down or whether more work arrived. A cumulative flow diagram draws inflow, work in progress, and completions as separate lines, so the cause is immediately visible.
Does this work outside software development?
Yes. Any process with statuses qualifies: request handling, deal stages in a CRM, marketing tasks, e-commerce orders. You need data with status-change timestamps from a task tracker or CRM export.
What WIP limit should we set?
Start below your current number. By Little's Law, the limit is roughly equal to your target lead time multiplied by the team's throughput. Teaching example: the team closes 5 tasks per week and wants to finish within 2 weeks - so the WIP limit is around 10. That is a starting point; adjust it based on what the diagram shows over the following weeks.
Why didn't lead times drop as soon as we started taking fewer tasks?
The work that had already accumulated has to clear first. Tasks started during the high-load period are still moving through the system. The diagram will show it: the "in progress" band will gradually narrow.
Can we ask an AI agent to build the diagram?
Yes, from a tracker export with status-change timestamps. After it does, verify the result: the number of tasks in each status on a chosen date should match what the tracker shows for that same date. That check keeps a data export error from reaching your conclusions.
If you want to map your team's task flow and find where work stalls, message us on Telegram or email hello@majento.ai.