Tools for teams: Capacity planning with Kanban

As practitioners and trainers using Kanban, we insist on a few changes in perspective that it requires in order to be effective. One of them is capacity planning.

Kanban, like Scrum, assumes that the capacity of the team 1 is fixed in the short term. This leads to the question: how can we use the current capacity in the most effective way possible? This is where capacity planning is useful, and here’s how to benefit from it.

1. Clarify the different types of work

Any team has to do different types of work.

The typical list for software teams includes features, bugs, documentation, and support. Depending on the characteristics of the product, the list becomes even more varied; for eventrix.co we identified UX design, visible features, and invisible features. There are differences between visible features since some affect only the UI while others require database changes.

Marketing teams have different types of work too: writing messages for social media, writing messages for email marketing, writing content for the blog, creating graphics, monitoring, reporting etc. Since Kanban assumes the capacity of the team doesn’t change in the short term, and since we know that all these types of work are necessary, the next step is clear.

2. Clarify Levels of Service for each type of work

Let’s assume everyone is currently working on new features and a support request arrives in the team. What is the most effective way to deal with it? This is an example of the level of service.

Support requests will be treated with priority. Someone will stop what they are doing and take the support request. An answer has to be provided in less than 24hrs. This is not surprising since most teams use this policy. Let’s look at less obvious situations:

• Everyone is busy, and a crash is found by testers. Do we start fixing it immediately or wait until its turn comes?
• Someone is working on a feature and a bug in the same area is reported. Do they fix the bug too, or just finish the feature
• We have to make changes in the architecture. Will everyone work on that?

Each of these situations, once it appears for the first time, will require a clear policy and level of service.

3. Associate swimlanes with the levels of service

Another name for a swimlane would be a sub-board. Each level of service has its own swim lane, and each swimlane has a different policy and might have a different process.

For example, a software feature tends to have steps like development, review, testing, deployment. But support issues have to go faster through the lane, so they tend to have a smaller number of steps. Some swimlanes have become standard. For example, a swimlane called “expedite” means “something really bad happened and we need to act now”.

But we started from capacity planning, so the next step is to …

4. Allocate a capacity for each swimlane

Since the capacity is fixed, and since we want to use it in the most effective way possible, a decision has to be made on which work is most valuable. Is it more valuable to add new features, x bugs, reduce development costs, solve support issues, prevent support issues etc? The capacity allocation should reject these priorities.

Obviously, the first answer will be “everything is important”. The problem is, when everything is important, nothing is important. Systems, where everything is important, are not as effective as they could, and good management means deciding priorities and strategies.

How can you allocate capacity? Here are a few ways:

• in hours per week
• in number of work items allowed per swimlane 2
• in number of people who can work on the swimlane (e.g. only one developer can do technical improvements at a time) etc.

If you’re just starting, the best way is to measure first or to estimate based on past data. Also, for fundamentally random activities, like expedite issues, it’s best to monitor the time spent and focus on reducing it.

Because the next and the most important step once you’ve planned the capacity is to…

5. Increase capacity / throughput with continuous improvement

Even if Lean / Kanban considers the capacity fixed on short-term, it doesn’t mean the throughout and the capacity should remain fixed on medium / long term. In fact, good Kanban implementations improve their throughput and capacity over time. There are specific ways to do that, so we can directly adapt it in your context through our Kanban workshops.

Need help with capacity planning and / or continuous improvement? Contact us and we’ll be happy to help.