Listen Now

Subscribe on iTunes                   Check out the podcast on Google Play Music

The Software Process and Measurement Cast 397 features our essay on cumulative flow diagrams.  A CFD can help everyone from team members to program managers to gain insight into issues, cycle time and likely completion dates. Cumulative flow diagrams are extremely versatile tools for managing work.

Download the figures that support this essay.

Our second column is a visit to the QA Corner. Jeremy Berriault weighs in on the thorny question of who signs off or approves the results of testing for projects. We discuss some strange behaviors that occur when responsibility and authority for the results of testing are ambiguous.

We also have the debut column from Jon M. Quigley. Jon inaugurates his column with a discussion of whether project risk, scope, and strategy are related.  The short answer is yes, and the longer answer suggests what happens when all of the options are not considered.  Jon is a principle at Value Transformation, LLC (www.valuetransform.com) along with being a teacher, coach, serial author and past guest on SPaMCAST 346. (more…)


A waterfall is an example of a complex flow!

The simple cumulative flow diagram (CFD) used in Metrics: Cumulative Flow Diagrams – Basics introduces most of the concepts needed to read and use a CFD. However, software development, regardless of the size of the work or the method used, is more complicated.  CFDs adapt to the true complexity of software development. CFDs allow teams and managers to visualize the flow of work . (more…)

A Cumulative Flow Diagram (CFD) is a measurement tool for tracking and forecasting work. CFDs are typically associated with Kanban, however, it can be used as a measurement tool for any type of work.  In its simplest form, a CFD is a set of measures that are presented in a visual form.  A simple version of a CFP shows the amount of work that has been completed, how much work is in-progress, and the amount of work still to be done over time. (more…)



Listen Now

Subscribe on iTunes

I am still on vacation (at least for a few more hours), and this week we have another mixtape for you. This week I have included the responses to the “if you could fix any two (or sometimes one) things” question I ask at the end every interview from the three most downloaded interviews of 2014. The top three were:

SPaMCAST 302 featured Larry Maccherone. Larry’s two wishes were:

  1. That we unlearn the natural tendency to look at how a number can be gamed rather than how it can be used.
  2. That he had access to all data and infinite time to analyze the data.

Listen to the whole interview with Larry!

SPaMCAST 318 featured Rob Cross. Rob wished that:

  1. Organizations would realize it is not the tools rather it is the data that counts.
  2. Organizations need to change their culture to focus on security.

Listen to the whole interview!

SPaMCAST 310 featured the return on Mike Burrows.  Mike only had one wish this time:

  1. Development organizations need to embrace balance as a value.

Mike made the list two years in a row! Listen to the whole interview with Mike.

If these excerpts tickled your fancy listen to the whole interview by clicking on the links shown above.

Next week we will return to regular programming with our essay on Agile Project Charters.


A framework is just a framework without planning!

A framework is just a framework without planning!

Personal Scrumban establishes a framework for conquering the chaos that day-to-day life can throw at you. However having a structure, even a structure with multiple classes of service, does not get the most important pieces of work in the queue when they need to be in the queue. Planning is required. Weekly and daily planning exercises, similar to sprint planning and the daily stand-up, are useful for taming the backlog and adapting to the demands of real life.

I begin all weekly planning sessions with a quick backlog grooming session (note: when new items are added to the queue during the week, grooming can be performed). In personal Scrumban, the goal of backlog grooming is not get team consensus (no need for the Three Amigos). Rather the goal is to ensure each backlog item that might need to be tackled in the next week has been broken down so that there are one or two immediate next steps identified. The first step in backlog grooming is to ensure that all work items (or stories) have been classified by class of service. For example, if one of the work items was “Review cover art for the Hand-Drawn Slide Saturday Ebook,” the work item should be classified in the Podcast/Blog class of service. Classes of service act as a macro prioritization and assigns the work to the relevant time slice in any given day. The second step is sizing, just like in Scrum, the immediate next steps should be of a size that can be accomplished in a single sitting. The information gathered in execution will used as part of daily planning or during the next weekly planning session.

Weekly planning is comprised of getting work items in priority order and then deciding which needs to be dealt with during the upcoming week GIVEN what is known when planning occurs. If you have not already established a work-in-process limit (WIP), set one for each class of service. A WIP limit is the amount of work you will allow yourself to start and actively work on at any point. Work is only started if there is capacity to complete the task. Prioritize up to the WIP limit or just slightly past the limit in each category. Remember if as you complete tasks in a category (and you have time) you can refresh the backlog by prioritizing new items. I generally do my weekly planning every Sunday evening so that I am ready to begin the when I roll out of bed on Monday.

Daily planning is exactly like a daily stand-up meeting, with two minor twists. In Scrum, the daily stand-up meeting starts the day with each team member answering the three famous questions:

  • What did I complete since the last meeting?
  • What will I complete before the next meeting? and
  • What is blocking progress?

The three questions provide a framework to make generate laser focus on what is done and what needs to be done. The twists

In personal Scrumban, as in normal Kanban, completed work items would have been moved to the completed column of the Kanban board as soon as they done, however this is a good time to ensure that has occurred. The twists relate to how new items are dealt with and time allocation. During planning, work items that will be accomplished during the next 24 hours should be moved to in-progress. Given the nature of daily planning, if new work items have been discovered and prioritized into the backlog, they then become part of the standard planning process. The stand-up also provides time to reflect on anything that will block accomplishing the planned work items. A second twist to the stand-up process is a reassessment of the time slices being provided to each class of work. For example, if a critical work product needs to be completed, time from a more discretionary class of service can be reallocated and the work items in this category can be put on hold.

A weekly planning session provides a stage to address the week. To paraphrase Helmuth von Moltke the Elder, no weekly plan stands first contact with Monday. The daily stand-up provides a platform to re-adjust to the nuances of the week so that you can stay focused on delivering the maximum value possible. Without planning, all personal Kanban is a framework and a backlog of to-do items.  Planning puts the energy into the framework that provides the guidance and reduces stress.

Bottlenecks constrain flow!

Bottlenecks constrain flow!


We are revisiting one of more popular essays from 2013 and will return to Re-read Saturday next week with Chapter 4 “Creating A Guiding Coalition.”  

Kanban implementation is a powerful tool to focus the continuous improvement efforts of teams and organizations on delivering more value.  Kanban, through the visualization of work in progress, helps to identify constraints (this is an implementation of the Theory of Constraints).  Add to visualization the core principles discussed in the Daily Process Thoughts, Kanban: An Overview and Introduction which include feedback loops and transparency to regulate the process and an impetus to improve as a team and evolve using models and the scientific method and we have a process improvement engine.

Kanban describes units of work that are blocked or stalled as bottlenecks.  Finding and removing bottlenecks increases the flow of work through the process, therefore increasing the delivery of value.

A perfect example of a bottleneck exists in the highway system in Cleveland, Ohio (the closest major city to my home).  A highway (three lanes in each direction) sweeps into town along the shore of Lake Erie.  When it reaches the edge of downtown the highway makes a nearly 90 degree left hand turn.  The turn is known as Dead Man’s Curve.   Instantly cars and trucks must slow down.  Even when there is no accident the traffic can backup for miles during rush hour.  The turn is a constraint that creates a bottleneck.   If the city wanted to improve the flow of traffic, removing the Dean Man’s Curve bottleneck would help substantially.

Here’s an IT example to see how a bottleneck is identified and how a team could attack the bottleneck. We will use a simple Kanban board.   In this example, the team has a backlog similarly sized units of work.  Each step of the process has a WIP limit.  One of the core practices in Kanban is that WIP limits are not to be systematically violated.

Each step can have different WIP limits.

Each step can have different WIP limits.

As work is drawn through the process, there will be a bottleneck as soon as the analysis for the first wave of work is completed because development only has the capacity to start work on four items. In our example of an application of Kanban, when a unit of work completes the analysis step it will be pulled into the development step only if capacity exists.  In this case one unit of work is immediately blocked and becomes inventory (shown below as the item marked with the letter “B”.

Unbalanced process flows cause bottlenecks

Unbalanced process flows cause bottlenecks

The team has three basic options.  The first is to continue to pull more items into the analysis step and continue to build inventory until the backlog is empty.  This option creates a backlog of work that is waiting for the feedback, increasing the potential rework as defects are found and new decisions are made.  The second possibility is that team members swarm to the blocked unit and add capacity to a step until the blocked unit is freed.  This solution makes a sense if the reason for the blockage is temporary, like a developer that is out sick.  The third (and preferred) option is to change the process to create a balanced flow of work.  In this example, the goal would be to rearrange people and tools to create a balanced WIP limits.

Process improvement maximizes throughput.

Process improvement maximizes throughput.

 Visually tracking work is a powerful tool for identifying bottlenecks.  Kanban’s core practices dissuade practitioners from violating WIP because it limits the stress in the process, which leads to technical debt, defects and rework. Other core practices provide a focus on continuous process improvement so that when a bottleneck is identified, the team works to remove it.  Continually improving the flow work through the development process increases an organization’s ability to deliver value to customers.


Listen to the SPaMCAST 310

Software Process and Measurement Cast 310 features our interview with Mike Burrows. This is Mike’s second visit to the Software Process and Measurement Cast.  In this visit we discussed his new book, Kanban from the Inside (Kindle).  The book lays out why Kanban is a management method built on a set of values rather than just a set of techniques. Mike explains why Kanban leads to better outcomes for projects, managers, organizations and customers!

Mike is the UK Director and Principal Consultant at David J Anderson and Associates. In a career spanning the aerospace, banking, energy and government sectors, Mike has been a global development manager, IT director and software developer. He speaks regularly at Lean/Kanban-related events in several countries and his book Kanban from the Inside (Kindle)was published in September.

Mike’s email is mike@djaa.com
Twitter: https://twitter.com/asplake and @KanbanInside
Blog is http://positiveincline.com/index.php/about/UK

Kanban conference: http://lkuk.leankanban.com/
Kanban conference series: http://conf.leankanban.com/


SPaMCAST 311 features our essay on backlog grooming. Backlog grooming is an important technique that can be used in any Agile or Lean methodology. At one point the need for backlog grooming was debated, however most practitioners now find the practice useful. The simplest definition of backlog grooming is the preparation of the user stories or requirements to ensure they are ready to be worked on. The act of grooming and preparation can cover a wide range of specific activities and can be performed at any time). In the next podcast we get into the nuts and bolts of making your backlog better!

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important! October 24, 2014 11:230 EDT
Has the adoption of Agile techniques magically erased risk from software projects? Or, have we just changed how we recognize and manage risk?  Or, more frighteningly, by changing the project environment through adopting Agile techniques, have we tricked ourselves into thinking that risk has been abolished?


Upcoming Conferences:

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

A dam releasing water is an  example of flow through a constraint.

A dam releasing water is an example of flow through a constraint.

The Theory of Constraints (ToC), as defined by Eli Goldratt in the book The Goal (1984), is an important concept that shapes how we measure and improve processes.  ToC takes a systems thinking approach to understanding and improving processes. A simple explanation of ToC is that the output of any system or process is limited by a very small number of constraints within the process. Kanban is a technique to visualize a process, manage the flow of work through the process and to continually tune the process to maximize flow that can help you identify the constraints. There are three critical points from the ToC to remember when leveraging Kanban as a process improvement tool.

  1. All systems are limited by a small number of constraints. At any specific point in time, as work items flows through a process, the rate of flow is limited by the most significant constrained step or steps. For example, consider the TSA screening process in an Untied States airport. A large number of people stream into the queue, a single person checks their ID and ticket, passes them to another queue where people prepare for scanning, and then both people and loose belongings are scanned separately, are cleared or are rescanned, and finally the screened get to reassemble their belongings (try doing that fast). The constraint in the flow is typically processing people or their belongings through the scanner. Flow can’t be increased by adding more people to check IDs because that is not typically the constraint in the flow. While each step in a process can act as a constraint based on the amount of work a process is asked to perform or if a specific circumstance occurs (the ID checker has to step away and is not replaced, thereby shutting down the line), however, at any one time the flow of work is generally limited by one or just a few constraints.
  2. There is always at least one constraint in a process. No step is instantly and infinitely scalable. As the amount of work a is being called on to perform ebbs and flows there will be at least one constraint in the flow. When I was very young my four siblings and I would all get up to go to school roughly at the same time. My mother required us to brush our teeth just before leaving for school. The goal was to get our teeth cleaned and out of the bathroom so that we could catch the bus as quickly as possible. We all had a brush and there was plenty of room in the bathroom, however there was only one tube of toothpaste (constraint). One process improvement I remember my mother trying was to buy more tubes of toothpaste, which caused a different problem to appear when we began discussing who’s tube was who’s (another constraint). While flow was increased, a new constraint emerged. We never found the perfect process, although we rarely missed the bus.
  3. Flow can only be increased by increasing the flow through a constraint. Consider drinking a milkshake through a straw. In order to increase the amount of liquid we get in our mouth we need to either suck on the straw harder (and that will only work until the straw collapses), change the process or to increase capacity of the straw. In the short-run sucking harder might get a bit more milkshake through the straw but if done for any length of time the additional pressure will damage the “system.”  In the long run the only means to increase flow is either change the size of the straw or change the process by drinking directly from the glass. In all cases to get more milkshake into our mouth we need to make a change so that more fluid gets through the constraint in the process.

The Theory of Constraints provides a tool to think about the flow of work from the point of view of the constraints within the overall process (systems thinking).  In most process, just pushing harder doesn’t increase the output of a process beyond some very limited, short-term improvement. In order to increase the long-term flow of work through a process we need identify and remove the constraints that limit the flow of value.


When discussing lean techniques such as Kanban, we often assume that you understand the concept of work-in-process (WIP). That assumption is not always true. I am occasionally asked how WIP is defined in a software development (or an enhancement or maintenance project) and whether related work products, like test plans or documentation, are part of WIP for piece of code.

WIP is work that has entered the production process, but is not yet complete. A slightly more technical definition of WIP is all raw materials or partially finished product that are used or transformed in the production process. In a software development or maintenance project, WIP includes all of the work products or resources required to deliver valuable functionality. In software development and maintenance, WIP for the story will typically include code, documentation, test cases, test results and plans (just to name a few typical work products). All of these work products are WIP until the story is deployed in production.

In the Kanban: An Overview and Introduction we used a simple software development lifecycle to define Kanban and the concept of flow. Using a user story as an example we can trace the transformation from a card into implemented software. The story begins its WIP journey as soon as is pulled out of the backlog and then completes WIP journey when it has been deployed in production. The simple Kanban workflow we used in the past is shown below:


Using the example of simple piece of web functionality we begin with the user story, “As a SPaMCAST listener I want to see the description of the book by current interviewee so I can decide to buy the book.” As soon as I grab the card and put it into the analysis column it is WIP. This is true whether I start fleshing out the user story at that exact moment or later in the day. In order to complete this story it requires that I create a link to the book and embed that link in the blog entry for the podcast episode and then test the link to ensure that it works. The link is complete when the blog entry is in production and the story is no longer WIP. Diving down a little into the detail, when I create the book link I go to the booksellers site (SPaMCAST uses an Amazon affiliate account so that purchases of the books mentioned on the podcast support offsetting the expenses needed to provide the podcast) and select the link for the book. The next step is to paste the link into an Evernote document for documentation purposes. That Evernote document becomes part of the WIP connected to the story. Later if that the link is found to be wrong, not only does the link in the blog entry need to be changed, the link in the documentation will need to be updated. Nothing ceases to be WIP until the link is live on the website and it works correctly. As the story progresses the link is embedded it into podcasts blog entry, the link is tested using a simple test plan (the test plan is part of the WIP related to the story). During the process of finding the link and putting it into the blog entry and Evernote document, the story is being worked on,. When the story is is being actively worked on the story is moving through the process (flow). When the link is embedded and tested the code is complete and ready to be implemented. Ready to be implemented is not same as being implemented. In process for the SPaMCAST podcast, the story is still WIP, but it is no longer being worked on. The flow of the story has been interrupted. If the blog entry or whole podcast needed to be updated the link would need to be revalidated and potentially changed. The listeners of the Software Process and Measurement Cast will know that the podcast typically goes live on Sunday at 17:00 Eastern Time. As soon as the link is validated in production the story moves from WIP to complete.

When discussing WIP in software development it is easy to fixate on the functional software as the only part of the story when tracing WIP. In the example of the book link user story, the process I use to develop the link and ensure that it works includes code (HTML), documentation and a simple test plan. All of these work products are part of the completing the user story. Completion of one work product without the other leaves the story in an incomplete state and still work-in-process.



Kanban is a methodology for shaping and controlling the flow of work through a process. Kanban as a method was popularized and honed though its application in lean manufacturing, specifically in the Toyota Production System. The manufacturing pedigree of Kanban led to application of lean and other engineering concepts such as queuing theory. Little’s Law is a mathematical observation that the number of customers in a system equals the average arrival rate multiplied by the average time the customer is “in” the system. Knowing the average time a customer is in process can be used to judge how many resources should be applied or whether changes speed the process up. Lean and Kanban adherents shift the focus from arrival rate to output, which is more interesting in development and manufacturing environments. Many Kanban implementations use Little’s Law to help forecast and measure throughput.

Little’s Law is typically stated in lean/Kanban circles as:

Cycle Time = Work-in-process/Throughput

Work-in-process (WIP) is the amount of units of work between the start and end points of the process. WIP is measured using the same unit of measure that you used to measure throughput. Use story points for velocity, function points for productivity and stories for #NoEstimates.

Throughput is the average output of the process. Examples of development throughput are velocity (average story points delivered per sprint), productivity (function points per person month) or simply as the average number of stories completed in a sprint (this could be explored by the adherents of #NoEstimates).

Here is an example calculation based on a Kanban implementation I reviewed:

  • Current WIP: 175 story points
  • Throughput: 47 story points per period (two weeks)
  • Cycle time: 175/47 = 3.7 periods or 37.2 days (10 working days per period)

Cycle time, based on Little’s Law, is useful for release planning, monitoring flow and judging whether process improvements are effective in reducing cycle time. Having a measure that informs an organization how fast work transits a specific process can be used to plan when an item from the backlog will enter the process (an item is pulled into a Kanban process when there is capacity to begin work) and when it will be complete. This type of information is critical for informed release planning. If we apply the cycle time metric to monitoring cycle time improvements, it should provide the organization with a means of monitoring and measuring whether throughput is improving.

Little’s Law as typically applied by practitioners of lean and Kanban effectively provides a process throughput metric by measuring cycle time. The original application of Little’s Law focused on waiting time in the queue (how long items sat in the backlog). The current interpretation of Little’s Law is more useful for development organizations trying to maximize output rather than minimizing the backlog wait time.

« Previous PageNext Page »