(This column is posted at www.StevenSavage.com, and Steve’s Tumblr)
Here’s the latest on my “Agile Life” experiment (where I use the Agile techniques in Scrum). Let’s talk Work In Progress or WIP, something my mentor wanted me to learn more about, and something that inspired my “Agile Life” experiment.
WIP is Work In Progress, a measure of how much is being worked on but is not done. It’s core to the Agile technique of Kanban and the measurement has been incorporated into other practices. WIP is “on it but not done with it” – from waiting on a test for finished software to just note done.
Why is it important? Because in general too much WIP (some would argue any more than one story) is a sign of bad things or can be bad things. To much WIP might mean:
- People are multitasking a lot. Too much being done at once, nothing finished, lots of context shifting.
- Too many blockers. A lot is just holding people up.
- Bad work. Too much is held up in testing and fixing.
- Testing problems. Maybe stuff is happening too fast and it cant be tested as fast as it’s getting done, or the testing team has problems.
- Poor story and task design. The work as broken down is hard to finish or isn’t what people thought it was.
Note the first issue – Multitasking. Even if you’re not blocked by anything else, starting but not finishing things distracts you. You have to context shift. You have to keep track of many things. WIP’s problem can sometimes be its mere existence.
Very quickly as I worked to get more Scrum-like in life, I could see how easy it was to have too much WIP. This was especially bad with domestic chores, things I could “do any time” or “complete whenever.” For my first sprint, it certainly shaped up my housekeeping.
This also made me aware of the issue of tracking completion of Tasks versus Stories. Stories may deliver value so you want to get them out – but individual tasks can also get stuck in never-being done. Tracking those specific “in progress” tasks can be helpful. Makes me wonder if a cumulative flow of both Stories AND tasks would help me or other teams – after all if you’ve got 5 stories not complete due to 5 different tasks or one story not complete due to 5 different tasks, that tells you something.
Some Agile practitioners and practices limit Work In Progress (and people fight over this). The idea is that there’s a limit for a person, team, group, etc. on how much can be up in the air. Past a certain point, it’s either finish it, unblock it, or go do something else not in the Backlog until the stars align. This limits multitasking.
Frankly, I can see why people do it. One Agile Coach I know said in a class that a team at its WIP limit should do nothing until stuff gets done, even if other people spend time to go to training or something. Yes, I watched a highly experienced expert outright state – with conviction – that if a team has too much WIP and one guy has nothing to do, he ought to go read a book instead of start something else. His time would be better spent not complicating everyone’s lives by starting something else.
My guess is you can sympathize.
What do I consider ideal WIP? I’d say for an individual 2 stories and 2 tasks at most, and I’m starting to see why people often make it one story, at least in business.
A final note on WIP. Having lots of small stories you can bang out easy may sound great – but may also tempt you to do them when there’s a big pile of WIP. Even if you can finish something quickly, maybe you ought to finish something from that big pile first.
(By the way, there’s no guarantee reduced WIP is going to have benefits, there’s other variables. But it’s a worthy goal. And yes, people fight over this.)
– Steve