Estimate Item Delivery from Throughput plus blockers

Question

We are combining all of our projects into one Kanban board. Since we are only ever one team, it seems to make the most sense to combine everything to one board and prioritize as we can all only work on one thing at a time.

Is there a good tool or method to calculate the completion date of a given story based purely on estimated time to complete, assigned user, given number of workable hours in a day and known blocking items? I understand that this is always going to be an estimate and we need to be ready for change, but that's exactly why I'd like to do it. So the team can easily see that changing priority or adding other items causes certain completion dates of stories to be pushed back.

I would think that there is some way for a system to know when an item will be completed. If, for example, it knows that there is a backlog of 120 hours for a given user and that our team only works on items from the board for 4 hours in a day. Of course, the final piece would be recognizing linked issues, that are blockers; so that for some items, it knows that other pieces must be completed first.

If it helps (or hurts, lol), we are using JIRA.

Answer 1

When using Kanban, Cycle Time is your guide. Cycle Time is the measure from one point of the cycle to another. Generally from when the item starts being worked, to when it is done. Related to this, and fairly important is Lead Time. This is how long from when a request is made to when it is done.

If your work items are generally similar in size, then cycle time can be all you need. You look at your average cycle times (there is a Jira report for this) and this tells you how long from when something moves to "In Process" to "Done" will normally take.

If you're work items are generally varying in size, then cycle time is going to need to be tweaked and can lose some accuracy. However, I've found that even on a new feature team doing both new work, rework and bug fixes, the amount of each type tends to even out. So you can get a general cycle time. Also, you can run cycle times by work items, so have a cycle time for a new feature and a cycle time for bug work. Again, Jira can filter by this.

Ultimately, estimates are a more measure for forecasting. If nothing else, forecasting is something management cares about and when you start using metrics directly to forecasting you can end up with the metrics getting skewed by the team as they unconsciously (or consciously) try and deliver to the forecast. I recommend heading over to FocusedObjectives.com. Troy's Agile Forecasting model is an excellent tool and can create much greater accuracy than traditional agile forecasting that uses velocity.

Answer 2

To answer your question directly - I don't think there's such a system in place. Even if there was, I wouldn't trust it too much, because it would be as accurate as your forecasting is.

The way I do it and the way other (smart) people that I know do it, is to use historical data to predict the future, based on Monte Carlo simulations. It does not allow you to predict exactly when a certain item will be out of the system, but it will allow you to accurately guess the number of items you can complete by a certain date.

Check the Monte Carlo section here for more details: Flow Analytics with Monte Carlo simulations

I hope this helps.