How to articulate Release Management and Sprint? Furthermore, how to book capacity for Release Management when the contributors are working in the Sprints? At last, how to make sure Release Management tasks are properly delivered?
How to deal with Release Management in Agile and with Sprint?
Most Agile frameworks, Scrum or Kanban included, focus only on the delivery cycle (Scrum Sprint) to build, unit-test and demo the features, not on how to run advance tests, package and deploy the software to production as traditionally covered by Release Management.
- How to:
- Articulate Sprint and Release Management ?
- Manage activities related to Sprint and those related to Release Management, especially when they involve the same people ?
- Make sure to properly cover Release Management tasks in order to enforce quality and support change in production?
How does Continuous Delivery deal with Release Management?
We will not cover here the special case in high maturity Continuous Delivery environments where it is possible after the build and the test of a user story to run automatic tests with a coverage wide enough to enforce the quality for the change to be automatically rolled out to production.
In fact, the context we are talking about is the common scenario with partial automation where the release with tests, packaging and deployment remains a batch step. In this case, the Agile development cycle, aka Sprint in Scrum, has a different duration and start date than the release cycle. Really, they are in parallel. So, this means that once the release date is identified and that a retro planning has been built with the contributors identified, the needed capacity should be booked and remove from the contributing Squads’ Sprints. Actually, this works the same way either one Squad or several Squads contribute.
Who does take care of Release Management?
A dedicated team may support part of the work but having the Squads in charge of development taking care of the production roll out and after that the support, is a good way to make them aware about the production needs and to enforce automation. Definitively, this is the “you build it, you run it” principle part of Agile at Scale.
How to properly cover Release Management tasks in Agile with Sprint?
In Agile, there is a powerful tool not to forget things to be done, before to start a user story or to consider a user story completed. Without a doubt, this is the Definition of Ready and the Definition of Done. In addition, this supports a common definition and consistency in the way of working within a Squad or over a group of Squads.
Furthermore, this tool may be relevant at the feature level for the same reason. In addition, some of the tasks are not delivered for a single user story but for a group of user stories contributing to the same feature and should be managed at this level.
How to leverage Definition of Ready (DoR) and Definition of Done (DoD) to steer Release Management in Agile with Sprint?
User Story, illustration of DoR and DoD
Definition of Ready
- Format of the user story: “As a Role, I want Expected Functionality, so that Business Value“.
- The user story follows the INVEST model:
- I – Independent (among other stories),
- N – Negotiable (a flexible statement of intent, not a contract stating “you must do it this way”),
- V – Valuable (providing valuable vertical slice to the user),
- E – Estimable (small and negotiable),
- S – Small (ideally fits within a sprint),
- T – Testable (understood enough to know how to test it) against accept criteria.
- Parent feature: the user story has a parent feature.
- Dependencies: the team has identified the dependencies with other user stories.
- Estimated and split in tasks: the team has estimated and split the user story in sub-tasks if need be.
- Acceptance Criteria: the PO has defined acceptance criteria that cover functional and non-functional requirements.
- Common Understanding: the team has reviewed the user story and understands it.
Definition of Done
- Code Review: peers have reviewed the code.
- Code analysis and quality control passed successfully.
- Unit Test are scripted, fully ran and successfully passed. The team has captured the results.
- Defects: there is no critical defect without an agreed workaround.
- Acceptance: user story meets acceptance criteria as defined in the DoR.
- Demo: Demo delivered with PO, Key Users and the Squad. If the PO finds any gaps, her or she creates new user stories to cover them.
Feature, illustration of DoR and DoD
As there are several steps, we will not have just a Definition of Ready and a Definition of Done. In deed, for intermediary steps, we will have only the Definition of Ready for the entry step as it is the same as the Definition of Done for the exit step.
Definition of Ready
- To start, the PO has defined the overall objective of the feature.
- Then, first slicing: the PO has split the feature in a first set of user stories with related T-Shirt sizing estimates from the team.
- To finish, the PO has defined specific acceptance criteria at the feature level if any.
DoR for advanced functional tests and change management preparation
- Firstly, built: the team has built all user stories related to the feature.
- Secondly, acceptance: feature meets specific acceptance criteria defined at the feature level for build.
DoD Feature
- Firstly, acceptance: feature meets specific acceptance criteria defined at the feature level for advanced functional tests and change management preparation.
- Secondly, feature End-to-end/Flow Tests successfully ran and passed. Then, the team has tracked test scenarios and results.
- Thirdly, Change Management materials: the team has written or updated supporting documentation.
- At last, Release note: the team has written the release note and has presented it with Q&A to all Squads’ members, the POs and all the key business representatives.
Technical Story for Release Management activities transversal to features
Remaining actions for the Release preparation are transversal to features. Therefore, a technical story will manage them: advanced technical tests, packaging and delivery of the Change Management to end users.
DoR
All features related to the Release are done according to their DoD.
DoR for Release for packaging
- To start, the team has fully and successfully executed the release tests (Performance, User Acceptance Tests). And the team has tracked results.
- To continue, defects: there is no critical defect without agreed workaround.
- To finish, the team has shared a Release Test Closure Memo that includes test executed, results and defect analysis.
DoR for production rollout
- Firstly, the team has built and tested packaging of the release.
- Secondly, the team has communicated the Release note with Q&A to the target population.
- Thirdly, the team and the PO has delivered the Change Management over the target population: presentation of new functionalities or training depending on the need.
DoD
The team has deployed to production and activated the Release package.
What’s next? Learn more about Agile and discover the other changes coming with Agile at Scale
Discover more about Agile and Agile at Scale.
Some changes coming with Agile at Scale that may interest you:
- The change in Project Management
- The change in Project Portfolio Management
- The changes in the roles (Team Manager / Application Manager, Test Manager and IT Support Manager)
Learn also about DevOps and Craftmanship.