“We have to figure out our capacity so we can limit our WIP”. There is a common misconception that you need to know your capacity before you can start limiting WIP (Work in Progress). Let’s clear up the confusion.
Capacity is the amount of work a team can complete as a function of time. Capacity is great for forecasting and budgeting. Capacity changes over time as your team improves.
WIP limits specify how much work a team has in progress at a given point in time. There is no relationship to the amount of work you can do in a timeframe. This is purely a throttle function.
Consider this scenario:
My team’s capacity is 120 features this year. Notice, Capacity doesn’t help you know how many features to work on at a time.
WIP limits could be managed many different ways. Notice the difference in outcome for each option.
120 features in progress all year long, track % done
12 features in parallel per month, delivered monthly
2-3 features worked per week, delivered weekly
1 feature every 2 days.
Can I set my WIP limit without knowing my capacity? Yes! You can gain productivity improvements simply by lowering your WIP. Try cutting it in half. Track the results. Then cut it in half again. Repeat until you see diminishing results.
Note: Make sure you measure productivity results, rather than perception. I guarantee that perception will change, but it may lag behind the actual productivity gains. I recommend you measure something like 1) # of features delivered 2) quality and ultimately 3) revenue or financial benefit. Use this to arm yourself against perceptions such as “I don’t feel like you are working on enough things”, or “The status report doesn’t make us look busy.”
What about resource allocation? How can you limit your WIP when you don’t know if everyone will be busy? “If we only work on 2 features, those features might not use some skills at all, and those people will be sitting there. There will be waste!”
This is local optimization thinking at work. If you have someone work on a low priority item because they are not busy, what happens when they need someone who is working on a higher priority? One of two things happens, either a) the other person won’t help them and they are blocked or b) the other person does help them and slows down the higher priority work. What happens if this lower priority introduces a bug into the higher priority feature? Now both features are delayed.
What do we do with this person whose skills are not needed? This is a great opportunity for them to broaden their skills. Can they pair with a developer with skills that are in demand?
“But I based my capacity forecast on everyone being busy at all times! My plan maximizes efficiency!” What you lose in your “efficiency” you will gain in effectiveness. By narrowing the team’s focus you’ll start to see work finish faster and with higher quality. Reducing rework will buy you the time you are losing by not having everyone busy.
How are you transitioning from Capacity-Thinking to WIP-Thinking? We’d love to hear your thoughts in the comments.
