Agile business transformation starts with the adoption of Agile methodology for software development and requires embodying the essence of Agile to achieve real business value. Release planning is one of the most important activities in the software development lifecycle. Traditionally, release planning is done based on effort estimations of the requirements that are signed off during the initiation/inception phase of the project. But in projects where the requirements are at a very high level without enough detail available, it becomes difficult to create a high-level release plan. The process of designing requirements starts right from defining the product vision, culminating in a full-fledged product discovery. But in many cases, the team gets requirements already written in the form of SRS/BRD. These requirements describe what the system can do and not how the user interacts with it.
When the management decides to deliver using Scrum, the entire approach to release planning changes. All requirements need to be converted to user stories that satisfy the INVEST Criteria. Teams starting their Agile journey afresh often face problems while creating roadmaps, as relying on effort-based estimations to chalk out a high-level release plan does not work here. Agile teams tend to lose sight of the bigger picture while focussing solely on delivering one sprint at a time. Individual sprint outcomes turn out to be satisfactory but data gathered from the actual state of delivery of the product backlog items (PBI) is not effectively fed back to the overall release plan. Thus, the release plan gradually gets derailed and this is detected at a very late stage in the project. Hence, it becomes imperative for the Product Owner to focus on the release plan and revise it regularly to make sure it stays true to the delivery goal.
Without a release plan, the stakeholders may not understand the scope of the engagement and future planning becomes difficult. This article discusses a 10-step systematic Agile release planning process to kick-start the brainstorming and requirement elucidation phase to arrive at a plausible project roadmap.
- Identify the users
- Map user journeys
- Identify epics
- Identify themes
- Identify possible user stories
- Create a story Map
- Map dependencies
- Story sizing
- Create a high-level sprint plan
- Identify MVP
This entire exercise assumes that there are requirements available in some form to deliberate over. These requirements may be at a very high level but the stakeholders understand the product vision and can answer relevant questions from the team. It is recommended that the Product Owner, business analysts, Scrum Master, Development team, Solution Architect and other supporting roles like UX and Database Admins be present for these sessions.
The position of step 9 and 10 is interchangeable depending upon what the Product Owner wants to accomplish. Identifying MVP should be before creating a high-level sprint plan if delivering the most impactful requirements first is the priority. If all requirements are relatively high priority and non-negotiable, the team can create the high-level sprint plan first and then identify the MVP from it. This will allow the team to be flexible with their milestones.
The aim of the systematic release planning process and the simple mathematics involved in it is not to create an accurate estimation and date of delivery. The whole purpose of this drill is to get the team and the relevant stakeholders to start talking and brainstorming on the requirements. This creates a shared understanding and heightens the sense of ownership. The number crunching done during Story Sizing step gives a rough estimate of timelines which helps the management to prepare a plan accordingly, and course correct wherever necessary. Risks are identified at an early stage giving enough time to create mitigation plans. Similar release planning activities need to be conducted regularly to tweak the future deliverables based on what was achieved in the previous sprints. This rolling wave planning process ensures milestones are achieved and risks, assumptions and dependencies are cleared as we move along.
With this done, the team can now proceed to complete the remainder of Sprint 0 where the prioritized set of stories identified as Sprint 1 deliverables can be written in detail, culminating in Backlog grooming and Sprint planning sessions. The development team can also now start the technical and solution design based on the renewed understanding of requirements. This eventually paves the way for a smoother transition to actual development. Thus, following this process enables the team to systematically explore requirements in detail and create a high-level sprint plan.