As a coach, I like to introduce new practices only when I can offer them as a solution to a problem that the team has identified for themselves. On my current team we’ve been tracking our Work in Progress (WIP) for some time, but we’ve never taken the step of systematically limiting it.
At a recent retrospective it became clear that everyone was feeling the strain of having too many things going on at once:
- Our velocity was really bumpy, with no releases for days at a time, then suddenly several stories going out at once in a big batch.
- Our QAs, who run final checks on stories before they go live, would be periodically hit by a tidal wave of work when one of these batches came through
- Stories would languish in the ‘nearly done’ stage, with developers too distracted with new work to finish off final copy changes and tweaks.
- There was a general feeling of being constantly distracted.
- We were doing less pairing than we wanted: the person you wanted to pair with always seemed to be doing something more important.
- We weren’t getting as much done!
We all agreed it was time to set a WIP limit.
So we studied our Cumulative Flow Diagram (CFD) chart, and looked back for a time when we’d been more productive. We used the measured WIP from that time as our new limit, and stopped taking on any more work until we’d drained down our number of stories in progress to that limit.
Here are the benefits we’re now enjoying:
- Our delivery velocity is smoother
- We’re pairing more again
- Our stand-up takes a sane amount of time, and people aren’t fidgeting and bored because what’s being discussed is more relevant to more people
- The cycle time to get a change through the build and into production is now way shorter
It’s too early to say, but I think we’re also starting to get more done again. Little’s law would certainly indicate that this is a likely outcome.