Use Kanban for software delivery by defining where work starts and finishes, controlling unfinished work and reviewing the evidence of flow. Begin with an agreed workflow, then choose a board or tool that makes those rules visible. Columns and colourful cards are useful only when the team can explain the decisions they support.
Where does a work item start and finish?
The Kanban Guide requires a Definition of Workflow with explicit started and finished points. The Kanban Guide makes those boundaries part of the shared workflow rather than leaving them to each person’s interpretation.
Choose a recognisable unit of work. For a hypothetical enquiry application, a work item might deliver the agreed behaviour for an incomplete enquiry. Write down what must be true before the team starts it and what evidence permits it to be treated as finished.
Ask whether review, testing and the relevant handover are inside that boundary. There is no useful comparison between two cycle-time reports if one stops at coding complete and the other includes acceptance. Preserve the definition used when collecting the evidence.
Record the states that matter to the actual work. “Awaiting a business decision” and “under review” may need different owners even if they occupy the same visual column. Choose labels that help someone take the next action, not a long list of states maintained solely to make reporting look detailed.
How should the team choose a work limit?
The guide requires explicit control of the number of started but unfinished work items. Decide how the control will operate across the agreed workflow, using the team’s actual constraints and responsibilities. Do not copy an unexplained number from another project’s board.
Ask what signal permits a new item to start. If review is the current bottleneck in the hypothetical enquiry project, the team should discuss how it handles work already waiting there before opening another unrelated task. The decision needs an owner and a visible policy.
The guide asks teams to make accepted exceptions to WIP control explicit. Define the route for a genuinely urgent interruption: who can approve it, what existing work is affected and how the exception remains visible. Avoid silently bypassing the limit and then interpreting the report as if the normal policy had applied throughout.
Use a controlled planning exercise with synthetic cards before changing the live workflow. Introduce an item waiting on an external decision and ask how the proposed policy treats it. Record whether the item remains within the chosen start-to-finish boundary and who is responsible for removing the block.
Which flow measures answer different questions?
The Kanban Guide defines WIP as the number of items started but not finished. It answers a question about unfinished work under the defined boundary. Ask whether every counted item has actually started and whether supposedly finished items meet the team’s agreed definition.
It defines throughput as the number of items finished per unit of time. Use a clearly named interval and keep the item-counting rule consistent. If the team splits work differently, record that change before comparing totals across periods.
The guide defines work-item age as elapsed time from start to the current date. Review an ageing unfinished item by asking what it needs now: information, a decision, a review or another action. Age should help identify work to investigate rather than assign blame to the person named on a card.
The guide defines cycle time as elapsed time from an item’s start to its finish. Keep the underlying start and finish evidence available. A report is easier to interpret when someone can trace a point back to its work item and understand any reopening or correction.
How should a service-level expectation be communicated?
The guide says a service-level expectation has both an elapsed-time period and an associated probability. Ask which historical data or provisional assumption supports the expectation and which Definition of Workflow it uses. Communicate the uncertainty alongside the period rather than turning a forecast into an unconditional delivery date.
For the fictional enquiry project, propose examining completed items with the same boundary before selecting an expectation. If the team lacks suitable history, label the initial assumption and define how it will be revisited. Do not publish the guide’s example probability or duration as though it were a measured result for your project.
Keep the expectation connected to active work. When an item ages beyond what the team expected, ask what investigation or decision follows. A number that appears only in a monthly report will not by itself explain why today’s work is waiting.
What should the flow review record?
Use this original flow-evidence review card. It joins each measure to a concrete question and a decision that can change how work proceeds.
| Evidence | Question to ask | Decision to retain |
|---|---|---|
| Started and finished definitions | Are the boundaries understood and applied? | Confirm or revise the explicit workflow |
| Current WIP | Which work is unfinished and why? | Finish, unblock or defer starting another item |
| Work-item age | What does this item need next? | Named action and responsible person |
| Completed cycle times | Which cases differ materially from the rest? | Investigate the relevant workflow conditions |
| Throughput interval | Are the items and time window comparable? | Keep the comparison or explain its limits |
| WIP exception | What interruption was authorised? | Record displaced work and the reason |
| Service expectation | What supports this forecast? | Retain, revise or gather better evidence |
The Agile Manifesto principles call working software the primary measure of progress. The Agile Manifesto principles offer a useful reminder to connect the flow discussion with what the software lets the intended user accomplish.
For the enquiry example, a finished card should lead the reviewer to the agreed incomplete-enquiry behaviour and its acceptance evidence. A high completed-item count is not a substitute for that task outcome. Ask what the customer or operator can now do that they could not do before.
The Agile principles call for teams to reflect regularly and adjust their behaviour. Close the review with one specific improvement and the evidence needed to assess it. Preserve the earlier policy and its result so the team can explain what changed, rather than rewriting history to make the latest arrangement appear inevitable.
When comparing board software, request a demonstration of how the chosen start, finish and blocked-work policies are represented. Ask how a reviewer retrieves the underlying event evidence and corrects a mistaken transition. Keep any unsupported reporting requirement visible in the selection decision.
For delivery roles and events, use the separate Scrum guide. Explore web development, or discuss your requirements with Spout using the Definition of Workflow and flow-evidence review card.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.