How often to release in Scrum sprint

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.