Where Is Work Piling Up? Specify a Workflow Flow Report, Not Just a Task Total
A current task board shows where work sits now. It does not show whether the review queue has been growing for weeks or only filled this morning. If the business question is where work accumulates, ask for a historical flow report with an explicit population and stage mapping, not merely a larger number labelled “open jobs”.
A cumulative flow diagram can help frame that discussion. It is not a staff productivity score, a promised completion date or proof that the people in the widest band caused the delay.
Separate a stock of work from work completed
For a hypothetical design studio, requests might pass through preparation, review and ready for handover. A snapshot of requests awaiting review answers how much is waiting at the chosen moment. A report of completed handovers during a period answers a different question. Do not use the same label for both.
The Atlassian Jira Cloud guide describes a cumulative flow diagram with time on the horizontal axis, work items on the vertical axis and coloured areas representing workflow statuses. It says an area widening vertically over time will generally indicate a bottleneck in the corresponding column. Treat that as a reason to inspect the underlying work, not an automatic diagnosis.
The review band might widen because more work arrived, because requests are missing information or because a downstream handover stopped. The picture alone does not establish which explanation is right. Give a named person responsibility for investigating the actual records before changing staffing or making customer promises.
Choose the records before choosing the colours
Atlassian documents that its report is board-specific and uses the board's saved filter. It also depends on column mapping, with the leftmost and rightmost columns defining its To Do and Done positions. This makes the report definition part of the meaning, not a cosmetic preference.
For your app, name the included service, team and work type. Decide whether requests awaiting initial acceptance belong in the same flow as accepted jobs. A large backlog of tentative enquiries should not silently become a measure of committed production work.
Define the counted unit. A parent job with several subtasks must not accidentally become several customer requests when someone changes the view. If work is deliberately split or combined, agree how the report represents that event and allows its effect to be explained. These are proposed reporting requirements, not behaviours established by the Jira guide.
Do not read cumulative boundaries as today's queue counts
Ask the developer to explain exactly what a band, its thickness and its upper boundary represent in the chosen implementation. Atlassian's worked example keeps earlier-column totals after work moves forward. It is therefore unsafe to treat every displayed cumulative value as the number currently waiting in that named stage.
Request a small companion table or an accessible explanation showing the chosen historical point, stage counts and contributing records. A person who cannot distinguish the colours should still be able to understand the result. The table must use the same filters and historical basis as the chart.
Keep actual completed work distinct from cancellations. Also agree whether a reopened job returns to the active flow and how that appears historically. Reopening is not necessarily a new incoming customer request. Do not promise a particular convention merely because the chart is called cumulative flow.
Preserve the meaning of past days
A report built only from today's statuses cannot reconstruct every earlier state. Ask what evidence supplies the history: recorded transitions, dated snapshots or another agreed method. Show where history is incomplete rather than drawing a convincing uninterrupted past.
Decide what happens when a status is renamed, two columns are merged or a job moves between teams. You may need a visible definition version or a marked break in comparability. Applying today's filter to past work and using each past day's original membership answer different questions; choose deliberately.
Historical reporting must also respect access restrictions. Drill-down should not reveal confidential jobs to someone who is authorised only to see a wider aggregate. Establish the permitted summary and record views separately.
Accept one traceable sequence
In your acceptance criteria, use fictional requests that enter the flow, wait in review, progress, finish, reopen and cancel. Check a period before the available history begins. Then change a filter or stage mapping and demonstrate the agreed treatment of earlier points.
Ask the developer to reconcile the visible queue with the report at the same observation time, explaining any cumulative boundaries rather than pretending they are all queue counts. Verify that table, chart and permitted record drill-down describe the same population.
Bring the question “which stage is accumulating work, and what will we inspect next?” to a workflow reporting discussion. A useful report supports an investigation. It does not replace one.
Source scope
The Jira Cloud documentation, read on 26 October 2026, supports the diagram description, widening-band interpretation, board-filter scope, column mapping and cumulative worked-example warning. Historical definitions, access controls and acceptance checks above are requirements to agree for your own application, not a certification of a live system.