A work-in-progress, or WIP limit,
is any mechanism designed to help your team
limit the number of items you're working on concurrently.
The idea is that the fewer items being worked on,
the faster those selected items get done.
And that's kind the interesting part,
actually by limiting work in progress,
you're going to end up getting more work done over time.
I'm Max, a product marketing manager on JIRA Cloud,
and WIP limits are a life saver for me,
because I always want to say yes to new projects.
When I have a WIP limit, I have a great excuse to say no.
Now my goal for this video is to share
how WIP limits are much more than an excuse to say no.
And I want to do that through a demonstration.
First, I just want to remind you to subscribe to our channel
for a full conversation about Kanban,
more than just the WIP limits we're talking about today.
Now, let's get into the demonstration.
I'm here with Sasha.
Sasha's a valued member of our development team
as a designer.
Sasha's known for getting stuff done.
If you have something for Sasha to do, he can get it done.
Even sometimes, two things at a time.
Easy.
Let's say things are getting a little chaotic,
have three things at a time.
He's able to catch two.
Let's see what happens
when you don't limit work in progress.
All right, so Sasha was able to catch one
of the many many many things
that we had to do.
Now this is an exercise I've seen play out so many times.
The less you limit work in progress,
the less you're able to actually get done.
So this is a visual demonstration
of why we should use work in progress limits.
That was fun, thanks.
So there are no hard and fast rules
for how to set a WIP limit for your Kanban team.
But I would recommend starting with something
that remains relatively constant,
which is your team size,
the number of people contributing on your board.
You can that that number and multiply it by 1.5 or two,
and that will be your overall WIP limit
for all projects in progress on your Kanban board.
But, let's say you have specialists
that look after specific columns in the workflow.
That means you have to do something little extra
which is what we'll cover next.
So let's say you have a workflow like
design, develop, test, and done.
And let's say you have two designers,
three developers, and just one tester.
You would take the number of people
that look after each stage in your workflow
and you multiply that by two.
So your WIP limit would be four for design,
six for develop, and two for testing.
Once you've arrived at a WIP limit,
it's time to add it to your board.
If you're on a physical board like this,
it can be super easy.
It's as easy as adding it to your columns,
so four for design, six for develop, and two for test.
You can also go a step further,
and this is what I would recommend,
which is to actually limit your columns.
So testing we can only fit two cards,
so let's block it off, let's cross it out,
and then it becomes super clear.
If there are only two cards in testing,
you're at your WIP limit,
and if you want to bring another card in,
you actually can't fit it.
That's how I'd recommend to do it on physical boards.
On digital boards, it's even easier.
I have JIRA Software Cloud in front of me
and I can add WIP limits directly to the board.
Let's set a WIP limit of two for doing,
which I can reach with one additional card,
and I will break at three.
So now you have WIP limits, that's awesome.
What are some goals that you should work towards?
First, decrease your lead time.
Lead time is the amount of time it takes
from when you start working on a project, to when it's done.
When you limit work in progress,
your lead time should go down,
cards should move faster from in progress to done.
That's an awesome outcome, so look forward to that.
Your second goal should be to map your WIP limits
to your team's specific skills.
We have a global WIP limit thanks to our exercise earlier
but we mentioned how there are specialists on your teams
like designers or testers.
You want to really dig into those specific skills
and map your team's WIP limit to match them.
Another opportunity is to start teaching
other team members skills like design and testing.
That way you can increase that specialist WIP limit,
and move work through your workflow faster.
The third goal is to reduce idleness.
When a team member has downtime,
they can move upstream or downstream in the workflow
and help out other team members.
This is one of the most awesome things you can get
out of your WIP limits.
These team members can jump into blocked work
and move those cards forward.
The last goal of setting up WIP limits
should be to protect a healthy engineering culture.
You might think that WIP limits mean
that developers need to work fast to get work done,
but it's actually the opposite.
Because developers can focus on a smaller amount of tasks,
they'll be able to make better products
and have a healthier code base,
and be a healthier team overall.