Agile Zone is brought to you in partnership with:

Michael is a founder of TargetProcess (agile project management software). His Mission is to provide solutions to real problems in agile projects. He wrote several books about web development and many articles related to almost all aspects of software development. Michael is a DZone MVB and is not an employee of DZone and has posted 48 posts at DZone. You can read more from them at their website. View Full User Profile

Flow. Discover Problems and Waste in Kanban

  • submit to reddit

You Kanbanized your development process and setup a perfect flow. You see the flow and feel its power. You even measure cycle time and want to reduce it. But it is not as easy as expected. Some problems in your development process are hard to find and are revealed on team level. Here I’ll describe an interesting technique that may help you.

The idea is quite simple. Take a single user story and visualize its states transition from start to finish, thus you see the whole flow of a single story. Draw all available states on Y-axis and days on X-axis. As a result, you will have a chart like this.

It is a real user story from TargetProcess project. It was quite complex and its cycle time was 19 days. Let me provide some comments.

User story has been in Planned state during just 1 day, then developers took it and moved to In Progress state. So far so good. 4 days of development and user story is moved to Coded state, but it sits there for 2 days. Why? Why testers did not take it immediately? Clearly, we found 2 days of delay and the reason of the delay should be investigated, since it increases story cycle time.

Then testers took the user story and tested it for 2 days. Then the  story was moved to In Progress state again and developers worked on it for 2 more days (including Saturday). Why? It is a half of the initial development time. It is a clear sign of a waste, but we need more details. It appeared, that testers found 11 bugs. Half of the bugs were caused by unclear user story specification, other are subject to investigate. We should apply root-cause analysis here to find the real problems.

OK. Then testers have verified the user story for 2 days and moved it to Ready to Merge state. It was merged quite fast (in 1 day), but still there may be a waste to eliminate. Finally, the user story have lived in Merged state for 5 days and was released Jan-29.

In total (and as a minimum!) we discovered about 9 days of waste. It means we can reduce cycle time significantly by eliminating this wait time (waste). If you check several user stories using this technique, I believe you will find comparable results for simple and complex stories.

Here is another example for a quite simple user story. Still we clearly see wait times in our flow! We can reduce cycle time to 2 days instead of 6 by just eliminating waits in the flow. But it is not easy ;)

This chart is a really powerful tool. It is easy to create and you could use it to find waste in the development flow.

Published at DZone with permission of Michael Dubakov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Neil Watson replied on Tue, 2010/02/02 - 10:51am

If you would like an alternative approach, have a look at Eliyahu Goldratt's books, especially "The Goal" then "Critical Chain".  Neither match software development exactly, but the principles apply.


Sindy Loreal replied on Sat, 2012/02/25 - 10:16am

It feels so wrong to analyze cycle time of user stories that way.

Theirs is no context at all. It could be, that the user story was amazingly fast developed? Or very slow? Why is development and testing decoupled at all? At our shop we believe testing and development should be happen parallel.

To call delays as waste days, is a little bit overstated. I totally believe an measurement of software processes and effectiveness and Kanban is nice but "Wait time, waste, and a value stream" are interesting metrics, but as many metrics don't provide much value without context, culture and "soft" goals.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.