Limit WIP doesn't mean doing less

· March 26, 2013

I’m having the opportunity to coach in an organization that isn’t used to agile practices. This is very refreshing and they are constantly challenging me and the ways that I think for granted. Quite often I find myself stumbling to explain practices that I for so long just have assumed that everyone was doing.

A couple of days ago I stumbled upon one of those. Here’s the dialogue that played out (as I remember it at least): Me: You are doing a lot of things at once here… Appointed Product Owner: Yes. But there’s a lot of things that we have promised them to finish by [date] Me: But why don’t you limit your work in process then? That will get stuff done faster and .. PO: Whatever do you mean? We cannot just limit the work. This [pointing to board] is what we are supposed to have done. We better do it now. As fast as we can.

There’s two things that I have missed to explain here; the use of WIP (what is it good for) and why they (the stakeholders) shouldn’t and probably doesn’t care about your WIP.

First; what is a WIP (work in process) limit? For me it’s a team agreement on how much work we take on a given time. It’s not pushed upon us from the outside and we can change it and break it if we see the need or use for it.

In Scrum a very important aspect of the sprint work load is that the team takes on how much work they think they’ll manage with the next sprint. This is done to balance the workload for the team and also, since the team takes on the work, you enforce a sense of commitment to the work you have taken on. If, during the sprint, new work appear we, as a team, could decide to take that on and hence stand the risk to not complete the backlog of work we took on for the sprint. Or we could talk to the product owner and say that we wont manage the new work as well as the sprint backlog. Could she please help us prioritize between these?

WIP limits serves the same purpose. We limit the amount of work that we take on (per stage in our process or totally in our process or what have you). It’s an working agreement that we have decided (as we do with sprint backlogs).

If new work should appear that would make us break our WIP-limit we need to have a discussion. This is really what a WIP-limit is; a trigger for a discussion. law](<>'s_law) tells us that the more work we do, the slower each work item will take. Bringing on new work will in other words slow down the progress on all work a little bit. Are we willing to pay that "toll"? Is the "toll" so small that we feel that we can make this decision on our own?
we're doing. To quote [David J. Andersson]( (as I remember it) > "Kanban allows you to become a Yes-man. You can always say 'Yes'. > 'Yes - we'll take this on - what should we stop doing?" Finally - with less work in process the work will flow faster, according to [Little's law]('s_law). That is - you will do less work at the same time but every work item will go faster. This in turn gives us feedback on our work and helps us improve. We get more decision points and can become more nimble and agile in our business. We can prioritize work that give us more business value or quick-wins, first for example. Finally, if you try games like [Pass the pennies](, you'll see that the total time for all work will also go down. Just by doing less work at the same time. Working the exact same way with your work items, but taking fewer of them on at the same time. To recap; WIP limits are triggers for discussions. We put them in there to make the work flow more even and faster. And to not overload people with work. ### Limit WIP doesn't mean less work done After that first point (yes, there's "First" waaay up there...) let's turn our attention to limiting WIP. Limiting WIP means that we decide a limit of the number of items that we work on **at the same time.** It's a team thing and doesn't say; we will do fewer items in total. Again - we use the tool limiting WIP to help the work that we're actually are working on to flow faster, and to manage more items in as I mentioned above. It shows, very clearly, that with less work in process (at the same time) you not only finish each item faster but also the total time for all the work you do is lower. Finally - this is a team internal practice. It's the way that the factory that we're constituting is operating. We pick a limited number of items and try to complete them before starting anything new. That's our aim. We don't always succeed on sticking to it, but we try, since we When we feel the need of breaking the limit we have a discussion on why and the benefits versus the cost of taking on more work. All we really want is to make informed decisions. We can decide to slow the system down for a while, in favor of expediting another critical item, for example. In that regard the stakeholder outside the team is probably not interested in WIP limits. Just like I don't care how the internals of a computer works. As long as it works and does it's job I really do not want to know about the inner workings. ### Conclusion This was a really long way of saying; WIP limits are not fast rules, they are triggers for discussions. We use them to improve the flow through the system. Limiting WIP does NOT mean that your doing less work in total. Just that you're doing less work at the same time. (outside the team) doesn't even care. They want features, as fast as possible with great quality.  

Twitter, Facebook