I have read that Work in Progress should be minimized, or that WIP amount doesn't matter as long as sprint is being finished.

But I am not sure how we define the WIP, specifically how large the WIP items have to be.

Am I right that it stems from the Sprint workflow, where each sprint contains N number of tasks / user stories or whatever (deliverables), and each tasks is single item of WIP. Then, because we are time-boxing the sprint, the WIP item size will automatically fit into some number of hours?

Here is an example of defining WIP item:

  • Bad: analyze all data from 01/2019 to 01/2020
  • Good: analyze datasets #1, 2, 3, 4, and 5, extracting metrics A, B, and C for each dataset

This way, when using "Good" definition, even though WIP item is still pretty large, we can judge post-hoc, how reasonably it was sized. E.g. we can end up with 75% "Done", whereas in the first case we end up with either 0% or 100%.

PS: part of the reason I am asking is confusion, but also I would like to have a canonical definition

  • You have tagged the question as kanban, but in the question you are referring to sprints. Kanban is a continuous flow method and doesn't have the concept of a sprint. Sprints come from Scrum, but that doesn't really have the notion of WIP although it does know about work-items (called backlog items). Commented Jan 25, 2020 at 17:43
  • That's a good observation. Let's point out that some teams blend Kanban and Scrum into "Scrumban". So they take the sprints and Scrum roles and focus on work in progress limits and cycle time from Kanban. Commented Jan 26, 2020 at 18:29
  • It is essential to find the local minima and maxima while conducting work in progress. This will lead to the best solution resulting from the data set Commented Feb 1, 2020 at 2:10

2 Answers 2


To contribute and also help move the discussion forward, let's first start with the definition of WIP:

WIP is the number of task items that a team is currently working on.

When rolling out a new workflow, you monitor the average number of task items in each iteration and determine the WIP limits. However, it is not possible to know if the WIP limit is low enough to promote smooth flow and avoid bottlenecks unless you experiment.

A lean management method exists that can make all the difference and this is Value Stream Mapping (VSM). The method was invented by Mike Rother, a US researcher who studied Toyota and particularly the practices of their supply chain development engineers.

Look at an indicative example of a map below:

enter image description here

Processes have been defined on the map (e.g., "Develop feature") and the Value Added time, Non-value added time and Efficiency have been calculated.

  • Value Added time (VA) is the average time spent actively working on a task.

  • Non-value added (NVA) time is the average time spent between each process step.

  • Efficiency is calculated as follows: Efficiency = VA / (VA+NVA)

Divide your team size by your efficiency to get the total number of tasks your team can perform simultaneously.

This total will be your total WIP for the entire board. :)

An excellent example is published by Evan Leybourn here: https://theagiledirector.com/article/2014/12/07/on-setting-your-initial-wip-limits/

I would like to mention a second approach. WIP can be also calculated by dividing the total Cycle time by Takt time. This is referenced as “Standard Work-in-Process” (SWIP).

SWIP = Total cycle time / Takt time

The Takt time is the rate at which you need to complete a product in order to meet customer demand and is calculated as:

Takt time = Available production time / Average customer demand

Note that available production time is the time that the team is actively working on creating value, excluding breaks and disruptions.

Cycle time is calculated as:

Cycle Time = End Date – Start Date + 1


The definition of Work in Progress (WIP) is: Work that has been started, but not yet finished.

The reason why we want WIP to be minimized are:

  • To help the development team to focus and minimize context switching.
  • To minimize incomplete, carried-forward stories at the end of the sprint.

The way I implement this in my team is: Whenever any developer has completed a story, I ask them to first see whether they can help another developer complete a story already in progress. Only if that is not at all possible, they should start work on a new story.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.