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

[Max Binder]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150818/b16401b9/attachment.html>