Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
My team is newly formed and trying to establish a baseline for their velocity in story points per sprint. The problem is at the moment the QA is part of the sprint. It has been suggested that it is excluded and that only the development phase is in the actual sprint. Why? Also should the velocity of QA (and BA before the sprint I guess) not be part of the team velocity?
Thanks! :)
In short; anything that has verifiable acceptance criteria should go through QA and they should be complete members of your sprint / agile team.
In detail:
Ideally, in agile / scrum, at the end of the sprint you are able to release the completed work to production. So that work needs to be tested and verified before it can be release, which means that QA needs to be part of your estimating.
So when estimating, any work that is "testable" would have to take into account the test time and any time to resolve any found issues. This means that your velocity will likely slow down in the short term, but in the long term it will create a more stable and viable product.
Why:
Why Not:
That is the only instance that I can think where a QA would not be needed. Even then, they should vote on everything that is not exclusively technical.
Having said that; the above "why not" is complicated because some would say that purely technical sprints / stories are invalid because they are not delivering value. So then you go in the opposite direction and end up with massive stories that others would say are too big and need to be split into smaller stories. At that point; you have to figure out what works for the team.
There is one central question that I considered when addressing this question for myself and my team: is QA required for an issue to be "Done?" I would argue that the answer is always yes. Nothing leaves our development process until QA has verified and tested it, so therefore we can't get anything to Done in a Sprint until QA has looked at it.
Calling issues Done without putting them through your QA process will only lead to an artificially-inflated velocity and hurt your team in the long run. Whether it's through bug reports or PBIs being returned to you for a future Sprint, it's not a sustainable way to develop.
In short, each Story/PBI should have to be put through your QA process before it is Done.
If dev and QA teams have traditionally operated separately, their processes and knowledge domains might be too different for them to effectively make estimates together, and thus establish a common velocity together. What I have seen done is stagger the dev and QA sprints so that one starts in the middle of the other. For example, if they are using two-week sprints, QA starts one week after dev. That gives dev enough time to finish a few stories and start handing them off to QA early instead of waiting until the dev sprint ends. This might be workable in your case while QA becomes more integrated with dev.
This really depends what you mean by QA.
At the end of every sprint you should have working shippable software. What does shippable mean to you? I would asume that you need to test, but you may have an external validation step. The development team should have all the skills and knowledge to make software that will pass all external validation steps with no additional work.
BA's should work for the Product Owner and are not necessarily working on the Development Team.
