One of my product teams has been successful in deploying to production once in every two weeks. In the past, our release plan would comprise of a sprint zero, one or two working sprints, followed by a release sprint.  We were essentially releasing features to end-users once in every six weeks or more. Our product features is critical to the business. With a primary objective of learning, adapting and reapplying changes quickly, our product team migrated to a shorter release cycle thereby developing and deploying for each sprint.

Benefits of frequent smaller releases

1. Frequent deployments to end-user provide a competitive advantage.
2. Product requirements could change significantly if deploying to production once in every few months. By launching frequently, you could gather data from end-users earlier and apply adjustments accordingly.
3. Keeps your team energized and motivated.
4. Helps in establishing best practices.
5. Exposes risks and challenges with design, architecture and solutions earlier in the process.

Adopting a two week release

The following would aid in adopting smaller and frequent releases to production.

1. Prioritize your product backlog by identifying the key features and corresponding stories that will result in a positive impact to your product space.
2. Identify places for improvements that have been consistently impacting your team and attempt to seek resolution. For example, resolve any environment issues or data discrepancies before attempting to proceed with a shorter release cycle.
3. As a team, review and update the definition of done for stories and sprint.
4. Identify cross team dependencies well in advance before beginning the sprint and ensure prompt support from external teams with the dependencies.
5. Conduct an effective Sprint Planning session, where team members can quickly identify the stories/defects that can be ideally completed within a sprint. Identify all tasks such as design, development, testing, etc. that are potentially shippable to the production environment.
6. Collaborate with your product owner as early as you can on areas such as seeking clarification on acceptance criteria and soliciting feedback on stories/defects as and when they are completed during the sprint. Reviewing the sprint backlog with the product owner for the first time during the sprint review meeting could be too late and ineffective.
7. Automate test cases and update them during the sprint.
8. Allocate an hour or two for grooming the product during the course of the sprint. This essentially allows the team to review stories and refine acceptance criteria for stories in the product backlog.
9. Plan for deployment at the end of your sprint review meeting. Be prepared to handle scenarios such as stories being rejected. Incomplete stories may be reprioritized for a future release.
10. Refactor code and consider pair programming techniques for enhancing product knowledge across team members.

     

    Needless to say, remember to set aside time for celebrating with your team!