Work In Progress, Visually
How many projects have you started and not finished? Some? Too many? Regardless of the count, this is Work In Progress. For software engineering Work In Progress (WIP) may be defined as the number of stories started which haven’t been finished. WIP tends to grow over time. At some point it will start to affect delivery.
Why WIP matters
WIP matters because demand always exceeds capacity and context switching takes time not used for completing work. Every new item added to the WIP queue requires prioritizing existing work, possibily the entire queue. Sometimes prioritizing is easy, other times it might difficult, requiring communicating with stakeholders, or resources already committed to other projects.
The following diagram illustrates what happens when WIP is addressed in a concurrent manner versus a sequential manner. There are 4 tasks in progress, red, blue, green, and gray.
For personal projects, whether WIP is good or bad is a value judgment exercised by the person. Unfinished collaborative projects risk a reputation hit, family and friends may not be amused. At work, too much WIP also risks a reputation hit, and possibly a career hit.
In words, concurrent processing comes with a risk of having a lot of unfinished work at any particular time. When tasks are approached serially, tasks get done. At work, this probably matters.
Links
The material in the following links may provide helpful context.
- Making Work Visible. The author notes (p. 188) that Scrum uses time boxing (sprints) to constrain demand, and kanban uses WIP.
- Little’s Law (Wikipedia) is a proven result, and applies where mean and variance of the process do not shift with time. From Wikipedia, “Little’s law is widely used in manufacturing to predict lead time based on the production rate and the amount of work-in-process.”
- The Lindy Effect is the notion that the longer things live, the longer they live. Applied to Work In Progress, the longer a work is in progress, the longer it will take to finish. This argues for smaller changes applied faster. Matt Rickard provides another on the Lindy Effect with many examples applying to software development.
- What’s WIP and why is it so important to limit it? makes an excellent observation about the inverse correlation between throughput versus response time.
- How finishing what you start makes teams more productive and predictable is the article I would have wished I’d written years ago. It’s long, but it’s worth the effort if you 1. like hamburgers, and 2. have the time and interest to dig deeper. Specifically, the author introduces Little’s Law, which I specifically avoided in my article.