Recreating Scrum using Kanban and Explicit Policies

This afternoon I was teaching a public class on Lean-Agile principles and practices, and a question came up about the differences between Scrum and Kanban. As a fun exercise, I recreated Scrum using Kanban coupled with a set of Explicit Policies.

To briefly summarize the differences, Scrum is a methodology which consists at its core a "three of threes" – three roles (ScrumMaster, Product Owner, and Team), three meetings (Daily Standup, Iteration Planning, Sprint Demonstration), and three artifacts (Product Backlog, Sprint Backlog, and a Burndown Chart). In short, the Product Owner has a prioritized backlog (Product Backlog) of work that she wants done for the product, or for the next release. The team meets with the Product Owner (Iteration Planning) to commit to a subset of that work they’ll spend the next fixed-length period of time (Sprint) working on. The stories committed to become the Sprint Backlog. In addition, the stories are estimated using Story Points, and the team can not commit to completing more stories than what their Velocity is (the number of Story Points they can complete, on average, during a Sprint).

Kanban, on the other hand, is a continuous flow model. It also starts with a prioritized backlog, but does not define who the owner of that backlog is (though we highly recommend it being a Product Champion, who has the authority to make change in items and priority). The team pulls work from the backlog as they have capacity, working on the story until it is finished. They then pull the next most important story from the backlog, and repeat.

The team in Kanban limits the amount of work they pull in based on Work in Process limits. These are explicit limits, set by the team, of how much work they can have flowing through the system at one time. Forecasting of how much more time is left is done using Average Cycle Time (though there are other ways, as I wrote about recently). Outside of that, Kanban doesn’t set how often the owner of the backlog needs to prioritize the work (as long as there is work ready to be pulled when the team needs it) nor does it define when work will be demonstrated for the customer. This doesn’t mean that it isn’t important – in fact, it is critical. However, the way it is done is, again, through Explicit Policies – the team makes a decision of how often they want to meet with the backlog owner, and how often they want to demonstrate the work completed. They then publicize that decision as a policy.

It’s through the use of these policies that we can recreate Scrum using only Kanban. The key is defining the right set of explicit policies to make it all work.

 

Time

Let’s start first with the time aspect. We’ll assume we’re using two weeks as our sprint length throughout the rest of this article. If our sprint length is indeed two weeks, we are saying, from a Scrum perspective, the following:

• We have an input cadence of two weeks. This means that every two weeks the Product Owner will have a chance to reprioritize what the team is working on.
• We have an output cadence of two weeks. This means that every two weeks, the Product Owner will have a chance to see the work that has been completed
• Assuming we are doing retrospectives, we have a retrospective cadence of two weeks, which is how often we’ll meet to reflect on our work and our process.

Each of these items are, in fact, implicit policies we take on by using Scrum and by setting our Sprint length. So, recreating these in Kanban is fairly straightforward:

• We set an explicit policy that every two weeks we’ll meet with the backlog owner to update the backlog and make sure we have enough work loaded for the team. This sets our input cadence. Note that the normal policy in Kanban is that if work hasn’t been started, it can be reprioritized at any time, so what we’re really setting here is a meeting cadence.
• We then set an explicit policy that every two weeks we’ll meet and demonstrate whatever is in the done column. This is our output cadence.
• Finally, we set an explicit policy that we will meet every two weeks to reflect on our work in process, setting our retrospective cadence.

Well, that was easy! What’s next?

 

Velocity

One of the key ways we limit work in progress in Scrum is through the use of velocity. Knowing the average number of story points a team can complete in a two week period accomplishes two things:

1. We are able to forecast out how much longer we have before we are finished with what is in the product backlog
2. We are able to limit how much work we pull in based on what is presumed to be our capacity for work

To recreate this in Kanban, we’ll need to do the following:

• First, the stories will need to be estimated using Story Points. Pretty straightforward, since that is what Scrum does
• We set an explicit policy that every two weeks we will sum the story points in the done column, and call that our velocity

So, now we have our velocity, but it isn’t quite satisfying. After all, part of what we use velocity for in Scrum is to limit the amount of work we have in progress. So what should we do with the number here?

If we go back to the concept of WIP Limits in Kanban, they are usually applied at the column level. Also, WIP limits are traditionally defined as limiting the number of stories that can be in play at one time – not the size of stories that can be in play. However, there’s nothing saying we have to stick with that – after all, these are our policies!

So, we set a WIP limit on the Backlog column of our Kanban board that is equal to the velocity calculation we just used. The WIP limit here would actually be based on Story points, not story counting, so sometimes we might have 3 stories, and sometimes we might have 9 in the column, depending on their size.

At this point, we now have a Kanban board with an input cadence of two weeks, an output cadence of two weeks, a limit on the backlog column based on how many story points were in the done column after two weeks, and a retrospective cadence of two weeks. Pretty close!

At this point in the class, one of my students pointed out that, while we are close to Scrum, we’re missing the ability that the product owner know that the stories started at the beginning of the two week period are going to be the ones demonstrated at the end. This leads to our third section.

 

Commitment

In Scrum the team is committing to the work in the Sprint Backlog. To make sure that goes well, we generally recommend teams don’t pull in stories above a certain size. For example, teams using a Fibonacci sequence may not commit to stories which are larger than 5 Story Points, because of the uncertainty involved. This is challenging, because we don’t really have a way of setting explicit policies around commitment models, but perhaps we can do something to improve the odds that a story entering the backlog will be demonstrated in two weeks.

To do that, we can do one of two things (or both):

1. We set an explicit policy that stories entering the board have a Service Level Agreement of being completed in two weeks or less. This may impact the way work is pulled across the board.
2. We set an explicit policy of entrance criteria which prohibits stories that have an average cycle time greater than some threshold – say 5-8 days. This can be done by sizing the stories using something like T-Shirt sizes (XS, S, M, L, XL) then calculating the average cycle time for each size. You can see my post on estimating in Kanban for more information.

With those in place, we can’t guarantee the work will be demonstrated, but we can come close into a high confidence level that the work will be ready by the next demonstration.

 

Summary

Now, of course, this is all a bit silly. But, it does raise a very critical point. Explicit Policies in Kanban are the magic sauce to a successful implementation. It’s also important to note that the policies need to be owned by the team. That way, even if they did set all of the above policies, they had the ability to change the ones that weren’t working for them.

Both Kanban and Scrum are rather interesting methodologies that can be applied to various teams. But no matter which you choose, the team should own the methodology and the implementation so that they can make it work for them. Every team and every implementation is different. The key is that when your team differs, make it explicit what it is your team does and why – and reflect regularly on it.