How to succeed with WIP limits
Introduction
Are you thinking about limiting work in progress in your team? Or have you done so already but are struggling to make it work? Then this article is for you.
As most Agile concepts, limiting work in progress (or just WIP limits for short) is easy enough to understand and explain. On the surface it’s a matter of adding numbers to a few of the columns in your Kanban board, and adhering to them. If only it were so simple. Because what usually happens after you add WIP limits to your JIRA board? Nothing, that’s what.
There’s a lot of work to do before you add the actual limits. Let’s get started!
Understanding the workload
To be able to define limits and understand why they work (or not), we need to understand both the team and their workload.
What is the current Work In Progress?
Count the number of team members, and divide it by the total number of work items (feature, story, or other small deliverable) currently in progress. You will find that the number of work items in progress per person can be anywhere from 3 to 10 and beyond. This baseline will help determine your initial WIP limit. Things like the nature of the work and the average lead time may also play a part in determining the right limit. More on that later.
What about the workload balance?
The number of work items often differ significantly between the team members. Finding one person who have one or two work items in progress, and another who has ten is not uncommon. This can be a sign of any number of things, and needs to be looked into. Here are just a few common reasons:
- You have a hero on the team that are either more knowledgable than the rest, or have just been there the longest. Now he’s ended up as the Go-to person for everything.
- The team has a large demand of a category of work items that only one or a couple of persons can or will handle. This could be due to a narrow spread in competence (lack of T-shaped people), or just poor balancing of work items. To keep WIP down you need a team that is able to collaborate on work items. The good news is that enforcing WIP will also help you build that capability.
- One or more persons on the team have hidden work. The person who seems the least busy on the board may actually be the most busy in real life. For all you know, she spends 80% of her time doing something that isn’t reflected on the board at all.
- You don’t have a backlog or similar single point of entry to your team. Team members accept work items directly from various sources, making it impossible to balance demand.
What do people do when their work is blocked?
This is one of the most common reasons for high WIP, which means it’s also one of the most important ones to address. This is also one of the most common objections to the whole concept. “But what if I’m waiting for someone else, am I supposed to just sit there? This will never work!”
The natural instinct when your current piece of work is blocked, is to start on something else. We need to fight this. You need to sit down with the team and discuss this topic to exhaustion. You need to agree as a team on how to handle situations where work is blocked. And this is (broadly speaking) what you need to agree on:
- Instead of abandoning blocked work, double down to remove the impediment. Need something from someone else? Don’t send an email, pick up the phone. Test environment down again? Help fix the root cause.
- If you can’t remove the blocker yourself, ask for assistance from others in the team, or even outside of the team if necessary.
- If you are still unable to continue with your original work item, do not start a new one. Assist someone else in the team with finishing a work item that is already in progress. If they are doing something you don’t know how to do, this is a perfect opportunity to learn.
- If you absolutely have to start something new, pick something you can finish quickly and that is of low priority. You want to be able to return as quickly as possible to your original work item when it becomes unblocked. The alternative is that when you finally get what you need from whoever was too busy to help you, now you are busy. Then the work item gets delayed even more.
You should also look for handovers. Is the same person responsible for a work item all the way to final delivery? If you have handovers for testing or acceptance, that’s a common cause for blocked or waiting work. Limiting WIP is a great way of challenging such a setup!
Visualise all work
As mentioned earlier, teams often have invisible work. Here are some possible reasons that you need to weed out:
- Certain types of work that are not tracked, like answering support calls or attending sales meetings. This may be okay if we know the rough size of this demand. If it is variable in nature, we need to understand that this may reduce our predictability.
- Individual persons may have special work in addition to their team duties. This could be due to historical reasons or special competence they have which means they are often called upon to assist. There may be various reasons why they haven’t tracked it on the board. It could be political reasons for “hiding” it, or maybe they just haven’t thought about it, or not even realized how much of their time goes into it.
- Some individuals don’t visualise their work because the team isn’t actually working as a team. If you do all the work yourself without collaborating, it’s hard to see the benefit of visualising it for others. It seems like a waste of time.
- Work is visualised but at the wrong level. You see work items that don’t move for weeks because they’re not granular enough, hiding the true nature and complexity of the work behind a single work item.
Figuring all this out takes time and hard work. If you are coming in to assist from the outside, you will need to gain the trust of the team before you get to the bottom of this. But you have to keep at it until you have visualised as much of the work as possible on the board. Whatever left outside the board must at least be known, so that you understand your true capacity as a team.
An obvious smell is when you see a work item that should take three days, go on for weeks. If a person is focusing on a small number of work items, and everything is on the board, where is that extra time going? Take care to be open and curious (and not accusing) when investigating.
When is it okay to break the limits?
A common reason why WIP limits don’t stick, is that you haven’t agreed how it is supposed to work. At some point someone will face a maxed out limit. Then what happens? Are they not allowed to break it, no matter what? If so, when is it okay? A helpful tool is Classes of Service. Connecting policies to classes of service or types of work items is an easy way to govern how this should work in practice. An example would be to always ignore limits when there are production problems. If you don’t agree on these things as a team up front, this will never work.
Down the road it’s also a good idea to spend some time understanding why limits are broken. If the limits are reasonable, this shouldn’t happen too often, so why did it happen? Was it a special cause, a symptom of some systemic problem, or an indication that the limits are wrong?
Explain what is happening to your customer(s)
If this is going to work, your team can no longer accept requests when they are at capacity. This mean we will introduce a new word into the team vocabulary. This word is “No”. Most teams are unconvinced when you explain this concept to them. Stakeholders are even less impressed.
You may have to explain the basics of queue theory to both the team and their stakeholders. This will not convince them, but at least it will sound sciency, and make it a bit harder to object.
Customers take two: Introducing options and consequences
After failing to introduce the concept of “No” above, try this: Explain how we will now limit the number of work items we will work on in parallel. Instead of accepting all requests, we will only be interested in the most important and / or the most urgent work items. The question to our customer should be “What is most important to you right now?” and the answer should be their five most important things, not their fifty most important things.
If they change their mind, that is fine, but they then have to pick something we haven’t started yet, and remove it. If something new is the most important thing, by definition something else must now be less important.
End of part 1
Finally! We’ve done a lot of grunt work, but trust me, it’s worth it. If you’ve done all of the above, you have a good starting point to apply sensible WIP limits. You will also have a much better chance of understanding why the team is unable to stay within the limits (which is almost bound to happen).
Unless you need a coffee break, head over to part 2 of this article, where we’ll start limiting WIP!
Thanks to Mike Burrows and Christina Kjær Seime for input on the first draft.
