Too busy to read?

I cannot tell you how many teams I have watched waste so much time, grooming, pruning, and re-prioritizing their backlogs. The truth is that the effort spent to maintain a backlog is waste. It is waste because the truth is that much of what goes into a backlog will never get worked on anyway. Why spend time prioritizing items that you have no clue nor confidence if or when they will ever get worked?

Part of the Agile Manifesto mentions "Customer Collaboration". I fully support that notion that our work should involve close collaboration with the customer. However, to me, collaboration means speaking the language of the customer. And that language should extend to cover all the metrics and analytics that we use. Have you ever had to explain what a Story Point is to a customer? How about Velocity? If you do not like yourself very much, march into your CFO's office someday and try to explain what a Story Point is. However, I guarantee all of your stakeholders understand the concept of elapsed time. I guarantee they understand the concept of the total number of features to be delivered in a release. If we truly want to be Agile, we are going to have to adopt the language of our customers. To that end, we must choose words and concepts that they are comfortable with--not force them to learn a new, arbitrary, and unhelpful vocabulary.

Queues form when work items that have been started just get stuck somewhere in your process (without completing). Items may get stuck because: - There are no more resources available to continue working on them. - Some manager mandates that more new work be started before current work has finished. - Resources that are actually doing the work are constantly pulled in multiple different directions and are not allowed to focus on any one thing. - There is a dependency on some external team or vendor.

The customer question "How long to complete?" is best answered by the flow metric known as Cycle Time. The customer question "How many new features am I going to get in the next release?" is a question best answered by the flow metric known as Throughput. The last of the three, Work In Progress (WIP), does not directly answer any particular customer question, but it is the metric that will most greatly influence the other two.

"spike" I mean a work item--user story--that is used to drive out risk and uncertainty in another work item).

Flow Efficiency is the ratio of the total elapsed time that an item was actively worked on to the total elapsed time that it took for an item to complete (its total Cycle Time).

The direct consequence of elongated Cycle Times is a decrease in Throughput. Throughput is the metric that represents how much work completes per unit of time. A decrease in Throughput therefore means that less work is getting done. The less work that gets done, the less value we deliver.

If work flows only part way through the system and gets kicked out or discarded--for whatever reason--then any effort that was expended on the eliminated item immediately becomes waste.

A further thing to know about Throughput, however, is that this metric as I have defined it here is very different from the Scrum metric of "Velocity". Velocity, as you may know, is measured in terms of Story Points per sprint or iteration. You have to remember, though, that for Throughput I am talking about actual counts of work items (e.g., actual number of discrete stories and not Story Points) per unit of time. As I have just mentioned, the unit of time you choose for Throughput is completely up to you.

Earlier when I first introduced Equation (1) I had stated that there was really only one assumption that needed to be in place for it to work. Well, in the interest of completeness, technically there were three. For Equation (1) we need: A steady state (i.e., that the underlying stochastic processes are stationary) An arbitrarily long period of time under observation (to guarantee the stationarity of the underlying stochastic processes) That the calculation be performed using consistent units (e.g., if wait time is stated in days, then Arrival Rate must also be stated in terms of days).

Average is a meaningless statistic unless you know something about the underlying distribution of the data from which the average was calculated. Specifically, when we are ignorant of the distribution, then we do not know what percentile we are talking about when we say the word "average".

"If a metric does not offer predictive power, then capturing that metric is waste."

The reason most companies do not know about an item's business value upfront is because that value--in most cases--is impossible to predict. As value is only determined by our customers, an item's true value can only be known once put in the hands of the customer.

A forecast is a calculation about the future completion of an item or items that includes both a date range and a probability.

WIP: All discrete units of customer value that have entered a given process but have not exited.

Average Cycle Time = Average Work In Progress / Average Throughput If you have ever seen Little's Law before, you have probably seen it in the form of the above equation. What few Agile practitioners realize, however, is that Little's Law was originally stated in a slightly different form: Average Items In Queue = Average Arrival Rate * Average Wait Time

The actionable intervention suggested by a CFD that looks like Figure 5.5 is that we must get arrivals to match departures.

there are five assumptions necessary for Little's Law to work, they are: The average input or Arrival Rate (l) should equal the average Throughput (Departure Rate). All work that is started will eventually be completed and exit the system. The amount of WIP should be roughly the same at the beginning and at the end of the time interval chosen for the calculation. The average age of the WIP is neither increasing nor decreasing. Cycle Time, WIP, and Throughput must all be measured using consistent units.

Flow metrics are defined in the language of the customer and are the proper metrics to track in order to be lean and agile. Flow metrics will suggest the actionable interventions needed to make us more predictable.

The upshot of Little's Law is that, in general, the more things that you work on at any given time (on average) the longer it is going to take for each of those things to finish (on average).

the variability in work item size is probably not the variability that is killing your predictability. Your bigger predictability problems are usually too much WIP, the frequency with which you violate Little's Law's assumptions, etc. Generally those are easier problems to fix than trying to arbitrarily make all work items the same size. Even if you were in a context where size did matter, it would be more about right-sizing your work and not same-sizing your work

notice the emphasis on "elapsed time". The use of elapsed time is probably very different from the guidance you have previously been given. Most other methodologies ask you to measure only the actual amount of time spent actively working on a given item (if they ask you to measure time at all). I happen to think this guidance is wrong. I have a couple of reasons why. First, and most importantly, your customers probably think about the world in terms of elapsed time. For example, let's say that on March 1, you communicate to your customers that something will be done in 30 days. My guess would be that your customer's expectation would be that they would get their item on or before March 31. However, if you meant 30 "business days" then your expectation is the customer would get something sometime around the middle of April. I am sure you can see where that difference in expectations might be a problem. Second, if you only measure active time, you are ignoring a large part of your predictability problem. It is the time that an item spends waiting or delayed (i.e., not actively being worked) that is usually where most of your unpredictability lies. It is precisely that area that we are going to look at for most substantial predictability improvements.

Do not use Little's Law for forecasting. Do not use averages for forecasting. Straight line projections are problematic because they are based on averages and because they do not communicate a probability of success.

The arrivals column acts as the throttle by which we constrain the amount of work that can arrive to our system at any given time. It is the mechanism by which we match the rate of arrivals in our process to the rate of departures. The matching of these rates is what is going to yield process predictability. And, The arrivals column acts as our "commitment" point to start new work. The implication being that when new work is committed to, we expect it will flow completely through the process and depart the system. It is only when work departs our system that customer value can truly be recognized and our predictability be assessed.

Little's Law is a relationship of averages.

A focus on flow necessitates not only a shift in thinking (away from capacity utilization and estimation and planning) but also a shift in the quantities used to evaluate process performance (away from ideal hours, level of effort, points, velocity, etc.)

I hate to belabor this point, but any CFD with a projection on it is not a CFD. It is a Burn Up chart or Projection Chart or something else, but it is most definitely not a CFD. To review, there are two reasons why a projections on CFDs are incorrect. The first reason is because to do a projection the chart must have some type of backlog displayed. But CFDs should not have backlogs on them. That is mistake number one. The second reason is that CFDs are for looking backward, they are not for making projections about the future. That is mistake number two. The fact that it is not a CFD is not a bad thing because this projection view can potentially be very useful (used incorrectly it can also be very bad). I should point out here that because I cannot call them CFDs, the term I am going to use for these types of charts is going to be either Burn Up Charts or Projection Charts.

Flow and the Basic Metrics of Flow Simply stated, flow is the movement and delivery of customer value through a process. In knowledge work, our whole reason for existence is to deliver value to the customer. Therefore, it stands to reason that our whole process should be oriented around optimizing flow.

Flow Debt is when Cycle Time is artificially reduced for some work items in progress by "borrowing" Cycle Time from other work items in progress. Some examples of scenarios that lead to the creation of Flow Debt are: Classes of Service Blockers Other order of pull policies in place (whether they are explicit or not)

Flat Lines Another pattern that I look for on a CFD is whenever any lines that flatten out over long periods of time (remember that lines can never go down!). Figure 6.2 shows an example of this: Figure 6.2: Flat Throughput Sections on a CFD Depending on your perspective, these lines could represent either periods of zero arrivals or periods of zero departures. Usually you will be concerned about these flat lines as periods of zero departures. The reason why is because zero departures means nothing is getting done. In other words, no value is being delivered to the customer (or to a downstream step).

Stair Steps A batch transfer in your process will manifest itself as "stair steps" on your CFD.

Mismatched Arrivals and Departures Let's say we had a CFD that looked like: Figure 6.1: Mismatched Arrivals and Departures In this picture the slope of the top-most line is steeper than the slope of the bottom-most line. This is a classic pattern that develops whenever items arrive to our process faster than they depart.

Key Learnings and Takeaways On your CFD, does arrival rate match departure rate? Are there any bulges in the workflow step bands? Do any bands disappear? Are there any long periods of flat lines? Are there stair steps? Is there an S-curve? Think about improvements to consider if everything looks good on your CFD.