Unrecognized Escape Sequence

The TLDR

My team has recently been experimenting with various WIP (work in progress) limits. Actually we brought in the idea maybe a year ago, but I’ve only recently had some time to write about it with some hindsight.

You can read on for quite a lot of (possibly uninteresting) detail, but the TLDR is that a WIP limit is a very valuable tool, which I would recommend any established Scrum team give a try. This is not only for the advertised purpose of the limit, but also for a variety of other potential benefits and at very least to see what it tells you about your team’s throughput and focus.

Note: my experience of this is limited to Scrum sprints, however I’m sure many of the points are relevant to kanban and other approaches to work management.

The problem

Something most agile teams will have seen is work items getting stuck or abandoned part-way across the board. For example this might happen because the team member who was driving that item goes on leave without notice. Once this happens, there is now a friction to other members of the team picking up this work to try and complete it.

My experience is that developers tend to mentally assign ownership of a task to whoever worked on it last, despite all the lip service we give to team ownership and joint responsibility as agile practitioners. And once a task has been abandoned part-way through, no one else wants the uncertainty and extra baggage of taking over where they left-off. And it’s relatable right? I mean who knows what awful state it might be in? At very least someone is going to have to figure out where they got to and fill in the rest. The result of this is that people will do what they can to avoid this friction, usually picking up new work from the Pending column instead.

The term friction applies in two ways here, because this behaviour also represents a problem for the smooth running of a sprint. In the Big Picture™ we want work moving across the board and being completed as soon as possible, ideally in priorty order. This is what provides our MVPs, unblocks other pieces of work, and makes us look good in showcases and retros, even if we don’t complete the sprint. Avoiding abandoned work items doesn’t really contribute towards this goal. At best it moves lower priority work towards completion which is useful but not optimal.

The fix in theory…

The idea of a WIP limit is to try and ensure that:

• Higher priority work items in the sprint are completed as soon as possible, irrespective of who is involved and how this happens.
• We have a device in our process so we notice when a task is taking a long time to move across the board, or has become stuck or abandoned.

In concrete terms, from the time a work item is started, until it is completed, we say it contributes to WIP, and then we ensure that the count of those items is limited to a fixed number agreed in sprint planning. This limit is typically something like the number of individuals or pairs in the sprint, or maybe a little higher to allow some wiggle room.

If we return to the scenario described in our Problem section above, with a WIP limit the behaviour should be different. The team member looking for new work recognises that they cannot bring a new item into WIP because of the limit, and so instead of picking up something new they return to looking at the highest priority item that is not complete and is not being progressed - if necessary picking this up from where it was dropped, or at least investigating its status.

There are legitimate reasons why a developer or pair might have more than one item in progress at a time, but it’s questionable. For example, if many tasks in a sprint require some long validation or release pipeline, then perhaps once they move to this state tasks should not contribute to WIP and should be moved to a new column while this happens. But this has its own drawbacks as if the pipeline fails unexpectedly, what happens now? Does it come straight back into WIP? How this kind of situation is handled is likely specific to the team; there is a trade-off between trying to maximise developer productivity and getting higher priority items over the line.

…and in practice

At the outset, I viewed the WIP limit as a guiding tool, but in fact I think it’s just as important as a measuring or monitoring tool. For our team, using a WIP limit allowed us to see more clearly a variety of incidental problems we hadn’t really noticed before.

When we first established the WIP limit, there were a lot of breaches. Engineers like to have some scope for selecting the piece of work they pick up and will bend the rules to take on more interesting or lower-hanging items. But over time this became less prevalent as the team realised they would have to answer for breaking the WIP limit in stand-up meetings. My advice would certainly to be very strict on sticking to the WIP limit, at least to start, until the team can agree on what potential caveats there should be (if any).

There are a variety of reasons why someone might want to breach the limit, many in a grey area in terms of their justifiability. Most common among these is that responsble engineers commited to sprint goals don’t want to be twiddling their thumbs. But if the team is at the WIP limit, then the default action is of course not to do nothing, but rather to find another way to contribute. If all WIP items are being progressed or as progressed as they can be, then as a last resort engineers should be encouraged to pair up with others, especially less experienced colleagues. As we use pairing for most work, this sometimes results in mobbing (a topic for another day) with three or enve four engineers working on a task. Often this leads to innovative ways to break that task down to break up the mob and make better progress in the sprint.

Conclusions

For the benefits that I discuss above, I stick to my original assertion that a WIP limit is worth trying. It is another piece of process that some teams may find an obstruction or point of contention; however there are a few additional reasons I’d offer to give it a try. I found that one of the principle benefits of having a WIP limit is that it encourages our team members individually to be more conscious of the state of the sprint as a whole; to be looking beyond just the Pending column and thinking more about the trajectory of the sprint.

Another real but unexpected benefit of introducing the WIP limit was it really brought into focus they way in which we as engineers were thinking about unfinished work. Rather than considering it a hypothetical situation, if you fully expect another member of the sprint to be picking up work that you have started (and vice-versa) then you pay more attention to things like developer documentation, writing tests first, making frequent and small commits, merge/pull request descriptions. All things that we as a team agreed were good practices in general.

Finally yet another benefit we found is that the WIP limit is a real help in flushing out sprint problems - people were much more likely to recognise and help out on work that ran long and was likely underestimated, or jump in to help a junior colleague who had become stuck but was worried about admitting it. These kinds of problems have a habit of becoming a single person’s problem, when it makes sense to recognise that they are team/sprint problems.