WIP - Work in...What?

(Germany)

March 19, 2019

Scrum and Kanban are a great combination. With this insight more and more Scrum Teams become aware of terms and phrases used in Kanban. Like 'WIP'.

When I have used this acronym in the past I have read it as 'work in progress'. In his book 'The Goal' Eliyahu M. Goldratt consequently uses 'work in process'. I realized this but didn't give it much thought.

This week, though, I discussed WIP with a colleague and we talked about the difference of 'work in progress' and 'work in process'. And only then I realized that the two phrases mean something completely different.

Work in Progress

progress (n): a forward or onward movement (as to an objective or to a goal)

progress (v): 1. to move forward or 2. to develop to a higher, better, or more advanced stage

— https://www.merriam-webster.com/dictionary/progress

So, progress is good. It describes movement towards a goal and implies improvement. This is what we actually try to achieve in our daily work. We want to make progress towards our Sprint Goals or product vision. We want to improve our way of working together. And we want to make progress in our own understanding of the problem domain and the solutions we create.

If we read WIP as 'work in progress' why would we want to limit it? Wouldn't it be great if we can make more progress by having more work? This is where we should read the acronym in a different way.

Work in Process

process (n): 1. something going on or 2. a series of actions or operations conducing to an end

process (n): to subject to or handle through an established usually routine set of procedures

— https://www.merriam-webster.com/dictionary/process

Process is more fuzzy. If something is going on or we follow a series of actions towards an end something crucial is missing: the direction and the clear goal.

In a business context process often means exactly this: we follow an established set of procedures. Often the different actions and procedures are executed by different persons, departments or even companies. This leads to a process where most of the time work is blocked and waiting to be picked up again.

Conclusion

It is a big difference if we talk about 'work in progress' or 'work in process'. And if we talk about WIP in Scrum or Kanban we are typically concerned with limiting WIP.

By limiting our work in process we are able to improve flow of work through our process an thus increase throughput and decrease cycle time.

Limiting work in progress, on the other hand, doesn't seem to make much sense. If the work really is progressing towards our goal and improving the status quo then this is good.

At Scrum.org we are careful with the terms we use. Names are important as they influence our perception. From now on I will make it a point to use 'work in process' when talking about WIP and limiting it for a Scrum Team.

What did you think about this post?

Share with your network

Comments (3)

Filip Czapeczka

09:43 pm March 21, 2019

Hey, Peter!

Naming is important, but you should remember that if you will have a lot of work in progress you will also have a lot of work in process - this isn't something separate. So not the naming is actually the most important thing here, but real limiting, I'd say :)

Let's have a simpliest example. You have a Development Team of 7 and you start your Sprint. The very first thing they do after planning is starting tasks from 4 different PBI's. They will have a marvelous progress of their work at each day of the Sprint and at the end of it - they wind up with 1 PBI done. The work was in progress so they didn't limit it as you pointed. But behind there was a really lot of work in process which should be limited.

What I'm trying to show is that we should encourage to really limit. Each time I focus on proper naming I lose my and team's energy and time on things that are less important and in this case it is to really limit the amount of work that is currently in the pipe.

Cheers!

GJ Pecover

06:31 pm April 21, 2019

Sorry Peter, not sure I'm entirely with you at the conclusion. Is it the meaning of the acronym or the limiting of work method you want to understand? Scrum does not use the acronym "WIP" so let's not introduce it or talk about it. I think Kanban does, though I've not studied Kanban so happy to be corrected. "WIP" has its origins in accounting and more recently manufacturing. 'Work-in-process', I would venture, has emerged over time where folk simply confuse 'progress' with 'process'. I realise language is fluid with a lot of leeway nowadays over what is and is not acceptable. That said, an essential element of Scrum is its conciseness: 2 artifacts, 3 roles, 5 events. Nothing more, nothing less. Let's keep it that way.

07:50 am January 18, 2021

The Kanban Guide for Scrum Teams (KGST) uses the WIP acronym, and classes it as Work In Progress. It even includes Work In Progress within it's Little's Law chapter, indicating that Little's Law also clarifies it that way.

When dealing with processes, I have always used Work In Process for WIP metric, as the value stream map and other workflow maps provide the direction of flow.

As Kanban and Scrum are both frameworks, and as they both have processes to follow, then Work In Process would be the logical term to use; however, as Kanban uses Work In Progress to identify the work that is actually being done within each stage, this is probably why they chose to use Work In Progress over Work In Process.

From the KGST:

Work in Progress (WIP) refers to the work items the Scrum Team has started but has not yet
finished.

You could argue that both acronym meanings can be used:

- Work In Process metric for process flow measurements in conjunction with other metrics (cycle time & throughput)

- Work In Progress state for visualisng how many PBIs have currently benn puled into each stage (count + work item age)

One can only hope that the PSK exam only uses Work In Progress as Work In Process is not mentioned within the KGST, even though it is mentioned in numerous articles related to this exam.