Release Planning – Initial Plan

Scrum guide doesn’t implicitly describe how releases should be performed and doesn’t define the interaction between scrum events and release planning. Actually, the latest update contains more references to the release for instance: explicitly referring to CI: the purpose of each Sprint is to deliver Increments of potentially releasable features. This Increment is usable, so a Product Owner may choose to immediately release it, as frequently as many times per day.

That’s still not much, so we had to come up with a plan.

We have defined cycles, release loops which consist of three sprints: focusing on the feature development in the first two sprints and focusing on major release in the third sprint. Hotfix and spot releases are allowed in the first two ones, so urgent releases could be performed at any time in case of need, but the major release should happen only in the third sprint.

Why is that sprint so special?

It would help the dev team focusing on the delivery and performing better sprint planning by keeping in mind that more bug fixes and operational issues might pop in during that period. It allows the dev team to get better prepared to take any immediate action if needed because production issues are more likely to appear after release and helps the business to lower their expectation of the delivered work during the sprint.