<div dir="ltr"><div><div><div><div><div>I'm no expert on WIP limits, but I have some thoughts:<br><br></div>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. <br><br></div>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. <br><br></div>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. <br><br></div>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. <br><br>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. <br><br>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). <br><br></div>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. <br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Aug 18, 2015 at 1:48 PM, Max Binder <span dir="ltr"><<a href="mailto:mbinder@wikimedia.org" target="_blank">mbinder@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<br><ol><li>A column is limited by the number of cards that can be put into it</li><li>A column is limited by the amount of story points it can hold</li></ol><p><b>TL;DR: Are there strong thoughts on how to use WIP most effectively, given the above?</b><br></p><p>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). <br></p><p>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, <i>rather</i> 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).</p><p>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:</p><ol><li>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.<br></li><li>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?<br></li><li>A team could have, in this instance, ten, 1-point tasks happening all at once, which defeats the purpose of <i>limiting </i>work-in-progress.</li></ol><p>All that said, I know some folks have not explicitly ruled out measuring WIP by story points (Phab is certainly OK with it).</p><p>I would love to hear debate one way or another.</p><span class="HOEnZb"><font color="#888888"><p>Max<br></p></font></span></div>
<br>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>