Project Practitioners > Limit Work In Process To Improve QA Utilization

Limit Work In Process To Improve QA Utilization

By Brandon Carlson

After adopting an Agile process, many teams find that the time boxed iterations are great for developers. By focusing their efforts on the following two weeks, we can limit the effects of student-syndrome and provide more accurate task level estimates. Often, however, another pattern emerges: QA sits idle for the first half of the iteration and gets slammed in the second half.

How does that happen? Let's look at an example.

Given a team of 8 developers (4 pairs)
and that 1 point is approximately 2 days of work
and the sprint length is 2 weeks
and the sprint work picked up is
   Widget 1 (5 pts)
   Widget 2 (3 pts)
   Widget 3 (1 pt)
   Widget 4 (8 pts)
   Widget 5 (2 pts)

Once planning is complete developers pick up the stories. Often, each pair will pick up their own story to work on. This means that development on Widgets 1-4 will begin immediately. Assuming that the estimates are accurate, which stories will be complete the first week? Naturally, only Widget 3 will be completed the first week. What does that leave our QA team to do? Sure they can begin working on more negative path or edge testing, but they probably want to relax considering that they'll likely be putting in some overtime towards the end of the week when the remaining four widgets come their way.

How do we solve this issue? We could shorten our iterations down to 1 week and accept less work each iteration, but that really doesn't fix anything, it just scales the pattern down to fit in a smaller window. What if, instead of picking up one story per pair, pick up just one (or two) story(ies) at a time? Widget 1, which was typically a 10 day task for a single pair, could be divided and conquered by all 4 pairs in 2 or three days. This still gets work to QA within the first couple of days of the iteration, but what happens to the rest of the widgets? Well, I'll leave the math as an excercise to the reader, but Widgets 2 and 3 should be to QA within another 2 or so days, and the same down the stack. This enables better flow and reduces the chance of a mad rush of testing at the end of the iteration.

Limiting work in process is a great way to reduce the thrashing that ocurrs within so many Agile teams. Next time you feel the QA rush at the end of the iteration, ask yourselves why. It's likely that too much work in process finishing late in the iteration is the cause.

Related Links
One point, two points, three points, four ... project poker can help your team decide how many to assign to each feature in your backlog. Refine the speed bumps in your projects with regular retrospctives. Use a Big Visible Chart to keep QA up to date on what's in process and what's in their lap.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I only touched on this in

Nice to see a better treatment here.

I don't mean to be flippant, but please explain how this differs from nine women having a baby in one month.



It differs only in that babies can't be decomposed, but many software stories can - especially if they're big.

One of the key points of pair programming done right is that you switch partners A LOT. If you only switch once a day (not enough) then at the end of the pairing session the "A team" can agree on dividing some labor - "we'll leave these tests for later - I'll pick them up after we split."

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.