Release planning is one of the most important activities in the software development life cycle. Traditionally, release planning is done based on effort estimations of the requirements, which were signed off on during the initiation/inception phase of the project. But in projects for which the requirements are at a high level without enough details, it becomes difficult to create a high-level release plan. The process of designing requirements starts from defining the product vision, culminating in a full-fledged product discovery. But in many cases, the team receives requirements written in the form of software requirement specifications or a business requirements document. These requirements describe what the system can do and not how the user interacts with it.
Release planning under Scrum
When management decides to deliver using Scrum, the entire approach to release planning changes. All requirements must be converted to user stories that satisfy the INVEST criteria. Teams starting their Agile journey afresh often face problems while creating road maps, because 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 focusing 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 is not effectively fed back to the overall release plan. Thus, the release plan gradually gets derailed, which is detected at a late stage in the project. Hence, it's 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.
10 steps to systematic release planning
Without a release plan, stakeholders may not understand the scope of the engagement, and future planning becomes difficult. This article discusses a 10-step systematic release planning process to kick-start the brainstorming and requirement elucidation phase to arrive at a plausible project road map.
- Identify the users.
- Map user journeys.
- Identify epics.
- Identify themes.
- Identify possible user stories.
- Create a story map.
- Map dependencies.
- Size stories.
- 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 high level, but the stakeholders understand the product vision and can answer relevant questions from the team. I’d recommend that the product owner, ScrumMaster, development team, solution architect, and other relevant stakeholders, such the UX and database administrators, be present for these sessions.
The positions of step 9 and 10 are interchangeable, depending on what the product owner wants to accomplish. If delivering the most impactful requirements first is the priority, identifying the MVP should come before creating a high-level sprint plan. If all requirements are relatively high priority and nonnegotiable, the team can create the high-level sprint plan first and then identify the MVP from it. This interchangeability allows the team to be flexible with their milestones.
Purpose of a systematic release planning process
The aim of the systematic release planning process and the simple mathematics involved 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 a heightened sense of ownership. The number-crunching done during the story sizing step gives a rough estimate of timelines, which helps management prepare a plan accordingly and then 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 future deliverables based on what was achieved in the previous sprints. This rolling-wave planning process ensures that 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, in which 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 without resorting to effort estimations.