How should you do long term releases with Kanban?

Question

With Scrum you can try to plan longer releases using team velocity. If the team velocity is 100 Story Points (SP)/Sprint and the Product Backlog has 1000 SP then you can say you can finish in 10 Sprints.

When developing software with Kanban it doesn't have velocity. How can you plan releases with Kanban?

I see cycle time and lead time used often. Is it with these? I assume tasks must all be the same. Otherwise, how can you use these KPIs? If one story is 2 SP and one is 8 SP, Scrum adds them up, but in Kanban their times will differ. Do you average?

How can you plan releases when developing software in Kanban?

Answer 1

Because Kanban is not a full framework for developing products in itself (it's a method to optimize another process), there are many things it doesn't specifically account for. However, teams often track throughput in either item count or even story points if they chose to use them. You can forecast release timelines with either item count or story points exactly like you would in Scrum. You just look at total complete in a period of time like week or month.

Answer 2

Daniel is spot on, feel free to add story points to the process if that helps you estimate the delivery time better. But similar sized tasks and average cycle-times will probably give a similar range without the time put into estimation.

I think that typically when using Kanban you would release when you see fit. So either you pick a date and release everything that is DoneDone on that date OR you pick a item on your todo-list and release once that one is done.

Answer 3

With Scrum you can try to plan longer releases using team velocity. If team velocity is 100 Story Points (SP)/Sprint and the Product Backlog has 1000 SP then you can say you can finish in 10 Sprints.

Theoretically, yes. In the real world, though, if you can have your scope of work so well-defined, why are you using iterative and incremental methodologies? Frameworks and methods like Scrum are best suited to cases with higher amounts of uncertainty and ambiguity, which prevent this kind of long-term planning and commitment.

When developing software with Kanban it doesn't have velocity. How can you plan releases with Kanban?

Like with Scrum, I'd assert that methods and practices like Kanban are best suited to environments where long-term planning and commitment aren't viable. Release planning is primarily around organizing the work so the most important work happens first and using other techniques to release usable increments as frequently as possible.

I see cycle time and lead time used often. Is it with these? I assume tasks must all be the same otherwise how can you use these KPIs? If one story is 2 SP and one is 8 SP, Scrum adds them up, but in Kanban their times will differ. Do you average?

In addition to cycle time and lead time, you can also consider throughput. If you know these metrics along with the size of the work, you can forecast when a given piece of work will likely be done based on where it is in the backlog. As you shuffle the backlog, you can use these same metrics to determine what impacts those have on particular units of work getting to the top of the backlog and then from the top of the backlog to a done state.

There's also nothing that is stopping you from using cycle time, lead time, and throughput with Scrum, as well. Scrum.org has built the Kanban Guide for Scrum Teams to help incorporate traditional Kanban tools and techniques into the Scrum framework to support Scrum's roles, events, and artifacts.

Answer 4

Great question!

Kanban works best when all tasks are a very similar size. Your team's velocity is simply the rate at which they complete tickets. This makes predicting effort reasonably easy.

Which ticket size to use? From experience, 3-5 days works quite well. If a ticket is larger than 5 days, we split into smaller tickets. If a ticket is only 1-2 days, we see if we can merge with another ticket. Often this works quite well, and the mere exercise of doing this has often lead to a better plan.

Of course, software release planning has a lot more to it. A big part is that is a continuous process. As the deadline approaches, the progress towards it needs to be continuously evaluated. If there is risk of missing the deadline, then we see if we can reduce the scope, reduce the quality, add developers, or see if there is flexibility in the deadline. For this, Kanban is a great tool to facility making these decisions, even without story points.

Answer 5

You can't do long-time planning with Scrum either. In Scrum velocity is used to plan the next Sprint (aka yesterday's weather estimates). It's a quantity that changes with time and isn't suitable for long-time planning. Not to mention that you don't estimate stories outside of the Sprint and therefore you can't know how many Story Points the backlog contains.

In JIT (Kanban) you release every task separately once it's done (or group them in small batches). Again, this isn't about long time planning. So you're clearly not doing JIT releases and can't measure lead time which makes JIT almost irrelevant to you. The only part that still can be relevant (still an important one) in JIT is "pulling".

Answer 6

Gotta say this, also ... "story points (SP)" cannot be relied upon to truly describe the internal complexity of any software system which has been devised to satisfy them. "Story points" are a measure of externally-visible functionality as seen from the point-of-view of a narrowly-defined set of users. The underlying software system undoubtedly has complexities that "SP's" have never thought to consider.