Project delivery
Flow board with work in progress limits
Each state split into doing and done so a handoff queue is visible, with a limit per state, the current count against it, and average days in state calculated from throughput.
What it is
Flow based delivery controls work by limiting how much is started rather than by fixing what fits into a cycle. That suits work arriving unpredictably, where a two week commitment made on Monday is invalidated by Tuesday's incident.
The practice that does the work is the limit, and it is the one teams remove first when it becomes uncomfortable. The discomfort is the point. Somebody blocked from starting new work is expected to help finish existing work, and total throughput rises because items stop queueing even though each individual appears less busy.
Splitting each state into doing and done is what makes a handoff queue visible. Ten items being worked on is capacity in use and ten items finished and waiting is a handoff problem, and on a board without the split the two look identical.
When to use it
- Requesters say everything takes six weeks and the team says it is working flat out.
- Work arrives unpredictably and cycle commitments are missed most cycles.
- A team has thirty things started and very little finished.
- Urgent requests are arriving through side channels because there is no route for them.
The columns
- State
- Days accumulated
- Items completed
- Average days in state
- WIP limit
- Current WIP
- Policy for leaving this state
The template
| State | Days accumulated | Items completed | Average days in state | WIP limit | Current WIP | Policy for leaving this state |
|---|---|---|---|---|---|---|
| Ready | 340 | 62 | 5.5 | 8 | 6 | Item is described, sized and has acceptance criteria |
| Analysis, doing | 118 | 62 | 1.9 | 3 | 2 | Approach agreed and dependencies identified |
| Analysis, done | 96 | 62 | 1.5 | 3 | 3 | Waiting only. Counts against the analysis limit |
| Build, doing | 372 | 62 | 6.0 | 5 | 5 | Code complete, unit tested, merged |
| Build, done | 149 | 62 | 2.4 | 5 | 4 | Waiting only. Counts against the build limit |
| Test, doing | 236 | 62 | 3.8 | 4 | 9 | All acceptance criteria verified in the test environment |
| Test, done | 310 | 62 | 5.0 | 4 | 5 | Waiting only. Counts against the test limit |
| Released | 0 | 62 | 0.0 | 62 | In production and observable |
Average days in state is a formula dividing days accumulated by items completed. Test is over its limit at 9 against 4 and holds the largest waiting time at 5 days, which is the bottleneck stated twice.
Splitting doing and done
The split columns are what make a handoff queue visible. Ten items being worked on is capacity in use. Ten items finished and waiting for the next stage is a handoff problem, and on a board without the split the two look identical.
The done half counts against the same limit as its doing half. Otherwise work piles up in the waiting column and the limit reports nothing, which is the most common way a board stops being a control.
Why limiting work in progress speeds things up
Average cycle time equals average work in progress divided by average throughput. It is arithmetic rather than philosophy.
| Work in progress | Throughput | Average cycle time |
|---|---|---|
| 10 items | 5 per week | 2 weeks |
| 20 items | 5 per week | 4 weeks |
| 30 items | 5 per week | 6 weeks |
The right hand column is what a requester experiences. The middle column is what the organisation receives. Starting more work moves the first and leaves the second alone, which is the trap, because starting work feels like progress and registers as responsiveness.
Setting the limits
Start from roughly the number of people who can work on that state at once, then reduce until it becomes uncomfortable. Discomfort is the signal working. Somebody blocked from starting new work is expected to help finish existing work, and that is the behaviour the limit exists to produce.
A limit that is never reached is set too high to do anything. A limit breached continuously is reporting a constraint rather than being wrong, and the response is to address why that state cannot keep pace. Raising the number to match the queue removes the instrument, since a limit set to whatever is currently happening can never be exceeded.
Classes of service
Not everything deserves the same treatment, and pretending otherwise pushes urgent work through informal channels. Add a class column and an explicit policy for each.
- Expedite. Jumps the queue. Only one in the system at a time.
- Fixed date. Has an external deadline. Started early enough to be finished by it.
- Standard. Taken in order.
- Intangible. No immediate return and real long term cost, such as reducing technical debt. Given a standing share of capacity rather than competing item by item.
Without a named expedite class, urgency is expressed by asking loudly and the loudest requester sets the order.
The measures worth watching
Cycle time is how long an item takes from work starting to done. Lead time is from the request arriving to delivery, including the wait before anybody started, and it is what the requester actually experiences. Throughput is items finished per week, and it needs no sizing scheme.
Forecast from the distribution rather than the average. If eighty five per cent of items over the last quarter finished within twelve days, twelve days is what to tell a requester, with the fifteen per cent stated honestly. That is a stronger commitment than an estimate made by looking at the item, because it is built from what happened.
Making the states honest
A column is a state work actually passes through, including the waiting states nobody would design deliberately. Ready for review, waiting for test environment and awaiting sign off are the columns that teach, because they are where time is spent and no work is happening.
Resist tidying those away. A board that shows only the states somebody would put in a process diagram will show a team that looks efficient and a requester who waits six weeks.
Questions people ask
- Why does limiting work in progress make things faster?
- Average cycle time equals work in progress divided by throughput. Thirty items in progress at five finished a week is a six week wait. Ten items at the same throughput is two weeks, and nobody has changed how hard they work.
- Our limit is always exceeded. Should we raise it?
- No, that removes the instrument. A breached limit is reporting a constraint, and the response is to address why that state cannot keep pace. A limit set to whatever is currently happening can never be exceeded and reports nothing.
- Can this be used alongside a cadence?
- Yes, and many teams do. Keep the planning and review rhythm and manage the work inside the cycle by flow. The two control the same thing by different means.