Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

I am aware that the length of a Scrum Sprint can vary on a case to case basis. This raises the following questions:

  1. How can product releases be handled within the Sprint time-box?
  2. How frequently can the release happen?
  3. Does Scrum have any rules that require releases only at the end of a Sprint?
  4. How does it affect the product, developers, and testers?
share|improve this question

3 Answers 3

up vote 2 down vote accepted

Typical approach

Scrum by-the-book assumes that you release at the end of iteration, then you demo the product to a client. "Release" and "demo" of course may mean different things depending on a product you build, e.g. back office app for big corporation versus an app directly addressed to end-users.

Most Scrum teams try to release at the end of timebox as it gives them more freedom in terms of how the work is done within iteration, e.g. they can start everything at the beginning of a sprint and finish stories only as the sprint end approaches.

Frequent releases

However, if you want to release more frequently, which I would personally encourage, feel free to do this, no matter what is the typical practice or what books says. Scrum, as any other method, is not a religion and shouldn't be treated dogmatic.

You might want to introduce (more) frequent releases since:

  • They shorten feedback loops--you learn what you did right, what you did wrong, and what should be changed sooner--so you can act on this feedback improving further work faster.
  • It also means that you need to automate most, in not the whole, process so you get closer to continuous integration.
  • Another thing is it encourages smaller batches of work, which usually is safer way to increment a product, as the smaller the change the smaller the odds that something is going to blow up.

By the way, there are methods that are decoupling planning, release and retrospective cycles. In this case we are talking about cadence. Planning cadence doesn't have to be the same as release cadence or retro cadence is. It's just Scrum that made them so. Read more about cadence versus iteration here.

In general, change to frequent releases affects the team as the tools you use usually have to evolve. You can spend a couple of hours to release a product if you're doing it bi-weekly. If you're doing it every single day, you can't. The good thing is that you may make this transition evolutionary, shortening release cycle step by step, e.g. from bi-weekly to weekly, and looking for pain points and addressing them.

share|improve this answer

Scrum originally didn't have anything related to releases, but fortunately it has been changed and there is a thing called Release Planning. During this meeting the Scrum Team and the Product Owner sit together and see when the product can be released. It is a high level planning meeting.

In reality, the releases are set by the projects and the stakeholders. The Scrum Team and the Product Owner shall use this meeting to give a periodic feedback to the stakeholders about the release. This feedback should contain information about the risks, scope (content) and possible impediments.

The frequency of this meeting depends on the length of the Sprints and the length of the original project. I didn't manage to find any data on the frequency, but I'd say have at least 3 meetings during a project - equally distributed on the length of the project.

This was the case when the release is pushed to the team. If the team can decide on the releases then I'd refer to the original Scrum idea that the result of a Sprint must be something shippable, hence the release happens after each Sprint Review Meeting.

Frequent releases in a large context have a huge overhead, but the feedback received from the customers/users/stakeholders are very valuable. That's why teams should do Agile: have frequent feedback on their work to verify that they are on the right track, and without frequent releases it is hardly possible.

share|improve this answer

Continuous Delivery and Scrum

Scrum is about time-boxing. Continuous delivery is about rolling releases and (to some extent) automated continuous integration and deployment. They are not completely orthogonal, but they are not synonyms, either.

Release Planning

If you're practicing "real" Scrum, then a release should coincide with a shippable increment at the end of a time-box. However, I have seen real-world examples where "shipping" was a story within a Sprint, where the shipping story is tracked as work and has user stories that continue on past the shipping story in the Sprint Backlog. If that fits your work-flow, then it's certainly something to consider.

Alternatively, any Sprint can be abended by the Product Owner, so even within the traditional Scrum framework there's a methodology for shipping early. The idea is that the Product Owner can terminate the Sprint at any time and return the team to Sprint Planning. This incurs process overhead, but it may very well be justified in some cases.

More About Early Sprint Termination

An early Sprint termination isn't automatically a negative thing; it's simply a management tool that trades some cycle time and process overhead to respond to changing business requirements. If the Sprint Goal for a given Sprint is "ship the product," then early termination of the Sprint after a successful product shipment is the very essence of agile, since the project doesn't chug along and incur costs that aren't necessary to the organization once its goals have been met.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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