How often to you release during a sprint. Only at the end of the sprint or every time a feature is ready. And how to you handle bugfix releases?

  • 3
    if you release every time a feature is done, maybe you should look at kanban instead of Scrum
    – David
    Oct 20, 2011 at 11:41

8 Answers 8


TL;DR: Release whenever appropriate

We do releases whenever there is value in doing a release. Sometimes that means doing a release after a single feature or bugfix is completed. Sometimes that means releasing a collection of features and/or bugfixes.

This doesn't mean we often have "emergencies" that require fast releases. It means we've worked hard to make releases easy. Our code is tested, tagged and packaged with every build. We use automated acceptance tests and as a result we have developed a high amount of confidence in the code that passes it's tests. Since our packages are immediately available via a local yum repo deploying a release is trivial.


Never during. That violates the basic premise of a "sprint". You run until you finish what you committed to finish. After you finish, it's really done and really works. You can then release it.

Release can be a separate kind of sprint where things are packaged for release.

Bugfix releases can be just short sprints. Not having a regular schedule of same-length sprints is considered by many to be a bad idea. Therefore, the usual rule is that bug fixes are simply high-priority work that happens during the next sprint.

If it's an emergency, you've got too many things going on -- support and development -- and you should consider changing the organization to have fewer things going on.

  • So, how are the testers supposed to test continously? Mar 12, 2019 at 6:05

If the work the team is committing to is conducive to doing multiple releases within the sprint, release it as often as you want.

The same holds true for defect-fix releases--if it makes sense to release them, do so.

  • Yes, I agree. The best approach is to decouple releases from implementing features and/or sprints. The (release) processes need to support this. A sprint is a time frame. A release can be done at any time if the version you release passes QA. The two things can be different. How to achieve this? One option is using the concept "no junk in the trunk" for branch management.
    – Manfred
    Oct 18, 2011 at 23:07

The last Agile job I worked at had releases every sprint; code was frozen every other Thursday (two-week sprints), and then the product was packaged and published to a UAT server for our clients to work with. This was during initial development of the product; for a mature product, especially a distributable program and not a web app, you probably wouldn't want to burden your users with upgrading every two to three weeks.

Virtually all our releases included a mix of story points and defects (bugs). Defects counted as "non-ideal hours"; there are 5 ideal hours in a workday, meaning heads-down coding of new point work. The other three to four hours a day are meetings, discussions, design, sometimes "spikes" (focused research/proof-of-concept development), and defect work; stuff that contributes to a better product and is a necessary part of the process, but simply cannot take up the entire team's entire sprint. The only time we did defect-only releases was when there was no story-point work available in the backlog as of an IPM; then we simply scheduled a QA sprint where we were instructed to "kill as many defects as you can". Because not having requirements ready to go is ALWAYS the PO's fault (and the PO worked for the clients), we could simply issue a contract change notice and work with what we had. Of course, once the actual story work was over and we were into "warranty" development, defects were all there were.

In a well-managed Agile project, running out of requirements should never happen; the backlog should always have a sprint's worth of work ready to pick up. But, sometimes the PO gets swamped producing requirements; sometimes the BAs/testers hold up release of stories to the development backlog, for reasons relating to requirements quality or story conflicts; sometimes a team decides they have to "punt" on a story that wasn't well-defined or well-estimated, and there isn't something that can easily take up the remaining cycles. In short, even in Agile, shit happens.

  • 3
    I think the point of Agile is that we EXPECT shit to happen. Oct 18, 2011 at 22:00
  • If your build process automatically tags a packages the code there is no need to "freeze"? Work can continue, vetted version can get pushed out, etc.
    – snakehiss
    Oct 19, 2011 at 16:09
  • The "freeze" was symbolic; we basically said that the latest build for which CI had passed as of 5:00PM Thursday was the release build, and we cut an SVN branch for that revision and moved on. If you didn't commit by then or your commit hadn't passed all CI tests it wasn't in the release.
    – KeithS
    Oct 19, 2011 at 16:13

What do you mean by release? If you mean PSP - probably shippable product you have two options:

  • Scrum by book (or Scrum level 2) you have PSP at the end of the sprint and that is what you show at retrospective meeting
  • I also met term Scrum level 3 where the team mastered their tools like Source control and Continuous integration and moved to Continuous delivery. Such team is able to have PSP after every nightly build (or every build in the best case). Having PSP after every build doesn't mean that you show it to the customer after every build - it is still just internal release.

The main difference between level 2 and level 3 is that in level 2 you must put some effort to make final PSP at the end of the sprint but in level 3 you put some money and effort initially to your tools and configurations and you have PSP prepared automatically all the time = there is no manual effort involved. Fully achieving level 3 is rare.

  • are these "scrum levels" official names ? I googled it and found nothing.
    – David
    Oct 20, 2011 at 11:46
  • @David: I don't think it is anything official. It is just another approach to measure "Scrum maturity" - I have found this presentation discussing those levels but I met it on CSM course. Oct 20, 2011 at 12:35

There's absolutely no rules in Scrum about when new features may be deployed. Every team needs to have a "definition of done", which always should include some criteria about testing. Once a feature is "done", it's ready for the real world and if there aren't any other dependencies or conditions that need to be met before it can be deployed, then there is no reason to wait for the end of the Sprint to deploy it.

None of which means that it isn't presented at the Sprint Review/Planning meeting. The concept is that everything that the Team has completed is shown to the PO (and other customer SME's) so that they can incorporate it into their growing understanding of the system as it evolves.


After a couple of weeks we found a good solution that fits our needs. We decide to release when ever we want. How we do that:

  1. when ever someone decide to release the actual develop branch, he merge all changes in the master branch tagged it with new release number and pushed onto our staging system.
  2. than our QA and all other teams get's a mail with an actual changelog and they test staging system
  3. if they found bugs we fix them in the master, pushed it to staging and then merge the master back into develop branch
  4. when the staging system passed the QA the master goes live

Thats it. We use git and maven as CI system and we have a good test coverage. Which is one of the reasons we can doit like this.


Answering a question that is almost 2 years old may be a bit redundant, but to hopefully add value for others who come to this question i would like to add a 2cent or so. :)

To answer the question: You should preferably release what was committed to in the sprint, at the end of that sprint. Doing so ties in with all the other parts/processes/guidelines of scrum which is geared to getting the best business value out at the right time.

BUT emergencies, bugs, unexpected events etc may force your hand, which is where the concept if "Release Planning" could come in handy. With "Release Planning" I do not mean waterfall-type-planning but rather planning of expectations which could help manage the product backlog and priority of stories in sprints ect.

But perhaps David's comment on the question is something to best consider. Scrum is not always the right answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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