3

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?

1

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

distribution of lead times

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.

  • Thansk Zsolt! My concern is that the type of issue we work to differs a lot over time. I am really after a system that caters for that. At the moment most of our issues (there are 16 on the board) are between 5 and 8 hours estimates. Next week most of the issues will be a lot shorter rarely exceeding 2 hours. This means my CFD will be very uneven and I find it hard to estimate how many issues we can accept in the backlog without affecting our lead and cycle times. So I was hoping to find a system that uses estimate values in the CFD to improve estimates. – Hans Apr 15 '13 at 13:05
  • The good practice is to regenerate your chart. If your context/system whatever changes on a weekly basis, then create a new chart in every week, and use for predicting the next week. – Zsolt Apr 16 '13 at 8:24
  • How accurate do your lead time estimates need to be? If you say 4 hours and it takes 8, is that a huge issue? Seems a little overly granular. – Andrew Clear May 17 '13 at 22:07
  • If 4 hour long lead time was at the right end of your histogram and the latest measurement shows 8 hours, then you need to figure out what has happened. If nothing unordinary, then your new predication is 8 hours, if it is not the case, you'll need some safe to fail experiments to dig deeper. – Zsolt May 18 '13 at 12:50
0

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.

0

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.

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.