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

  • 3
    If there would be some "dictate by an official guide", that would not be very agile. The answer to your question is IMHO the same as the top answer to "How often to release" from your link above: whenever appropriate. Note Scrum tries to be a generic framework, but build times and QA requirements still vary heavily from product to product. So there is no way around using your own brain and think what is appropriate for your software and your team. – Doc Brown Mar 12 at 6:20
  • There are a lot of dictates in the official guide. If dictates make for less agility, Scrum ain't very agile. – Melbourne Developer Mar 12 at 20:17
  • 2
    You asking if the guide mentions something, after specifically saying you read it and saw it didn't mention something? What kind of answer are you expecting other than "I read it, and no, it doesn't mention it"? – Bryan Oakley Apr 5 at 14:15

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.

  • I agree that I would 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.". The point is that the guide doesn't offer any guidance on how to achieve the above. – Melbourne Developer Mar 12 at 6:00
  • Any thoughts on why it doesn't? – Melbourne Developer Mar 12 at 6:02
  • 2
    because if it did, some people would say it was wrong and hence scrum was wrong and wouldnt pay for scrum consultants and training etc – Ewan Mar 12 at 7:54
  • 1
    @MelbourneDeveloper The Scrum Guide overall lacks details in these areas. SG defines roles and responsibilities of those roles. But it doesn't go into detail how those roles should achieve and fulfill those responsibilities. I guess SG assumes the people working under it are skilled enough to know better and that they will use retrospectives to adopt more efficient techniques and processes. – Euphoric Mar 12 at 9:26

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".

  • 2
    "Scrum" may be a general product development framework, ( at least in theory) not just specific software to development, but same is true for "QA" and "tests". – Doc Brown Mar 12 at 10:53

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.


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.


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".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.