How to integrate QA into the Sprint [closed]

Question

One of the challenges with Scrum is how to fit QA into the process. Sure, QA works with the developers on each individual user story during the Sprint, but what about giving QA time with the fully completed sprint to do a full regression and load test before releasing into production?

I've seen 2 approaches:

1. launch into production on the last day of the Sprint; or
2. launch into production a week after the Sprint

Both approaches have their challenges so I'm wondering what most shops do that release every Sprint?

Answer 1

Both approaches have their challenges so I'm wondering what most shops do that release every Sprint?

In my opinion, the ultimate goal with Scrum is to be able to release a new increment after the end of a Sprint. In other words, the result of the Sprint is a releasable increment (not a released increment).

So option #1 seems a bit too early to me (our Product Backlog Items are done at the end of the Sprint, but before the Demo, and we don't include "releasing to production" in our Definition of Done, because this isn't really under our control, this is the job of another team).

And somehow, I think that option #2 means that you're not including everything required to be "DONE DONE" in you definition of DONE. I'm definitely not saying that it's easy to do and it will very likely take some time to really include all the required steps to reach releasable in your Definition of Done and to make the necessary organizational changes to achieve the goal.

Personally, I still didn't really reached this level of fluidity (releasing at each Sprint) and, while a part of the QA is done during each Sprint (IST, UAT), we are actually releasing every 4 sprints of 2 weeks, the last Sprint being a kind of release Sprint with "special" Product Backlog Items like performing load tests, optimizing if necessary (although there aren't much bad surprises now), writing documentation (for the production team, for users). Shortening the release cycles would require deeper changes that can't be done for now and is actually not desired in our case. Your context is certainly different of course.

See also

• Pitfalls of QA during Sprint?

Related questions:

• Best practices for QA / testing in an Agile (Scrum+XP) team?
• Help me understand how QA works in Scrum
• Best ways to fit bug fixing into a Scrum process?