Limiting work in progress (WIP) is a mindset shift! Limiting WIP has many benefits. What is your WIP mindset?
The blog Do A Few Things Insanely Great emphasizes that we can actually “do more with less”. 
The idea is that we can increase our flow rates, decrease wait times, and eliminate bottlenecks when we limit WIP. This leads to increased productivity, improved team morale, more visibility into ongoing work, and better metrics on velocity and project progress. There is more personal satisfaction in seeing things actually completed rather than having a full plate of ongoing work.
Limiting WIP also makes us identify and focus on those tasks which have the highest value since we can only work on a few things at a time. If we can only do a few things, we will first pick those that deliver the most value.
Scrum and Kanban have built in mechanisms for limiting WIP.
In Scrum, the sprint backlog is the artifact that manages WIP. The team meets during the sprint planning meeting at the beginning of an iteration to create a sprint backlog of the highest value user stories that can be completed during a short iteration. Velocity is calculated as a measure of points from the stories that are done and accepted. The sprint review at the end of the iteration is primarily a demo of those accepted stories.
In Kanban, there is a visual board or table consisting of columns. Work items move from the left column to the right most. Most columns have limits to the number of work items which can be concurrently in progress within that column. The general method is to “pull” items from the left to right columns, and you can only “pull” if a space is available. The goal is to increase flow and eliminate bottlenecks, reducing cycle time as items move across the table.
The opposing WIP mindset values lots of ongoing work. There is always a lot of pressure to add more to an engineer’s plate. An engineer once proudly replied “he was currently juggling 17 tasks at once.” It was important for him to have lots of ongoing assigned work. This concept can be reinforced by managers who put value on the quantity of work assigned to engineers.
How does WIP impact the daily work stress?
By limiting WIP, stress can be managed since there are more frequent deliveries which typically involve smaller work items. There certainly is stress from knowing that you must get to completion. This stress can be reduced by the team being engaged with the refinement and selection of work items. The idea is to create a sustainable pace for which the team of engineers maintain a productive level. Stress level is generally constant or elevates slightly since the duration of an iteration is short.
With unlimited WIP, the stress level increases exponentially as the release date gets nearer. Think of it as an ocean wave curve. As long as the schedule date is in the distance, there can be a calmness to have lots of ongoing work. Eventually, as the time nears to a release date, the pressure mounts exponentially as the wave crashes down on us. Managers begin to increase pressure on “knowing when things will be done” and may start to actively engage with “command and control.” Engineers begin working longer hours. The consequences are even more stress from last minute code insertions, reduced testing before deployment, and increased error proneness.
In summary, limiting WIP is a mindset. Try to limit your WIP to get more done (and done well). If you are a manager, communicate to your team that you value work that is completed over the amount of ongoing work. The goal is to create a sustainable pace with sustainable stress levels.
What is your WIP mindset? Let us know your stories on how you manage WIP or send us other topics related to your experiences on “cultivating and growing agile.”
