Start and end points for flow metrics

If we want to be tracking flow metrics, we need clearly defined start and stop points. When we’re talking at a team level, these are often described as Definition of Ready (DoR) for the start point and Definition of Done (DoD) for the stop point.

The four flow metrics that we typically start with are Throughput, Cycle Time, WIP, and Work Item Aging, and all of them are measured relative to the start and stop points. Without clarity on those two points, none of the metrics will be helpful.

Flow metrics

So where do we really want to measure those?

At a high level, there are two parts to the start point (Ready). Someone representing the business has agreed to spend money on this work, and the team understands what they’re being asked to do. It’s worth noting that the team does not need to understand how they’re going to do the work yet. Figuring out the how is part of doing the work and happens after the clock has started.

Our stop point is similarly simple, we aren’t coming back to this work. What does that mean? If it hasn’t been tested yet then it’s highly likely that we are coming back to it because we don’t know if it works yet. We stop the clock when we have a reasonable expectation that we are not coming back to this work.

Each team will likely have more specifics that they want to capture, to provide a checklist of the things required for each of those two points. Perhaps the code must be checked in, reviewed, and merged before we can say we’re doing. All of this is towards satisfying the high level point of we aren’t coming back to this.

A common mistake made with both of these points is that individuals think that the points are measuring them personally, when in fact the measurements are about the work. We don’t care that a developer finished coding, the work isn’t done until other people have done their work as well.

This also holds true for the start point. I’ve seen lots of teams count the work as started when a developer starts coding, yet the work usually started well before that. Has the team not already had discussions about this work during a refinement/planning meeting? The moment we committed to doing the work is when it started, not the time we touched some code.

Many people want to defer the start point as long as possible to make the numbers look good. What we really want to do is make the reality visible so that we can start improving it. If we held a refinement meeting a month ago and brought the work to ready at that time, then the work has been started for a month, whether or not a developer has touched it since.

We don’t like that because it makes the numbers look bad, but instead we should be happy that we’ve just identified problems in the workflow. Why did we refine the work so early? All we did is build up an inventory of tickets that we aren’t working on, and inventory is one of the classic wastes in Lean.

If the work has been fully refined, the clock should have started. If we’re not coming back to it, the clock should have stopped.

Always remember that we’re not collecting metrics for the sake of being busy. We’re doing it in order to make better data-informed decisions. Better decisions require a better understanding of the system, and that needs accurate measurements.