Read Work in Progress and Throughput as Different Counts

Work in progress is a snapshot of work that has started and has not finished under a stated workflow definition. Throughput describes finished work over an interval. Those numbers answer different questions. A team can finish several items while its work-in-progress count stays the same because other items entered the workflow. Read the snapshots and the events together before interpreting a change as evidence of speed or productivity.

This guide uses an invented eight-item workflow and a local event-counting utility. The exercise reconciles opening work, starts, finishes, cancellations and closing work. It does not measure a real team, recommend a staffing level or predict delivery dates. Its practical purpose is to make the definitions and arithmetic visible before a management discussion relies on a dashboard number.

Define the workflow boundary before counting

Write what counts as started and what counts as finished for the work being examined. A request received is not necessarily a task started. A draft produced may not be a finished deliverable if review is part of the workflow. The definition should describe the actual process and remain understandable to the people supplying the records. Do not let a convenient software column silently decide the meaning.

The Kanban Guide defines work in progress and throughput in relation to a workflow's start and finish points. That is useful conceptual context, not validation of this invented event model or a claim that every organization must use this worksheet. The example below uses one explicit start event and one terminal finish or cancellation event per item. Other processes may need a different model.

Keep a backlog outside the example's started-work count. An unstarted request may matter to planning, but adding it to WIP changes the measure. A report can show backlog and WIP side by side if the labels remain clear. Avoid combining them under a broad heading such as work remaining and then treating the total as the number of items actively inside the defined workflow.

Distinguish a snapshot from an interval

A snapshot asks how many qualifying items are open at a particular instant. An interval asks which events happened between two instants. In this example, the opening snapshot includes events up to and including the start time. Interval events occur after that start and up to and including the end time. That convention assigns a boundary event once rather than counting it in both places.

The closing snapshot includes all events up to and including the end time. The convention is a definition for this exercise, not a universal rule for reporting systems. If another report uses a different boundary, the totals may differ for events exactly on the cutoff. Preserve the convention beside the report so another reviewer can reproduce the result without guessing which side contains the boundary event.

Use an explicit time basis in the practice file. The utility accepts UTC timestamps ending in Z and does not infer a time zone from a date alone. The example interval runs from nine in the morning to five in the afternoon UTC on October 26, 2026. These are fictional timestamps, not the working hours of an actual team or a recommendation about when people should work.

Follow the invented eight-item example

Three fictional items, W1, W2 and W3, have started before the opening snapshot and remain open at that point. During the interval, five more items, W4 through W8, start. Four items finish: W1, W2, W4 and W5. W3 is canceled. The closing open set is therefore W6, W7 and W8. The identifiers are invented practice labels and contain no customer or employee information.

The count reconciliation is opening WIP of three, plus five starts, minus four finishes, minus one cancellation, leaving closing WIP of three. Looking only at the two snapshots would show no numerical change in WIP. Looking at the events reveals that four items finished and the composition of the open set changed completely. Both observations can be true without a contradiction.

The example keeps canceled work separate from finished work. A canceled item leaves the open set under this model but is not counted as a completed deliverable. A report that combines finishes and cancellations would answer a different question. If the actual process handles cancellation differently, state its rule explicitly rather than assuming this teaching convention applies to every workflow.

Do not infer throughput from a WIP difference

The difference between opening and closing WIP is zero in the invented example, but four items finished during the interval. Subtracting the snapshots would therefore fail to recover the finish count. To understand the movement, the reviewer needs starts and other exits as well. A static screenshot cannot necessarily provide those events, even when it displays the current open items accurately.

The example's throughput count is four finished items over the stated interval. Dividing four by the eight-hour interval gives a descriptive rate of one-half item per hour for that sample. It does not predict how many items the team can finish tomorrow, establish a service promise or compare the effort required by those items. The interval and item definition belong beside any rate.

Avoid treating a count of items as a measure of their size or value. Four small routine tasks and four complex projects may have very different implications. The teaching model deliberately counts items rather than estimating effort or revenue. A real management review needs the context relevant to its question instead of interpreting a larger count as automatic evidence of better work.

Separate waiting from unstarted work

An item can be inside the defined workflow while waiting for a review or another dependency. If it has started and has not reached the stated finish or other exit, it remains open in this example. The event model does not claim that someone is actively working on it every minute. WIP is not equivalent to hands-on working time.

This distinction matters when reading a board with columns such as waiting, review or blocked. Moving an item to a different internal column does not necessarily change whether it belongs inside the start-to-finish boundary. Do not remove waiting items from the count merely to make the open total smaller unless the actual definition calls for that treatment and the comparison is labeled accordingly.

If the question concerns active effort or waiting duration, obtain the relevant evidence separately. The supplied utility does not record intermediate states or calculate time spent working. It cannot establish that a delay was avoidable or identify who caused it. Keep those questions distinct from the simple reconciliation the file can support.

Keep item identity consistent

Use a stable identifier for each item so that a start can be connected with its finish or cancellation. A title can change during the work, and several items may share similar wording. The teaching file uses W1 through W8 because the distinction is easy to inspect. A real organization should use its appropriate records and access controls rather than copying unnecessary customer details into a public worksheet.

Do not count a renamed item as a new start without understanding the source system. Likewise, splitting one item into several may change the counting unit and require a clear explanation. This utility does not model splits, merges or reopenings. Those are limits of the exercise, not instructions to suppress real events that make the arithmetic more complicated.

When a process needs a richer model, define it before comparing totals. An item reopened after finish may require another state or event rule. A partially completed item may need a different treatment from a finished deliverable. The appropriate model depends on the actual question. A simple program should report that it cannot represent a case rather than silently convert it into an unsupported count.

Inspect the event sequence before trusting the summary

The utility checks that an item starts before it finishes or is canceled, and that the same item does not start twice under this model. Those restrictions help reveal inconsistent practice records. They do not prove that a real source system captured every event correctly. A valid sequence can still omit an event that was never recorded.

An apparent finish without a start might reflect a truncated export rather than impossible work. If the opening history is incomplete, the model needs an appropriate starting-state record or a broader source extract. Do not invent a start time to satisfy the program. Clarify the source boundary and use a representation that honestly describes what is known about the opening state.

Keep the original event data available through the appropriate process. A corrected export should be identifiable as a new version, with the relevant reason for the correction. The summary alone cannot explain why a count changed. A reviewer needs to distinguish a genuine workflow event from a data correction, a definition change or a revised interval.

Read the opening and closing sets as well as their counts

Two snapshots with three open items each do not necessarily contain the same work. The utility returns the item identifiers in the opening and closing sets so that the reader can inspect the difference. In the fictional example, W1, W2 and W3 leave, while W6, W7 and W8 remain open at the end. The unchanged total conceals that movement if only the count is shown.

The sets also help identify a mismatch between the calculated state and a separate snapshot. If the board at the closing instant contains a different item, investigate the specific reference and event history. Do not fix the disagreement by adding a generic adjustment row without understanding it. A reconciling total is more useful when the item membership can also be explained.

Avoid drawing a conclusion about aging from the count alone. An open set containing long-standing items may raise different questions from one containing newly started work, even at the same size. This utility does not calculate item age or cycle time. Those measures require the relevant definitions and source times, and their interpretation should not be inferred from a WIP number that lacks that detail.

Use cancellation as a visible explanation

The fictional cancellation explains one exit without claiming another completed item. Removing that distinction would report five departures from the open set and could be mistaken for five finished deliverables. Keep the cancellation count and item reference visible when the question concerns what was actually delivered. The reader should not need to infer the difference from a footnote hidden beneath a dashboard.

A cancellation can have many causes, and the event record alone does not establish one. The utility does not judge whether the cancellation was appropriate or whether it represents waste, a changed request or an administrative correction. If the management discussion needs that explanation, obtain the relevant context from the responsible source rather than attaching an assumed cause to the event label.

The same caution applies to a finish. A terminal event in the file means finished under the stated model. It does not certify quality, customer acceptance or a commercial outcome unless those conditions are part of the actual definition and supported by records. Preserve the distinction between the operational event being counted and any broader claim someone wants to make from it.

Run the local practice utility

The downloadable Python script reads the fictional CSV, validates the event sequence and reports the opening set, interval starts, finishes, cancellations and closing set for explicit UTC boundaries. It makes no network calls and does not connect to a task board. The expected JSON shows the checked result for the supplied example, including the count reconciliation and the three closing identifiers.

Run the script with the fictional file and the stated start and end timestamps. Compare the output with the expected result before adapting any input. The utility is deliberately limited to start, finish and cancel events with one start and one terminal exit per item. An unsupported event should be handled as a model limitation rather than renamed to a familiar event merely to make the file run.

The output does not write changes to a project system or recommend an operating action. It is a calculation aid for understanding the example. If an actual workflow requires another event type or a different boundary convention, the specification and review need to change before the tool is used as evidence about that process.

Frame a management question from the result

Begin with a supported observation: the fictional open count is three at both boundaries, four items finish and one is canceled during the interval. Then ask which additional information matters for the actual decision. A question about delivery predictability requires more than this one sample. A question about a particular open item may require its history and source context rather than an aggregate rate.

Keep proposed process changes separate from the measurement. A team might choose to examine a constraint or clarify its finish definition, but the event arithmetic does not prescribe a specific intervention. The separate bounded-process-trial guide addresses how an organization might frame a change for review. Do not claim that reducing the example's WIP will automatically improve throughput or that one interval establishes a causal relationship.

The useful outcome is a clearer account of what the numbers mean and what remains unknown. A small reconciled example can help people distinguish a stock from a flow without pretending to describe every feature of a working organization. Preserve the definitions, interval and source version whenever the summary is shared beyond the person who ran the calculation.

Check events exactly on a boundary

Under this exercise's convention, a start event at exactly nine in the morning belongs in the opening state and is not another interval start. A finish at exactly five in the afternoon belongs in the interval and affects the closing state. A finish one second later is outside that closing snapshot. These choices make the arithmetic reproducible, but they must remain attached to the result rather than being assumed from the calendar labels alone.

If a report counts the start boundary in both the opening state and the interval starts, it can double-count an item in the reconciliation. The total may look plausible until the reviewer traces the specific event. A boundary test with one invented item is useful for checking the implementation before interpreting a larger file. The test should establish the intended convention rather than selecting whichever rule produces a preferred management result.

The program processes a full ordered event history through the end boundary. It does not assume that the first row represents an opening balance. That matters when a file begins after work has already started. If the actual source is only a partial export, use a representation that supplies the missing state appropriately; do not claim the teaching program reconstructed events it never received.

Explain a definition change before comparing periods

If a team changes finished from draft prepared to reviewed and accepted, later finish counts describe another boundary. A decline in the reported count may reflect that change rather than a deterioration in performance. Preserve the definition and its effective context when comparing results. This guide does not choose which finish definition is right for a particular organization.

Likewise, changing the size of a work item can affect counts without changing the underlying amount of work. A formerly single item split into several tracked items should not automatically be described as increased productivity. Keep the measurement unit consistent where the comparison requires it, or explain the difference and limit the conclusion. An honest definition note is more useful than a trend line whose counting basis changed invisibly.

Keep the raw event file with the reported interval so another reader can reproduce the result. A screenshot of the closing total alone cannot show which items started, finished or were canceled. Record the file version and the agreed event definitions alongside the calculation rather than treating the chart title as sufficient documentation.

Frequently asked questions

Can WIP stay the same while several items finish?

Yes. In the fictional example, three items are open at both boundaries, while five start, four finish and one is canceled during the interval. The events reconcile to the unchanged count. The snapshots alone do not reveal throughput or the changing membership of the open set. Keep starts and other exits visible when explaining the movement.

Is a cancellation a finished deliverable?

Not under this example's rule. It removes an item from the open set but is reported separately from finishes. An actual workflow may need another definition, which should be stated explicitly. Do not combine all departures from WIP and label them completed work without checking what each event represents and what the report is intended to describe.

Does a WIP count measure active working time?

No. An item can remain within the defined workflow while waiting or blocked. This utility counts items and their start or terminal events; it does not measure hands-on effort. If the question concerns waiting time, active effort, age or cycle time, use the relevant definitions and records rather than inferring those quantities from the open-item count.

Can the sample rate predict tomorrow's output?

The article makes no such prediction. Four finishes over the invented eight-hour interval describe that sample only. Item size, workflow conditions and other context are not represented as a forecasting model. Keep the period and count definition with the result and obtain evidence appropriate to any actual delivery or staffing decision.

Does the script update a task board?

No. It reads a supplied local CSV and prints a calculation. It makes no network calls, writes no project records and takes no operational action. The fictional file contains invented identifiers, not client work. Use the actual authorized process for any changes to a live workflow or its reporting definitions.

What if my process allows reopenings or split items?

The supplied model does not represent those cases. Define the needed events and counting rules before using a different implementation to analyze them. Do not disguise a reopening as a new unrelated item merely to satisfy the teaching program. The tool should remain honest about its limits rather than producing a neat total from an inappropriate representation.