Scrum Mastery and Kanban: Part 2 - Limiting WIP (Work in Progress)

Part 2 – Limiting WIP

This article is part two in a six part series towards helping Scrum Masters get better at their craft.

In the first article of this six part series we explored the Kanban practice of visualizing work to help a team gain better insights and make better decisions. The outcome of that article was to provide options to a Scrum Master they could use to help their team visualize their work and expose potential overburdening, unpredictable delivery, or competing priority issues.

In this article we leverage some of those visualization techniques including expanding the “In Progress” column of a traditional Scrum Board, and we now introduce the Kanban practice of limiting Work in Progress (WIP) so a team could use it towards improving their predictability, lead time, efficiency and delivery rates. The goal of this article is therefore to help a Scrum Master learn the value of limiting WIP so they may in turn help their team apply this practice.

When work happens it is still possible no progress is actually being made!  As a result the chosen term is sometimes “Work In Process” instead of “Work In Progress”. For the sake of remaining consistent with familiar taxonomy we will use the term “Work In Progress” in this article.

Why Limit WIP?

Stop Starting, Start Finishing!

A useful reason for setting a WIP limit is because it essentially changes outcomes by affecting the behaviours of team members. Specifically, a WIP limit makes team members focus their efforts on finishing work rather than handing off and leaving existing work unfinished for someone else to deal with. A comparison using two scenarios is provided below.

The first scenario below (see Figure 1) has no imposed WIP limit. Upon completing a work item (say, work item F 8) a typical Scrum team member with personal interests in being a software developer would likely move (push) the work item to Testing. It is then most likely they would start working on the next development task (likely work items F 11 or F 12) rather than tackling a testing task.

Figure 1: No WIP Limits Imposed

Of course, ideally on a Scrum team any team member should be able to do any task, however the reality is most people have domains of expertise they prefer to remain within, and they usually do.

In this scenario, if the team is faster at writing code than testing or documenting then work items would continue to “pile up” or “queue” in the “Testing” column. Since there are no imposed limits this is an “unbounded queue”.

In our second scenario (see Figure 2 below), WIP limit of 3 is imposed on each work type (visualized by the yellow and blue declarations at the top of each column). This means no more than 3 work items of the same type may be happening at the same time.  Note there are other ways to visualize a WIP policy, such as limiting the number of “cards” or “slots” available in a column.

Figure 2: WIP Limit of 3 Imposed on Each Work Type

For other suggestions and options for visualizing work, please see part 1 of this series of articles on Scrum Mastery and Kanban – “Part 1: Visualizing Work“.

Because there are already 3 Testing tasks in process a team member would not be allowed to move (push) their completed work item (F 8) to Testing. The team member would also not be permitted to choose a new coding task from the Design column because of the WIP limit on Coding activities. Their best course of action would be to collaborate to clear Testing tasks from the board (e.g. F 3 or F 4).  Only after testing tasks have been finished and capacity becomes available could the team then move existing Coding tasks forward to Testing. In other words, the team must obey the WIP limits and move (pull) work items towards “done”.

This is what the Kanban term “stop starting and start finishing” stems from.

Of course, other policies may (and should) still be respected. A good example would be someone should not test their own code. We will explore more about policies in the upcoming part 4 of this series that will investigate the Kanban practice of “Making Policies Explicit”.

Provide Focus

By setting a WIP limit you will be changing behaviours and you will also be acknowledging that most people are poor at multitasking. When attempting to resolve multiple complex problems, multitasking can have up to a 40 percent impact on productivity. The outcome of imposing a WIP limit forces team members to focus on the work at hand, reduces the opportunity for multitasking, and therefore helps accelerate the delivery of work items to their conclusion.

For more information on the costs of multitasking, please see the article “Multitasking: Switching Costs” by the American Psychological Association.

Work at a Sustainable Pace

The imposition of a WIP limit also creates a bounded queue which changes the system from being push based (where work is queued up before a team) into pull based (where teams pull work based on their capacity). This approach is especially important for those teams that constantly feel a sense of overburdening and feel they can never get ahead of the work queue before them (i.e. where work piles up faster than the team can deliver). Imposing a WIP limit combats the resulting demotivation and sense of hopelessness such a team would typically feel and often restores a sense of accomplishment and engagement.

Improve Predictability

Queueing theory and Little’s law provide the foundational knowledge for setting WIP limits and creating bounded queues. Work that is done and waiting to be moved to the next process step is considered “queued”. If there is no limit to the number of items that can sit at that stage then you have an unbounded queue, and it becomes difficult if not impossible to predict how long it will take to deliver those work items (given it is infinite). This is especially true if work piles up faster than it can be cleared from a step. Of note – stakeholders and customers don’t typically like unpredictability or poor forecasts, and neither do the teams doing the work.

However, having a bounded queue provides a finite limit to the work that can sit in that state, which creates a predictable system that can be used to forecast from using historical data. Looking at how long it typically has taken to move work items from one step to the next is a core measure within Kanban, and limiting WIP helps create reliable measurements that in turn result in a predictable delivery cadence and ultimately provides a systems view of the work.

Provoke Discussion and Solve Problems

Although the scenario above provides an example how to improve predictability, the imposition of WIP limits will also evoke a discussion and subsequent evaluation of work. Setting a WIP limit will therefore entice collaboration, expose bottlenecks, and identify opportunities for improvement. How the team chooses to respond to the data is equally important, and that is why they and their leaders should also be aligned to the Agile values and principles including experimentation, transparency, and a continuous learning mindset.

Part 2 Conclusion

There are many different ways to set WIP limits, and this article has just explored one option as an example. WIP may be set for stages of work (like in the example above), or it may also be defined for a feature or shared set of work items, for individuals on the team, for an entire team, for a risk dimension, or even for the entire system. Each WIP limit type will be slightly different in how it helps improve predictability and throughput, protect from bottlenecks, and help teams stop starting and start finishing.

In my next article I will focus on the Kanban practice of managing flow in order to create even more system predictability.

If you are interested in learning more about real agility including these and other helpful Kanban practices, principles and techniques I highly recommend you attend a one day Team Kanban Practitioner (TKP) or two day Kanban Systems Design (KMP I) training class in Toronto with BERTEIG. We often see struggling Scrum Teams begin to succeed when they start using Kanban practices such as limiting WIP to help create focus and get their work to the “done” state sooner.

If you find this useful, please consider contributing with our
“Value for Value” model.