[teampractices] [Discussion] WIP limits: story points vs task count

[Kevin Smith]

I'm no expert on WIP limits, but I have some thoughts:

The point of a WIP limit is to pressure the team slightly to take on less
new work before finishing their work in progress. If the limit is set too
high, there is no pressure, and WIP can build up. That might not be bad in
itself, but high WIP can indicate that the team is probably doing a lot of
context switching (wasteful), and/or that partially-completed work will
"rot", and then have to be reworked before it can be finished. Limiting WIP
is a means to an end, and is not itself the actual goal.

One big factor in setting your WIP limit is whether you include "blocked"
tasks in it or not. If tasks get stalled waiting for other teams, it can
make sense to take on other work while waiting, and thus a higher WIP limit
would be reasonable. If blocked tasks get moved to a different column, then
the WIP limit should remain lower, to avoid having too much work actually
in progress at once.

In Kanban terms, limiting WIP and reducing batch size are two sides of the
same coin. If you aggressively reduce your batch size, then several of the
problems mentioned in the question are mitigated. If all of your tasks have
a narrow range of point estimates, then their sum will approximate a task
count. Having large tasks in your sprint backlog is seen by some (not all)
as an anti-pattern.

Another thought is that the WIP limit is a warning, not a blocker. If the
team ends up with 11 points of work in a column with a limit of 10, the sky
won't fall. The limit will light up red, indicating that something is
"off". And in this case, I would argue that's exactly the right thing. The
team is alerted, and can decide whether or not going to 11 in this
situation is healthy or unhealthy.

I know those were just sample numbers, but in a real-world case, if there
are 3 developers, and tasks are typically 2-5 points, then I would expect
the WIP limit to be more like 15-20, rather than 10. That also relates to
the concern that the WIP limit has to be at least as big as the largest
task.

On the other hand, I would argue that whatever WIP limit is appropriate for
this team, the largest task should probably be split until it "fits"
nicely. In a single-developer project, I would personally say that no task
should be more than 50% of the WIP limit. On a 4-developer team, I would
say it should be no more than 20% of the WIP limit. Disclaimer: I strongly
prefer very fine-grained user stories (which rarely need to be split into
engineering tasks).

The last concern, that a 10-point WIP limit would allow 10 1-point stories,
is true. That goes back to favoring stories that have a narrow range of
point values. But I think it also raises the point that the WIP limit is
more of a backstop than a primary tool. Developers should already be
getting into the habit of finishing work before taking on more work,
whether or not a red light is blinking. The WIP limit should only kick in
when they forget, or when odd circumstances arise. Even if the WIP limit
fails to trigger due to [math], anyone on the team could notice that too
much work/too many tasks are in progress, and guide the team to make
corrections.



Kevin Smith
Agile Coach, Wikimedia Foundation


On Tue, Aug 18, 2015 at 1:48 PM, Max Binder <mbinder at wikimedia.org> wrote:

> I've engaged in some debate lately as to the proper use of WIP limits, and
> have seen 2 ways they are used at the foundation:
>
>    1. A column is limited by the number of cards that can be put into it
>    2. A column is limited by the amount of story points it can hold
>
> *TL;DR: Are there strong thoughts on how to use WIP most effectively,
> given the above?*
>
> My understanding is, in typical best practices, WIP limits are reflected
> using Method 1, especially on a Kanban board (which typically does not use
> story points anyway).
>
> At WMF we use Phabricator, and Phabricator marks the column red if the
> limit is exceeded. However, Phab also automatically counts story points in
> a column, *rather* than individual tasks, if the board is marked as "Is
> Sprint" and the tasks are estimated. So, if a board that measures story
> points has a WIP limit of, say 10, then a team could have tasks of adding
> up to 10 points (for ex: a 2, a 5, and a 3).
>
> The problem I see with the above example is that a WIP limit based on
> points can hurt working capacity, in multiple ways. Here are a few:
>
>    1. A team can't always maximize it's WIP. If the limit is 10 points,
>    and there are tasks of 5 and 3 points being worked on, and the only thing
>    left in the backlog are 3 and 5 pointers, then there are 2 points of
>    "wasted" capacity.
>    2. A WIP must be able to fit the largest possible task, so you if your
>    biggest tasks are, say, 5 points, your WIP must be at least 5. What if most
>    of your points are 3's? 1's?
>    3. A team could have, in this instance, ten, 1-point tasks happening
>    all at once, which defeats the purpose of *limiting *work-in-progress.
>
> All that said, I know some folks have not explicitly ruled out measuring
> WIP by story points (Phab is certainly OK with it).
>
> I would love to hear debate one way or another.
>
> Max
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150820/45beddf0/attachment.html>