Minimizing Work in Progress within a Scrum Sprint is Important, too!


How many times have you heard the following from the testers in a team attempting to be agile?

“There was not time to test at the end of the sprint. We just got most of the features on the last day of the sprint. How are we supposed to test those features?”

Frankly, I think it happens all the time. This is one of the reasons that some teams try to have the testing teams test features in a following sprint. The problems is that so many teams attempt to apply a variant of Scrum that can be called Scrumerfall. Basically, these teams are treating a sprint like a miniature waterfall project like the following diagram shows.

This team is based on a real scenario that I’ve seen. The team had three developers, on the first day of the sprint, they all took a PBI and drove it. But what happened? The variation in completion of requirements and development resulted in really squeezing the testers that were on this team. Sure they were working on test cases and test planning initially, and even participating in requirement meetings. Something obviously wasn’t working very well. For instance, how well do you think Feature 3 was actually tested?

If that’s all we do when setting up scrum teams, we’ve failed. We haven’t allowed testing to happen sufficiently, and we haven’t really built quality into the process. We have limited the amount of work in progress (on paper), but technical debt obviously is growing here no matter what.

An alternate reality of Sprint 23 above is executed by the same team, but we’ve set a WIP (Work In Progress) limit of 2 PBI at a time. Let’s see what happens:

What’s different here? The total duration of Features 1 and 2 shrunk a little bit because I had to double up the effort short term (we forced the team to collaborate on those features, rather than each going in their own directions). Feature three testing also grew in duration which illustrated it probably needed to get tested more even in the first case. Additionally, the team is often performing all types of the functions in there, from requirements, development, and testing throughout almost the entirety of the sprint. The team was increasing its design, build, deploy cycles and having many of those throughout the sprint, rather than just at the end.

At the end of the day, forcing WIP limits can increase the throughput and quality of features that are running through the system.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *