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.
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.