Scrumban when will this be done

Dennis Stevens wrote a wonderful blog post called Kanban and when will this be done where he talks about how to forecast done dates in a kanban environment and how kanban looks at estimates, unperdictability, and how to make commitments. I think its a great post, go read it!!! After you’re done, try to think how it applies in a Scrumban environment, or more specifically, where the delivery is not continuous but scheduled in a sprint-like fashion. As Cycle time is supposed to reflect start to finish, and finish usually means delivered, Cycle time in a sprint environment will include time waiting for the release/delivery event (E.g. every 2 weeks). So for example a story with 2 days cycle time to “ready to deliver” might have either a 3 days cycle time end to end, or 10 days cycle time end to end, depending on how long it waited to be delivered. This means that the cycle time histogram used to create the T-Shirt sizes will not be very useful.. What should you do? It probably makes sense to measure cycle time up to the release activity, and add the frequency of the release activity to the “when will this be released” forecast. so for example our 2 day cycle time story, added to a 2w frequency of delivery will end up being a 16 day cycle time from first place in queue. When looking at longer-term commitments this effect is diminished somewhat, especially if lead times are much longer than the cycle times and the delivery frequency. Tools like LeanKit Kanban provide a way to define different levels of cycle times, which might come in handy for such situations. There might be also some way to provide dynamic disneyland queues that take into account the fact that “next delivery cycle” might be 1 day ahead, or 10 days ahead. But I think this goes back into the land of planning what is going to fit before the next delivery cycle. And that is “Scrum Sprint Planning/Commitment” world, which is what we’re trying not to do here (but works in some environments…)