"What do our QA people do at the beginning of a sprint before the developers have coded any user stories for them to test?"- Every aspiring Agile team with QA people
Honestly, I'm not sure I've ever worked on an Agile team that did not struggle with this conundrum of keeping QA people busy early in a sprint.
I'm a fan of the maxim: "If you can lean, you can clean"—there's always something valuable to do on a software project at any given time. Here are a few ideas off the top of my head, but I'm sure a curious mind could come up with many others:
- Automate the testing of user stories that were tested manually in previous sprints
- Conduct exploratory testing not directly related to a particular user story
- Training
In case none of these ideas are adequate, there's also the common advice from Agile literature that smaller user stories are better. This idea of smaller user stories is appealing to people who are struggling to keep their QAs busy, because the thinking is that smaller stories take less time for the developers to code, and therefore the QAs don't have to wait as long to begin their testing. Makes sense, right?
So well-meaning teams take an axe to their user stories in an effort to make them smaller by any means necessary. Give QA something—anything!—to test.
Work proceeds like:
- Write a specification of something.
- Write code that meets that specification.
- As quickly as possible let a QA person check if the specification has been accurately met.
- Forget whether the behavior specified solves any problem for a real user.
By following this path, it's amazingly common to see the goal of "keeping QA busy" become the central organizing principle of a software project. And before we know it, maximum utilization becomes the goal of our sprint, rather than delivering value to users at the end of our sprint.
After a while, it starts to look like QA is our user, not the actual user anymore. We're delivering stories for QA now, not the actual people who need our software.
Snap out of it! There is no user but the user. Value is only realized when the user has it.
It's like acquiring staggering piles of Monopoly money. That pile looks really pretty, but let's not kid ourselves about the "value" of what we've achieved.
We don't work for managers and we don't work for QAs. We work for our users.
