Work In Progress (WIP) limits
Too many work in progress items is bad for productivity. It delays delivery, feedback and return on investment.
Imagine you have a backlog of three projects or tasks of similar complexity. So you go ahead and schedule each project one at a time. Your schedule will look like this:
Let’s assume a stakeholder or customer shows up and asks about the progress of their project. “Why haven’t you started this other thing” or something along those lines. To be helpful, avoid conflicts or cancellations you start working on the next project, and then the next one after that. Seems simple enough, we establish with the stakeholder that delivery will take a little longer. Now your plan looks like this:
This might give you and stakeholders a feeling that we’re making progress on several fronts, we’re getting more done! Besides, this is similar to how it works on a factory floor where each station has a specific purpose in a delivery line.
Well we didn’t consider the cost of context switching. Every time you switch between projects or tasks you need to reset your brain and learn a new context, dig out the material/code, etc. This takes time. Now if we add context switching between tasks our timeline looks like this:
Now it’s super clear that having several items in progress at the same time is slower than completing them one at a time.
What if we have a team and we want to minimise context switching but deliver on several projects at the same time? Let’s split the team and create several work streams!
Two work streams in progress:
Three work streams:
We eliminated the context switching! But now you don’t have one team, you have two or three, and each group will take 2-3 times longer to deliver anything! Every team member will feel less connected and have less insight into each others work. They will have less possibility to support or share the burden of responsibilities. The project might now depend on one person who feels less connected and may fall ill or leave the company. This won’t create a happy, strong, cooperative or agile team. On top of all this we’re also creating more overhead work!
What if we are ok with the tradeoffs we’ve talked about so far. Stakeholders accept later delivery. The fine for context switching is acceptable. Team fragmentation and morale is ignored.
Then let’s talk about our return on investment and feedback! Every project has some sort of delivery value like cash payment or added user growth. The longer you wait to deliver, the longer you wait for that return, or feedback. If the return compounds over time like interest rate or user growth, shipping early means gaining traction earlier.
ROI for projects in consecutive order
Now we start collecting new users or money after delivering after the first third of the time.
ROI when switching between projects
We won’t collect new users or money until the end of all three projects.
ROI with multiple work streams
Won’t collect anything until everything is completed.
In summary
Of course the real world has a many factors to consider when planning. If you have a big team, it doesn’t make sense to put all of them on a small feature or fixing a bug at the same time. I’ve seen and made this misstake myself in the past, try to avoid it or at least keep a low work in progress limit for your team.
If you limit you or your team’s WIP you will:
- Reduce context switching
- Improve productivity
- Deliver faster
- Get your return on investment or feedback faster
- A more synchronised and supportive team, making it stronger and happier.
Further reading: