Show all posts
8 years ago

Flow. Discover Problems and Waste in Kanban

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 that (click to enlarge).

complex user story flow

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 😉

simple user story flow

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

  • Derek Huether, PMP

    Very intriguing technique. Could you tell me if you leverage the process you described on a scheduled basis? If so, what is the frequency and the size of targeted user story? Though I don&#39t think it is very efficient, my client usually asks our vendor to investigate when deliveries fall outside an approved variance range. I like your simple but effective approach.

  • Michael Dubakov

    We are just tried this technique, so there is no any cadence in it. I believe initially it may be used for all suspicious user stories with cycle time (CT) > average CT.

  • Andrew Golik

    Your chart is really informative so it really reveals the waste. It could really help in post mortem investigations or retrospective meetings that are aimed at eliminating muda.

  • Chad Albrecht

    Interesting! Done any work on how the dynamics of multiple user stories affect the system and waste? (Still keeping in mind that we are seeking to reduce WIP)

  • tomolennox

    Very simple! I like it. What do you call your charts?

  • Michael Dubakov

    Not exactly, we are seeking to optimum WIP. At some point you may under-utilize resources if you have minimal WIP. It is required to find a point where throughput is high and there are no bottlenecks.

  • Michael Dubakov

    It is not me who invented this chart. I just used existing idea.

  • Chad Albrecht

    Is under-utilization of resources bad if the system is optimized? (ToC)

  • Michael Dubakov

    Don&#39t get me wrong. It is a bad idea to have 100% utilization for sure. But what number is best for your flow? It may be around 80%, or maybe around 60%. It depends. In general this is U-curve, so it is required to find the optimum.

  • robmi

    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&#39t provide much value without context, culture and “soft” goals.

  • Michael Dubakov

    Wait time is ALWAYS a subject for investigation. This chart shows whether you have it. It is just a sign that you should pay attention to story and discover why delays happened. I know the context, so to me these charts are useful. You know your context, and if you&#39ll draw such chart you will have more information at hands.

    Testing is a stage in our development process. We manually test each user story, since during development full functional testing automation is waste (in our context). In parallel with development testers create test cases and check user story sometimes (a kind of quick smoke test).

  • Fabrice Aimetti

    Hello Michael,
    I&#39ve translated your (super-)post in french :

Try for free

Account url: *
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy