Does the Scrum Guide Specify How Often to Release QA/Test Builds?

Question

See https://www.scrumguides.org/scrum-guide.html

I've read through this several times and can't find anything about how often to do QA/Test builds during a sprint. There is a section called increment. This seems to refer to the fully built product at the end of the sprint, but it doesn't offer any guidance on whether or not builds should occur during the sprint. My question isn't about How often to release . My question is whether or not the official guide dictates how often to release. I'm not looking for opinion or speculation. I just want to know if there is an official guide on this

Answer 1

No it does not. Only thing it states that at end of sprint, Potentially Releasable Product Increment is produced.

And general consensus of "Potentially Releasable" is that it does include it being completely tested. But how team achieves that is completely up to the team.

In practice, I find it hard to imagine that fully tested "potentially releasable" increment can be achieved without deploying into testing (or even production) at least few times during sprint. Or without good chunk of build, testing and release being automated.

Answer 2

Scrum, according to the scrum guide, is not specific to software development. It can be used for Software development, but there are many other kinds of projects where scrum can be implemented. Note that the word "software" only appears twice in the text. As such it makes sense that the scrum guide does not mention anything specific to software development, like "builds", "releases" or even "QA" and "Test".

Answer 3

The official guide gives no guidance about building OR releasing.

The guide is very carefully written to only proscribe behaviors that are core to Scrum, and to recommend a few others, and to leave the rest of your process up to you. This is what it means when it says it's a "lightweight" and "a framework".

One similar place teams seem to get confused these days is in backlog refinement. The Guide recommends backlog refinement as a practice, so that Sprint Planning doesn't have to take half a day. It doesn't proscribe how that gets done--it literally says, "The Scrum Team decides how and when refinement is done". I know of teams who have a mandatory two-hour full-team slogathon of a meeting to do backlog refinement, and don't seem to think they can inspect and adapt that item.

Answer 4

The Scrum Guide only talks about ensuring that, at the end of the Sprint, there is "a "Done", useable, and potentially releasable product Increment". However, there is also nothing that precludes creating such a Product Increment more frequently than once at the end of the Sprint.

If your team or organization states that, for a Product Increment to be considered "Done", it needs to go through a QA or Test build process, then you would need to produce an Increment at least once before the end of the Sprint with sufficient time to go through your QA/Test process such that the Increment can be considered "Done" at the end of the Sprint (going into QA review).

If you need to go through a release process in order to go through the QA/Test process, then this would also imply that you need to go through the release process at least once in a Sprint, so that way your Product Increment can go through the QA/Test process before the end of the Sprint so that you can have a "Done" Product Increment at the end of the Sprint.

Answer 5

No, it does not state how oft you need to test/ roll out build on test environment.

Increment can be marked as "Done" only if it has been developed AND tested AND covered acceptance criteria. It depends from involved people, how many cycles you will need to get there. Some will be done with 1 or 2, other can take 10-15.

I suggest you as well to read Scrum.org article about meaning of definition of "Done".