Flow efficiency is one of the most important, startling and difficult to measure flow metrics. Flow efficiency describes the ratio of time spent on doing real, transactional work—the touch time—to the total calendar time needed to deliver output to a customer—the cycle time—expressed as a percentage.
If it takes a team 10 days to perform all the required work on a work item, but during those 10 days it was really working on the item only a total of 1 day, then its flow efficiency for that work item was (Touch time) / (Cycle time) * 100%, or 10%.
When team members are first presented with the idea of flow efficiency, something often clicks in their minds. It helps describe the phenomenon of taking months to deliver something when they had worked so little on the item. It brings to mind those endless delays, those fruitless meetings, the long periods of waiting for someone else to make a decision, return from holiday, get well again and so forth.
The problem of measuring flow efficiency
If we find flow efficiency so useful a metric, why don’t teams measure it and use to regularly to document improvements and to encourage yet further improvements? Rightly done, flow efficiency can be very difficult to measure.
The easy part of measuring flow efficiency is the measuring of cycle time.1 A team may easily take note of when it starts work on an item and when it has completed that work. It may find it hard to measure when it works on the item—the touch time. Two reasons explain this. First, the stakeholders might disagree or misunderstand what constitutes that real work. Second, the administrative effort to note the starting and stopping of that work may be difficult to perform consistently and accurately. In short, many workers might not bother doing it, or they might record some fictive and imaginative values long after the fact. Completing weekly timesheets poses the same problem.
As a result, manual measurement of flow efficiency might be too time consuming and unreliable to perform without intensive supervision. This additional cost and overhead translates into rare and difficult to compare measurements.
What is the "real work" part of flow efficiency?
Different teams might have different concepts of what work duration ought to be measured. Cycle time might be divided into three categories: the time during which no one is working on the item; the time during which someone is performing the work that directly leads to completing the work item; and the time spent on coordinating and communicating the real work.
What is the "real cycle time" part of flow efficiency?
Some people might distinguish between poor quality work that leads to defects and must be repeated, on the one hand, and adequate quality work. As important as this distinction might be, I do not believe it reflects on the maturity of flow management and should not enter into the calculation of working time. Instead, worker ineffectiveness or inefficiency leads to longer cycle times. This explains why I emphasize the importance of measuring the end of cycle time as the time the work item is completed with the right quality. If you take 1 week to complete a work item, only to learn a week later that the quality is insufficient and then you take another week to fix the defects, the real cycle time is three weeks, not one week.
A more effective way of measuring work
If you are using a physical card board to visualize and track work, it might be very difficult to track the start and end of every period of real work on every work item. I suppose you could do it by writing on the backs of the cards. However, using a virtual card board with the necessary features offers a simpler method requiring much less administrative effort.
Remember that teams, especially those performing knowledge work, tend toward very low flow efficiency. When a team does not actively manage flow, analysts report the typical flow efficiency at around 5% to 15%.2 But even when a team has reached a good level of maturity in flow management the efficiency can still be under 50%. Consequently, the most common state of a work item is “not being worked on”, i.e., “not being touched”.
When you first create a work item, its state should thus be “not being worked on”. There are two ways to reflect this state:
- the work item is in a queue
- the work item is not in a queue, but is flagged as temporarily not advancing.
- the workers have switched context (started to work on something else without having finished the current value stream phase). They could do this voluntarily or an external party could impose the switch, such as when a manager wishes to expedite a work item
- the work is blocked, generally because the team must wait for a third party.
The first reason is under the control of the team (a team might refuse to expedite an item, for example), while the second is largely not under the control of the team.
Low overhead steps for tracking working time
The following steps, illustrated with videos from a kanban software tool, show how a team may calculate accurately its flow efficiency with a minimum of administrative overhead.
Step 1:
The team pulls a work item into a new value stream phase only when it intends to start work on it immediately. The state of that work item is set to “working on it”, “being touched”.
In the example below, a worker pulls a card from the Requested column into the Analyze column. The worker makes no special changes to the card attributes. The cycle time starts at this moment. The touch time starts to accumulate.
Step 2:
As soon as the team finishes its current session of work on the item, it sets the state to “not working on it”. As per the discussion above, the tool might include various flags to distinguish the reasons for stopping work: voluntarily switched context; switched context due to expedited work; waiting for a third party; etc.
In the example below, a worker flags a card to indicate that the touch time has ended and the team no longer advances in its work on the item. The changed card color indicates the new state. The touch time stops accumulating.
Step 3:
The next time the team starts work on the item, it resets the state to “working on it”. The touch time starts accumulating again.
Step 4:
If the team finishes work on the current value stream phase, either it moves the item into a queue or, if explicit queues are not used, a worker resets the attribute to “not working on it”. Otherwise, return to step §2.
In the example below, a worker pulls the card into the “Analysis completed” column, a queue. While in the queue, the touch time accumulation ceases.
Step 5:
As soon as the the team completes entire value stream for the work item, a worker drags the corresponding card into the “Done” column. The cycle time comes to an end and the touch time stops accumulating.
At this point, the kanban software may include the work item in its calculation of flow efficiency. The software sums all the periods during which the item was either in a queue or flagged as not being worked on to calculate the touch time.
Detecting and correcting errors
The team can easily detect unfeasibly long periods of work when data is collected this way. For example, if workers only work done during single, daytime shifts, the team should investigate and fix durations of working periods greater than, say, 12 hours (or any duration it wants). Automated alerts in the software can help detect such cases.
If a user attempts setting the state to “not working on it” when the item is already in that state, it is likely that the start of the session was not recorded. The software should indicate this missing datum and allow the user to set a feasible start time.
Finally, if the card lacks both the start and end times of a session, this omission could be detected, but only if workers also tracked their coordination and communication activities. In that case, there would be periods for which the touch/wait state of the work item is not being accounted.
Calculating the flow efficiency
The calculation of the cycle time should be straight forward. In case a work item had been marked as completed and then returned to an active phase of the value stream, the software should replace the initially recorded end time by the subsequent end time.
The software should calculate the touch time as the cycle time minus the time spent in queues during the cycle time, minus the time flagged as “not working on it”. In case the team reactivates the work item after it having been moved to a “done” phase, all the time in that “done” phase should be considered as if it were a queue.
The article Measuring Flow Efficiency by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Notes
Credits
Unless otherwise indicated here, the visualizations are the work of the author.
