Current Articles | RSS Feed RSS Feed

Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade

Posted by Andy Singleton on Tue, Aug 28, 2012
  
  


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.

Scrum

Here’s what a Scrum process looks like in a “continuous flow diagram:”

idealized scrum

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.

Kanban

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.

idealize kanban

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.

ScrumBan

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.

idealized scrumban

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.

constant contact diagramGet Cumulative Chart Diagram and Cardwall to help you out with ScrumBan for free with Assembla Renzoku.

Tags: , , ,

COMMENTS

"and closer to the way many of them actually work now". Wow, no kidding. I have been developing software for a long time, and I have seen this effect many times: it seems that every time we (the software development community) are able to formalize&articulate an idea about software development, it occurs to me that "oh, interesting, we've already been doing that to a great degree on our own team". Indeed it is true with your notion of ScrumBan: it's already what me and my team are doing to a great degree. 
 
 
 
The fun part, for me, is discovering little details, and small bits of vocabulary, that me and my team aren't using yet, and adding them to our process. While the big picture is usually already in place, those smaller additions clean things up in no small way. 
 
 
 
Thanks for your post. 
 

posted @ Tuesday, August 28, 2012 10:03 AM by Tom


Actually, your use of the term "triage" makes me wonder if we can come up with something better. Because I have long used the word "triage" to describe the process that happens on a day-to-day basis when bug reports come into the team from users and testers. We triage them by assigning them to a certain sprint. Maybe the currently active sprint, or maybe a future one. Or maybe it is a very minor issue and we leave it unassigned, just resting in the product backlog until an unspecified later time. That's the process I call "triage". 
 
 
 
The process that you are describing, the one that occurs toward the end of the sprint, during the stabilization phase, I guess I would call that "backlog grooming", or "sprint backlog grooming". I didn't invent that phrase, and haven't really even used it much until the past month or two. I learned from the wikipedia article on Scrum. Previously I just called it "moving undone items from my current sprint to a future one", which has always been kind of a mouthful. So "backlog grooming" has felt better, although I'm eager to hear other ideas as well.

posted @ Tuesday, August 28, 2012 10:33 AM by Tom


So Kanban works off of # of tasks in progress. How does this mean you don't have to use estimates anymore? How does this give you any predictability in deliver times? If some stories will take a few hours and some stories will take a few days (or even a week). It seems like estimates and schedules are very tightly coupled.

posted @ Tuesday, August 28, 2012 4:01 PM by Jody


Jody, there are three answers to that question about estimating: 
 
1) You might not care about estimates, as long as you are always working on your highest priority tasks. Estimates might not be required to decide what to work on. In this case, you save yourself time and improve your schedule by skipping estimates. 
 
2) You can estimate individual tasks, stories, and epics when you need to do that, in order to make budget or go / no-go decisions. In this case, you do a detailed breakdown of the story in quesiton, but you do not need to make detailed estimates for the entire backlog or WIP. 
 
2) All estimating is rough. Many people find that the velocity in terms of number of tickets (even though they are different sizes) is about as accurate as other methods. For example, at Assembla we are consistently completing 100 - 120 tickets per week, of which 40 are bugs and requests added during the week. So, we can finish a net of 60 tickets per week, and if you read down the backlog in chunks of 60, we can get a reasonable idea of when we will get to things that are lower down on the list.

posted @ Friday, August 31, 2012 10:46 AM by Andy Singleton


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: