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:

WIP Limit - Simple project timeline.jpg

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:

WIP Limit - Fragmented project timeline.jpg

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:

WIP Limit - Timelines with context switching.jpg

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:

WIP Limit - Two lanes.jpg

Three work streams:

WIP Limit - Three lanes.jpg

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.

WIP Limit - ROI consecutive projects.jpg

ROI when switching between projects

We won’t collect new users or money until the end of all three projects.

WIP Limit - ROI switching projects.jpg

ROI with multiple work streams

Won’t collect anything until everything is completed.

WIP Limit - ROI three lanes.jpg

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: