These simple charts show how we can combine Scrum (with periodic releases) and Kanban (with very frequent releases) and combine them in a “ScrumBan” process that has periodic releases, and is an improvement on the normal Scrum process. It's better for distributed teams, and closer to the way many of them actually work now. It's a simple step toward the fully scalable process that we will propose later.
Here’s what a Scrum process looks like in a “continuous flow diagram:”
You select your current work as a “Sprint backlog.” Then, you burn up the completed tasks until (hopefully) you are ready to release.
In actuality, you don’t usually see sprints that match this chart. Tasks get added near the beginning, and removed near the end. You can get a lot of bottlenecks when you get near the end of a release.
In a Kanban process, you select a list of "Work In Progress (WIP)." As you finish one task from this list, you select a new task. This continues without stopping at special release points.
Note that WIP in a Kanban process is usually not expressed in terms of size or points. This is because Kanban uses a “lean” philosophy, where the idea is to avoid having tasks that are waiting around for someone to work on them. Kanban limits the number of tasks, regardless of size, so that each current task has someone that is working on it. A task that will take 1 day and a task that takes 9 days require the same amount of attention today. In contrast, a Scrum team will consider a task that takes 9 days to be similar in size to 9 tasks that take one day, sequentially. The Kanban WIP limit is a simple and effective way to ensure that each current task is finished as rapidly as possible, it doesn’t require estimating, and it provides a natural way to work on tasks that take longer than one iteration.
The Kanban process has a lot of advantages, and it is great if you update an online service with daily releases. However, most teams can’t release every day. They send things to the appstore once per month, or have enterprise clients that will accept quarterly updates, or burn CD’s or PROMS every year. They need periodic releases that are stable. For those teams, we suggest the ScrumBan process.
In our idealized ScrumBan process, you start your sprint with the normal Kanban process. When you get closer to the end of the sprint, you do some things to get ready for a release which I have labeled here with my own vocabulary.
Triage: Find tasks that you are not going to finish by release time, and get rid of them by moving them to a future release. This is actually an important part of any process that delivers releases at a fixed time. I have diagrammed all of the triage at one time, but you should actually do it whenever you find a task that is not likely to be completed in time.
Feature Freeze: Stop adding new tasks to the list of current work. Then, you can stabilize your release by burning down the list of incomplete tasks and problems (shown here as burning up the closed tasks).
Stabilization: Finish or remove tasks, and fix problems, until you have a stable release. The cumulative flow diagram converges to the end of the iteration, One hint for the stabilization phase is to not allow developers to move on to new tasks until the release is finished. This creates psychological pressure to finish a good release.
I find that the stabilization process often takes about 1/3 of the release cycle. A good rule of thumb for your first release cycle is to do an aggressive triage and a feature freeze by the time you have used up 2/3 of your time to release. If you can stabilize in a shorter time, you might be ready for a straight Kanban process, using this testing secret.
If you are using Scrum sprints, I recommend that you try this Scrumban process for your next sprint. You get two immediate advantages:
1) You don’t have to do estimating and sprint planning. Hooray! You get an extra day for design and programming. If you have one or more distributed teams (like the Constant Contact project shown below), you avoid the logistical challenges of agreeing on a sprint plan.
2) You can add bug fixes at any time. In the idealized Scrum process, it’s annoying how bug fixes go into a separate work queue.
Compare the ideal Scrumban diagram to this real continuous flow diagram presented by Gil Irrizarry of Constant Contact.