Should the Kanban CFD be weighted with estimates?

Question

I am working in a Kanban process with a team the tries to estimate Cycle time, Lead time as well as completion time based on applying FIFO wherever possible on our queues.

Using the Cumulative Flow Diagrams is very helpful in this process. However most systems I have used do not account for time estimates in this graph. The latter vary significantly in my team and also differ between iterations.

The systems I have used so far, only count the tickets in the CFDs. Hence I largely discard them and measure velocity weekly, dividing completed story point estimates by the available resource in that week.

I am looking for a CFD and associated calculation of common metrics based on estimates. Are there any Kanban systems that can do this?

Answer 1

For predictions purposes, we are using lead time distribution diagrams in the Kanban method (source):

The diagram above shows the number of finished work items (the height of the bars) with their lead times (x-axis). The rightmost lead time is the best estimate for your upcoming work items based on the “past experiences”. Based on the diagram above, you can decide to go with 2 days lead time, because in most of the cases the work has been done in 2 days. However, the evidence shows that there were work items with longer lead times, so taking 2 has higher risk in being late than the rightmost 16. So if you don’t want to be late, it is wise to give that time as an estimation or prediction.

You can of course have different distribution diagrams for different work item sizes and use them for prediction/estimation.

Answer 2

I haven't seen a tool that provides you 'story point cycle time', however - I also use this type of calculation (due to varying user stories).

The best I can suggest you at this point is to do a weight average of your user stories (according to their sizes) development time.

It will provide you average cycle time of story point. This is based on the assumption that story point is (more or less) a unified work unit. Here is the calculation: 1. For each ‘done’ user story: multiply it’s size in the number of days it took to develop it. 2. Sum all the results of #1. 3. Divide the result of #2 by the total story points of your ‘done’ user stories.

Example: If you have the next 3 ‘done’ user stories:

5 story points, it took the user story 10 calendar days to be developed.
3 story points, it took the user story 6 calendar days to be developed. 2 story points, it took the user story 8 calendar days to be developed.

The cycle time is: (50+18+16)/(5+3+2) = 8.4 days. Your cycle time per story point is 8.4 days.

Answer 3

There is a chance you may be misusing Cumulative Flow Diagrams, since the point of the diagram is to identify process bottlenecks and estimate how long it will take to complete assignments. However, if there are huge differences between the effort required to complete various tasks, then I guess a different approach may be necessary.

An easy way to accomplish a weighted Cumulative Flow Diagram is to count "Story Points" instead of "Jobs". Assume a team has been asked to complete three jobs, A, B, and C. Rather than enter those jobs on the CFD, first convert each job to story points (e.g. A=8, B=13, C=20). Now, use those point values to construct a CFD that will show you the number of story points in each phase of your process and help you forecast how long it will take to complete your backlog of points.

Before doing this, take a look at this post on creating and using cumulative flow diagrams to double check you are currently using the diagrams properly.