17

I'm currently working with a development group that has a variety of project management approaches. They use a Kanban board for tracking work with a constantly re-prioritized backlog, they have iterations and a burn-down chart like scrum, and they have a PMO that wants to know the overall status of the project in a nice, neat timeline.

After working with the project for about a month, it seems like this team delivers sets of functionality that usually take a few weeks to create and the priorities shift frequently, making Kanban a great approach for the team. I'd like to get rid of the burndown charts and the long-term project plan, since it changes so often, but there is a real sense of apprehension that some of the long-term goals for the overall project won't be met by their required deadlines.

Does anyone have experience with Kanban metrics to demonstrate progress through work - especially long-term goals that are being worked toward?

12

Most common metrics used along with Kanban are:

  • Cycle time / production lead time

    There is some confusion over naming so let me explain in a bit more detail. Production lead time or cycle time is time that elapses from the moment a team starts actively working on a task till the moment they are done (or done-done). This metric basically say about how responsive the team is or how fast they can deliver something when priorities change.

  • Customer lead time

    Time that elapses from the moment a customer or a user submits the work item to a backlog to the moment they can use it. In other words, if a feature is queued for long time in the backlog it would hit customer lead time while it won't hit cycle time / production lead time. This metric say about how the whole organization or product team (not only a development team) reacts to customer's needs.

  • Throughput

    A measure of productivity or efficiency which is typically a number of features delivered over time. Some teams tend to weigh delivered features basing on assumption that a big feature is worth more than a small one but that's tricky at best.

  • Work in Progress (WIP)

    Simply a number of work items that are currently in progress in the whole process. As a stand alone measure it doesn't make that much sense but it gives a lot of insight when combined with other measures. One classic example is Little's Law which adaptation to this context goes like this: Average Cycle Time = WIP / Average Throughput

  • Tact Time / Takt Time

    A measure that says about frequency of delivering new work items. Tact time is Average Cycle Time divided by Average WIP. In other words it tells about throughput of a team and allows to assess whether remaining work would be done before a specific deadline.

There are tools that help to make sense out of these measures. A simplest one is a burn-up chart which is an alternative to burn-down chart that is more intuitive to use especially in cases where the scope changes frequently.

Another tool that shows even more is Cumulative Flow Diagram (CFD). CFD would show more data, e.g. give you sense of how much WIP is there in the system or what roughly are cycle times / production lead times and customer lead times.

Value

Now, the tricky part is that aforementioned measures and tools are tools to measure efficiency and not effectiveness, i.e. how well we are doing in accomplishing our long term goals. For the latter there is one crucial bit that is missing here--an idea what value is.

In other words the organization has to be able to answer the question how valuable each work item is or how it contributes to accomplishing long term goals. Only then you would be able to translate any efficiency measures to long term goal accomplishment.

Are we there yet?

Finally, there is a question you mention, which is an answer to a question what is project status. For that I would typically use a CFD and a forecast of progress basing on throughput over time (which is a curve representing done stage). However, instead of looking when it crosses current scope curve I'd use a forecast of scope change basing on how it was changing in the past. If it was growing over time the forecast would represent that. If new features substituted the old ones it should be pretty stable.

This would give you an answer about the estimated delivery date. While I don't think percent complete is, in such a setup, a very useful number I'd estimate it dividing a number of features done by estimated number of features at the end of the project, i.e. not the total number of features we have now.

This works under an assumption that the scope will be changing over time roughly in a similar manner as it did so far. This is something that the organization is in control of, e.g. you can decide that you don't add new stuff or remove some of the planned stuff. This would render the forecast of scope change irrelevant but this would also give additional data what kind of scope you work against.

  • By the way, your CFD article is awesome and I'll be passing it along to others. – Daniel Jan 29 '14 at 20:43
1

I would establish a fixed capacity bandwith for each type of work

  • Long term goals
  • Items whose priority changes often
  • Support

I have written about it here and here on this list. Please check those answers out.

The Long term goal development can be tracked with a burn-down or Earned Value.

1

I think that the most common are:

  • Cycle time
  • Lead time
  • Throughput work
  • Work in Progress

On a daily basis, I prefer to analyze cumulative flow diagram and time tracking metrics.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.