Amongst other things you start new work at a faster rate than you finish old work, you work on too many items at the same time, you ignore systemic dependencies and impediments, and you expedite requests that do not need to be expedited. You, in effect, initiate a denial of service attack on yourself, and then wonder why it takes so long for things to get things done. (Location 35)

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. (Location 130)

Tags: flow

Note: .flow

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. (Location 135)

Tags: queue, flow

Note: .flow .queue queues are formed by dependencies, new work starting before existing work is finished, resources being pulled in multiple directions

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. (Location 153)

Tags: kanban, through put

Note: Throughput measures how much work is completed per unit of time

Actionable Metrics for Predictability: The set of metrics that will suggest specific interventions that will result in the outcomes you are expecting. (Location 160)

“If a metric does not offer predictive power, then capturing that metric is waste.” (Location 167)

Tags: metrics, measure

Note: the best metrics help predict

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. (Location 188)

Tags: language, story points, kanban, flow

Note: .flow .kanban use the language of your stakeholders. Story points are confusing for them

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.) (Location 205)

Tags: metrics, flow

Note: .flow

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. (Location 219)

Tags: flow

Note: .flow define metrics in the language of the customer

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. (Location 226)

Tags: metrics, flow

Note: .flow .metrics cycle time answers the question "how long", Throughput annwers "how manny features"

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

Tags: value, kanban, flow, wip

Note: WIP has not realised value yet

Cycle Time: The amount of elapsed time that a work item spends as Work In Progress. (Location 306)

Tags: cycle time

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. (Location 314)

Tags: flow

Note: .flow measure elapsed time. This includes weekends

Cycle Time represents the amount of time it takes to get customer feedback. (Location 350)

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). (Location 355)

Tags: cycletime, flow

Note: .flow .cycletime flow efficiency = total time work on item / cycle time

Throughput: the amount of WIP (number of work items) completed per unit of time. (Location 368)

Tags: through put

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. (Location 372)

Tags: through put

Note: Velocity measures story points, throughput measures number of stories

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 (Location 421)

Tags: queueing, littleslaw, flow

Note: .flow .littleslaw .queueing

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). (Location 488)

Tags: multitasking

Note: .multitasking

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). (Location 512)

Tags: littleslaw

Note: .littleslaw steady state,same units and long pleriod of time

Every time you violate an assumption of Little’s Law your process becomes less predictable. Every time. This increased unpredictability may manifest itself as longer Cycle Times or more process variability or both. (Location 566)

Segmenting WIP I mentioned in Chapter 2 that it is possible to segment your WIP into several different types. For example it might be useful to think of your WIP not as just generic work items, but categorize it into types like “user stories”, “production defects”, “maintenance request”, etc. This is a perfectly valid approach and actually may be desirable in most circumstances. The good news is that if you choose to segment your WIP in such a manner then Little’s Law will apply to both the overall WIP in the system as well as to each type or groups of types. (Location 590)

Tags: kanban

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 (Location 619)

Tags: sizing, flox

Note: .flox .sizing

Little’s Law is a relationship of averages. (Location 668)

Tags: littlelaw

Note: .littlelaw

there are five assumptions necessary for Little’s Law to work, they are: The average input or Arrival Rate (λ) 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. (Location 670)

Tags: littleslaw, kanban

Note: .kanban .littleslaw

CFD Property #1: The top line of a Cumulative Flow Diagram always represents the cumulative arrivals to a process. The bottom line on a CFD always represents the cumulative departures from a process. (Location 737)

CFD Property #2: Due to its cumulative nature, no line on a CFD can ever decrease (go down). (Location 842)

A backlog, therefore, is merely a convenient container for these candidate ideas. Commitment does not happen until a team actually has capacity, and prioritization does not happen until at the time of commitment (Location 888)

CFDs demonstrate the cumulative arrivals and departures to a process over time, and, as such, are one of the best tools available for visualizing flow. (Location 904)

The best way to capture data for a CFD is to track the date at which an item enters each step of your process workflow. You are going to need those data points for other analysis anyway, so you might as well collect those from the start. (Location 911)

Three easy ways to spot if a CFD has not been constructed properly: If any line on the chart slopes downward on any part of the graph. If something that sounds like a “backlog” has been graphed (remember, a visualized backlog may not necessarily be bad—but it usually is!). If some type of projection has been plotted. (Location 912)

CFD Property #3: The vertical distance between any two lines on a CFD is the total amount of work that is in progress between the two workflow steps represented by the two chosen lines. (Location 924)

the horizontal difference between the top line of a CFD and bottom line of a CFD at any point along the graph is your process’s Approximate Average Cycle Time. (Location 935)

CFD Property #4: The horizontal distance between any two lines on a CFD represents the Approximate Average Cycle Time for items that finished between the two workflow steps represented by the chosen two lines. (Location 941)

CFD Property #5: The data displayed on a CFD depicts only what has happened for a given process. Any chart that shows any type of projection is not a CFD. (Location 978)

CFD Property #6: The slope of any line between any two reporting intervals on a CFD represents the exact Average Arrival Rate of the process state represented by the succeeding band. (Location 1004)

CFD Property #1 is that the top line of a Cumulative Flow Diagram always represents the cumulative arrivals to a process. The bottom line on a CFD always represents the cumulative departures from a process. CFD Property #2 is that due to its cumulative nature, no line on a CFD can ever decrease (go down). CFD Property #3 is that the vertical distance between any two lines on a CFD is the total amount of work that is in progress between the two workflow steps represented by the two chosen lines. CFD Property #4 is that the horizontal distance between any two lines on a CFD represents the Approximate Average Cycle Time for items that finished between the two workflow steps represented by the chosen two lines. CFD Property #5 is that the data displayed on a CFD depicts only what has happened for a given process. Any chart that shows any type of projection is not a CFD. CFD Property #6 is that the slope of any line between any two reporting intervals on a CFD represents the exact Average Arrival Rate of the process state represented by the succeeding band. (Location 1038)

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. (Location 1073)

Tags: cfd

Note: .cfd

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). (Location 1083)

Tags: cfd

Note: .cfd

Stair Steps A batch transfer in your process will manifest itself as “stair steps” on your CFD. (Location 1096)

Tags: cfd

Note: .cfd

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. (Location 1184)

Tags: cfd

Note: .cfd

Little’s Law Assumption #1: The average input or Arrival Rate of a process should equal the average output or Departure Rate. (Location 1201)

Measuring the rate of departures from the system is exactly the same as measuring the rate of arrivals. We simply count the number of work items placed into Deployed (that have “crossed the line” so to speak) per unit of time. Again, the unit or interval of time is not important, only that you match your departures interval to your arrivals interval as discussed above. (Location 1244)

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

Tags: kanban

Note: .kanban match the arrival rate to the departure rate

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. (Location 1330)

Tags: kanban

Note: Match arrivals to departures

Little’s Law Assumption #2: All work that is started will eventually be completed and exit (depart) the system. (Location 1358)

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? (Location 1363)

Tags: prioritisation, backlog

Note: .backlog much of the backlog is never worked on, so prioritisation and grooming efforts are wasted

“spike” I mean a work item—user story—that is used to drive out risk and uncertainty in another work item). (Location 1438)

Tags: spike, kanban

Note: a spike is used to drive out risk and uncertaintity in other items

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. (Location 1444)

Tags: flow, kanban

Note: If work does not flow all the way through it is wasted effort

If the Approximate Average Cycle Time is greater than the exact Average Cycle Time, then you can conclude that your process is incurring what I would call “Flow Debt”. Flow Debt is when Cycle Time is artificially reduced for some items of Work In Progress by “borrowing” Cycle Time from other items of work in progress. (Location 1488)

To explain, a smaller exact Average Cycle Time calculation when compared to the approximate average would tell you that you have (either explicitly or implicitly) favored the faster completion of some work items over the regular completion of others. You were not able to conjure that shortened Cycle Time out of thin air (we are not like the Fed who can just print money). This new ability to complete some items faster than they normally would have finished must have come from somewhere. (Location 1491)

Approximate Average is Less Than Actual Average This scenario is a bit less interesting than the last one. If in the above situation we were talking about accumulating Flow Debt, then the case where the Approximate Average Cycle Time on your CFD is less than your actual Average Cycle Time means that you are paying off Flow Debt (again, for the time interval under consideration). A larger actual Average Cycle Time means that those items that have—for whatever reason—languished in progress are now finally completing. The actual average has become inflated because as the artificially aged items complete they make the actual average calculation come out “larger” than it otherwise would have been under normal circumstances. (Location 1553)

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) (Location 1587)

Tags: flow

Note: .flow

Third, percentiles are not skewed by outliers. One of the great disadvantages of a mean and standard deviation approach (other than the false assumption of normally distributed data) is that both of those statistics are heavily influenced by outliers. You have probably heard the saying, “If Bill Gates walks into a bar, then on average everyone in the bar is a millionaire”. Obviously, in the Bill Gates example, average is no longer a useful statistic. The same type of phenomenon happens in our world. However, when you do get those extreme Cycle Time outliers, your percentile lines will not budge all that much. It is this robustness in the face of outliers that is why percentile lines are generally better statistics for the analysis of Cycle Time. (Location 1705)

The second major reason that a triangle pattern might emerge on your Scatterplot is a process that is dominated by Flow Debt. Remember from Chapter 9 that Flow Debt accrues any time that items are left to age arbitrarily. Aging of items could be due to blocks, too much WIP (as in the case above), or poor (or misunderstood) pull policies. (Location 1801)

Some qualitative things to look for on Cycle Time Scatterplots: A triangle pattern that never flattens out Clusters of dots (either high or low) Long periods of gaps in the data Extreme outliers Dots that just cross a give percentile line (Location 1877)

According to a life expectancy calculator at WorldLifeExpectancy.com (at the time of this writing), a female born in the United States has a life expectancy of 85.8 years at the time of her birth. If she lives to be 5 years old, her life expectancy goes up to 86.1 years. If she lives to be 50, her life expectancy becomes 87.3 years. And if she lives to be 85 (her life expectancy at the time of her birth), her new life expectancy jumps to 93! This data is summarized in the following table: Figure 12.2: Life Expectancies at Different Ages It is a little known fact that the older you get, the longer your life expectancy is. That is due to the fact that the older you get the more things you have survived that should have killed you. (Location 1979)

Tags: aging

Note: .aging the older you get the larger your life expectancy

When an item has aged to the 70th percentile line, we know it is bigger than more than two-thirds of the other items we have seen before. And now its chance of missing its SLA has jumped to 50%. Flip a coin. The conversations we were having earlier (i.e., when the item hit the 50th percentile line) should now become all the more urgent. (Location 2000)

A Class of Service is a policy or set of policies around the order in which work items are pulled through a given process once those items are committed to (i.e., once those items are counted as Work In Progress). (Location 2056)

The second subtlety of the above definition is that CoS does not attach until a work item has been pulled into the process. I cannot stress this point enough. There is absolutely no point in having a discussion about whether work item A is an Expedite (for example) and whether work item B is a Fixed Date while both items A and B are still in the backlog. The reason for this is, as I have mentioned so many times before, is that while those items are still in the backlog there is no confidence that either will ever be worked on. (Location 2072)

In this next round, we are going to replace our strict FIFO pull order policy with a policy that says that we will choose which item to pull next completely at random. One way it may help you to think about this is when two items are finished in the Development column, we are essentially going to flip a coin to see which one we should pull next into the Test column. Any guess now as to what this new policy is going to do to our expected Cycle Time? To variability? To predictability? Figure 13.3: Random Pull Order with no Expedites In this case (Figure 13.3), the simple switch from FIFO queuing to random queuing has increased our 85th percentile Cycle Time from 50 days to 60 days—that is an increase of 20%! (Location 2109)

Note: Picking tickets to pull at random makes the system more unpredictable

introducing an Expedite CoS is worse for predictability than simply pulling items at random. (Location 2129)

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. (Location 2218)

Tags: value

Note: .value we only know the value of something when put into the hands of customers

By definition, CoS will introduce variability and unpredictability into your process. The unpredictability manifests itself—among other things—as Flow Debt (Chapter 9). The truth is that the only part of your process that is more predictable with CoS is the highest priority class. Overall, CoS will cause your process to actually take a predictability hit (see Figures 13.4 and 13.5). Are you really that confident that the upfront value decisions that you are making with CoS are worth more than all the negative implications? (Location 2247)

Class of Service is the policy or set of policies around the order in which work items are pulled through a given process once those items are committed to (i.e., counted as Work In Progress). (Location 2260)

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

Tags: forecasting

Note: Forecast includes date range and probability

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”. (Location 2289)

Tags: average

Note: .average average is not very useful unless you know the distribution

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. (Location 2308)

Tags: cfd

Note: .cfd dont use for forecasting

do not recommend using Little’s Law or a straight-line projection to make a forecast for a completion date. That is because both approaches are based on averages and neither give a probability of success. (Location 2353)

Note: Always have a probability for succsss

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. (Location 2358)

Tags: forecasting

Note: .forecasting

Rule of Five – There is a 93.75% chance that the median of a population is between the smallest and largest values in any random sample of five from that population. (Location 2498)

By using the Scatterplot, teams could clearly see stories whose Cycle Time exceeded normal ranges, perform root cause analysis and take steps and actions to prevent recurrence. (Location 2745)