My team is newly formed and trying to establish a baseline for their velocity in story points per sprint. The problem is that 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?
-
The business analysis needs to be done before the Product Owner knows what Stories need to be created for the product, so that does fall outside of the development team and their Sprint.– PolymathMay 11, 2016 at 13:30
-
Do you mean QA or testing?– MrHinsh - Martin HinshelwoodMay 15, 2016 at 17:42
Add a comment
|
5 Answers
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:
- Just because a developer marks a story as done doesn't mean ALL of the acceptance criteria have been met.
- You decide to exclude QA and verify the acceptance criteria yourself. That doesn't work because the acceptance criteria is expected behavior and a QA can often make really strange things happen.
- In the unlikely event that the developer happens to do everything regarding their story perfectly; it likely has to interact with other parts of the system and that could introduce bugs.
Why Not:
- Not every story requires QA. For example; a documentation story or refactor story may not be something a QA needs to / can test.
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.
answered May 15, 2016 at 17:45
If the QA or functional testing is included, what would developer do when they finished all the coding for the Sprint whereas the testers are still doing their testing?
