How do I use cycle time to predict when team can deliver item #3 from backlog?

[Rob]

Our product folks want to use historical data (not hourly estimates) to know what our roadmap of Stories might look like. We have a ranked backlog.

We are doing Kanban of sorts and have these statuses:

• Backlog
• Awaiting Development
• Dev In Progress
• Awaiting Merge
• Awaiting Quality Review
• Quality Review In Progress
• Awaiting Deployment
• Deployed

So I've got a cycle time graph. I selected all status except Backlog, Awaiting Dev and Deployed for Story issue type. To me this means "once the developer started working on the issue, it took X days to release that to our customers." The mean value I'm looking at (including non-working days) is 56 days.

I was thinking I could use this value to look at, say, the top 3 items ranked in our backlog and roughly get an idea about when they might hit our customers. But, I'm realizing now that a) that 56 days is how long it took to get that issue out to customers after development started. It takes into account the bugs and other stuff that was worked on that blocked that from getting release. Cool.

But, this number is a bit misleading since it looks historically from the POV of the issue, not the team. Like we released 4 stories to our customers in January that each took around 40 to 60 days. In other words, looking at our ranked backlog it doesn't necessarily mean that backlog item #3 will get out in 56 x 3 days since we have five people on the team and a higher capacity than that. But it doesn't mean I can somehow divide by 5 since some folks work on bugs, etc.

Am I thinking about this all wrong? I feel like the data is there, I just want to know how we can look back in history and very roughly predict where each Story in the ranked backlog might fall in a roadmap.

[Andreas K. · Accepted solution]

Hi Rob, Well I think what you have is a good start - however, once you start digging it will get more complicated. -> 56 day mean, but how does your normal distribution look like? Are all stories very close to 56 days or does it spread out very uneven? -> Probably not all stories require the same amount of resources and/or have the same amount of resources available What I mean to say is, you can do a nice top-down model using your method - but it will not take away that you will need to do bottom-up planning for each story against: a) the resources you have available and how these are spread across other stories b) the effort it takes to get your story out of the door. It comes down to project and enterprise resource management and how well you do that (Top-Down & Bottom-up). To get back to your historical data a) and b) - I would suggest that you also add the amount of man/days you had available in parallel to your historical data. Otherwise you will not take available resources (hire/fire/transfers/temps) into consideration. Cheers & best, Andreas

[Andreas K.]

Hi Rob,

Does this help???
https://confluence.atlassian.com/display/GH/GreenHopper+6.1.5+Release+Notes

Otherwise we could go through a scenario to calculate your estimate from scratch...

Let me know :)
Cheers,
Andreas

[Rob]

Hi Andreas,

Unfortunately, we're using Kanban boards and we do somewhat regular ad hoc releases that include whatever work is ready at that time (not planned into sprints). Also, Kanban boards don't have this feature, but we're looking for something slightly different, but seems somewhat common to me:

We have historical data of

a) how long it takes a Story from start of development to deploy status (56 days mean)
b) amount of Stories we've been able to deploy week-over-week (in a Time Since Issues Report: 4 Stories over past 180 days)

With that data (or any other info), shouldn't I be able to make an assessment of when a particular item in a ranked backlog might be released? Not sure if my thinking is sane here, just riffing.