I like to have a three tiered system for the complexity of tasks:

Level 1 tasks: I could write out the pseudo-code for this task right now

Level 2 tasks: I could outline the basic algorithm for this task right now

Level 3 tasks: I would have to do some research or experimentation before starting this task

So you then have an average cycle time, which you could additionally break down into level 1 cycle time, level 2 cycle time, etc.

This has the added benefit of offering more accurate estimates for future work. For example, you could easily categorize your backlog into one of these three levels and be able to determine approximately how long the top priority item would take to get to completion. You could also use throughput for each complexity level to forecast project completion. This method of forecasting is the most accurate I have seen to date.

]]>You are right: we need both the cycle time AND throughput to make a prediction. The relation between those variables can be defined by this formula:

**throughput = (wip / cycle time)**

In my example, “the team finishes one story every X days”, the throughput is “one” and the cycle time is “X”, so my prediction works with the (N * X) calculation of remaining days to finish the work, with N being the number of stories to do. In your example, with a cycle time of 10 days and 40 stories, we would still need the throughput to make a correct estimation of remaining days. The formula would be something like (40/throughput) * X. In my example, as the throughput was 1, I didn’t have to divide N by it.

Best regards!

Tiago.

I think you’re actually making your predictions with throughput, not cycle time. In the example above, you might say the team finishes 1 story every day, or 5 stories per week.

You’d have to predict using cycle time differently. Let’s say your cycle time is 10 days and you have 40 stories. (Cycle Time * Stories) here would be 400 days to finish. This would be true if you only had one story in progress at a time, but most teams will have multiple in progress at once. How would you account for that?

]]>There are a few links I could provide, but this one has some drawings which clarify the point.

http://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycle-time/

]]>I really meant “product advancement”, in the sense that we should focus on improving our product so that we can reach our goals, using our KPIs as a guide. We should always advance and not just develop a product, because if we just develop, we can start walking on circles. ðŸ˜‰

Regards,

Tiago.

Focusing on product advancement instead of the development team performance « Tiago Motta Jorge's Professional Blog…

]]>