Velocity for a QA team is a bit harder. To hew to the equivalent of the dev team's definition, we would count work performed to accept stories, and work performed on QA stories ("develop a user acceptance test plan", "certify our software with another vendor's software", etc). But is this really sufficient? We've modified the definition a bit to be the following:
QA velocity includes activities that are defining, performing, and analyzing the results of tests.
Things that are included in our velocity measurement:
- Test plan development
- Test automation
- Performing manual tests
- Going through automated test results to identify new and recurring issues
- Accepting stories
- Creating acceptance criteria for stories
Things that are not included in our velocity measurement:
- Helping support diagnose a problem
- Verifying bugs that are not part of stories (so if a bug became a story, it counts. If the bug didn't, then it doesn't count)
- Attending other team planning meetings
In the end, velocity isn't about the absolute number. It isn't even about whether the number matches the dev team's number. It's about whether the number goes up or down over time. And it's about using the number to figure out how far down our queue we're going to get this iteration.
So don't sweat what goes in the number. Just define your velocity and go with it. Then watch how the number changes and how it works with your estimates.