Uncharted Waters

Oct 31 2018   12:49PM GMT

Sprints to Kanban

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


For as long as I can remember agile has been synonymous with sprints. To do agile, we had to use some sort of iteration, and today that means a two week sprint. We also had to do the required ceremony and ritual of multi-hour planning meetings where the team commits (aka, gets tired of talking about it and says fine) to how much work they can get done over the next two weeks.

I’ve been asking what if questions lately — what if we don’t have a standup every day, what if we don’t do sprints anymore — to get conversations going around what these things really do for us. The team I’m working with decided to do an experiment to find out an answer to one of those questions. We haven’t done sprints for the past few weeks. Here is how that is working.

The first thing we did, was kill the backlog, or at least redefine it. Prior to doing kanban, we had a months old and months long backlog of changes. We would spend at least an hour at the end of each sprint re-grooming that backlog, re-prioritizing, and deciding what to work on for the next two weeks. Today we use a constantly replenished backlog of 10 cards. Each time a card is pulled into a work stream, a new card is reviewed pulled from the queue into the backlog.


One of the more important parts of changing to kanban is using a Work in Progress (WIP) limit. We don’t allow more than 5 cards in progress at any point in time, and no more than 3 cards in PR. If there are 3 cards in PR, and someone needs to add another, we swarm on the task of reviewing those changes and getting those things ready to go to production. The goal is to remove any potential bottle necks for getting a  code change into production.

So, back to the important question, what was lost by not doing sprints? The main things I can think of are stress, contention, and bottle necks right before the release. Each planning session ended with the question of whether or not we were willing to commit to this amount of work. The implication there is that there is a consequence for not getting everything done. We don’t do that anymore, now that there is no limit on a development flow, there is no need to commit. The stress of committing to work and not getting it done is gone. There is a counter argument, I guess, that we were never forced to commit to anything. But, there is very real social and political pressure to not say no to these things.

Since there is no work batching (2 weeks) we deliver when we feel like it. If a handful of changes are ready to be delivered after a day and a half, we do a push to production. If one change is ready, we can push that, too.

There were questions about metrics and retros initially. Managers want metrics on development to understand how fast on average we can develop software. We still look at metrics at 2 week intervals to get a high level look at what is happening. We are also doing retros every 2 weeks, too.

Overall, I’d say kanban has been a wonderful success. We get all the benefits sprints are supposed to provide, but without the stress and hassle.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: