馃攳
Kanban WIP limits - Agile Coach (2019) - YouTube
Channel: Atlassian
[4]
A work-in-progress, or WIP limit,
[6]
is any mechanism designed
to help your team
[9]
limit the number of items
you're working on concurrently.
[13]
The idea is that the fewer
items being worked on,
[16]
the faster those selected items get done.
[19]
And that's kind the interesting part,
[21]
actually by limiting work in progress,
[23]
you're going to end up getting
more work done over time.
[26]
I'm Max, a product marketing
manager on JIRA Cloud,
[29]
and WIP limits are a life saver for me,
[32]
because I always want to
say yes to new projects.
[35]
When I have a WIP limit, I
have a great excuse to say no.
[40]
Now my goal for this video is to share
[42]
how WIP limits are much more
than an excuse to say no.
[45]
And I want to do that
through a demonstration.
[47]
First, I just want to remind
you to subscribe to our channel
[50]
for a full conversation about Kanban,
[52]
more than just the WIP limits
we're talking about today.
[55]
Now, let's get into the demonstration.
[61]
I'm here with Sasha.
[62]
Sasha's a valued member
of our development team
[63]
as a designer.
[67]
Sasha's known for getting stuff done.
[69]
If you have something for Sasha
to do, he can get it done.
[75]
Even sometimes, two things at a time.
[79]
Easy.
[80]
Let's say things are
getting a little chaotic,
[83]
have three things at a time.
[88]
He's able to catch two.
[90]
Let's see what happens
[90]
when you don't limit work in progress.
[97]
All right, so Sasha was able to catch one
[100]
of the many many many things
[102]
that we had to do.
[105]
Now this is an exercise I've
seen play out so many times.
[108]
The less you limit work in progress,
[110]
the less you're able to actually get done.
[113]
So this is a visual demonstration
[114]
of why we should use
work in progress limits.
[117]
That was fun, thanks.
[123]
So there are no hard and fast rules
[124]
for how to set a WIP limit
for your Kanban team.
[127]
But I would recommend
starting with something
[129]
that remains relatively constant,
[131]
which is your team size,
[133]
the number of people
contributing on your board.
[135]
You can that that number and
multiply it by 1.5 or two,
[139]
and that will be your overall WIP limit
[141]
for all projects in progress
on your Kanban board.
[145]
But, let's say you have specialists
[147]
that look after specific
columns in the workflow.
[150]
That means you have to
do something little extra
[152]
which is what we'll cover next.
[158]
So let's say you have a workflow like
[160]
design, develop, test, and done.
[163]
And let's say you have two designers,
[165]
three developers, and just one tester.
[168]
You would take the number of people
[170]
that look after each
stage in your workflow
[173]
and you multiply that by two.
[175]
So your WIP limit would
be four for design,
[178]
six for develop, and two for testing.
[181]
Once you've arrived at a WIP limit,
[183]
it's time to add it to your board.
[185]
If you're on a physical board like this,
[186]
it can be super easy.
[188]
It's as easy as adding it to your columns,
[191]
so four for design, six for
develop, and two for test.
[195]
You can also go a step further,
[197]
and this is what I would recommend,
[198]
which is to actually limit your columns.
[201]
So testing we can only fit two cards,
[204]
so let's block it off, let's cross it out,
[207]
and then it becomes super clear.
[209]
If there are only two cards in testing,
[212]
you're at your WIP limit,
[213]
and if you want to bring another card in,
[215]
you actually can't fit it.
[217]
That's how I'd recommend to
do it on physical boards.
[220]
On digital boards, it's even easier.
[222]
I have JIRA Software Cloud in front of me
[225]
and I can add WIP limits
directly to the board.
[228]
Let's set a WIP limit of two for doing,
[232]
which I can reach with
one additional card,
[235]
and I will break at three.
[240]
So now you have WIP
limits, that's awesome.
[243]
What are some goals that
you should work towards?
[245]
First, decrease your lead time.
[248]
Lead time is the amount of time it takes
[250]
from when you start working on
a project, to when it's done.
[254]
When you limit work in progress,
[256]
your lead time should go down,
[258]
cards should move faster
from in progress to done.
[261]
That's an awesome outcome,
so look forward to that.
[264]
Your second goal should
be to map your WIP limits
[267]
to your team's specific skills.
[270]
We have a global WIP limit
thanks to our exercise earlier
[273]
but we mentioned how there
are specialists on your teams
[276]
like designers or testers.
[278]
You want to really dig
into those specific skills
[281]
and map your team's WIP
limit to match them.
[285]
Another opportunity is to start teaching
[287]
other team members skills
like design and testing.
[290]
That way you can increase
that specialist WIP limit,
[293]
and move work through
your workflow faster.
[297]
The third goal is to reduce idleness.
[300]
When a team member has downtime,
[302]
they can move upstream or
downstream in the workflow
[304]
and help out other team members.
[306]
This is one of the most
awesome things you can get
[308]
out of your WIP limits.
[309]
These team members can
jump into blocked work
[312]
and move those cards forward.
[313]
The last goal of setting up WIP limits
[316]
should be to protect a
healthy engineering culture.
[319]
You might think that WIP limits mean
[321]
that developers need to
work fast to get work done,
[324]
but it's actually the opposite.
[326]
Because developers can focus
on a smaller amount of tasks,
[330]
they'll be able to make better products
[331]
and have a healthier code base,
[333]
and be a healthier team overall.
Most Recent Videos:
You can go back to the homepage right here: Homepage