Plan Releases

Finally, teams must create a plan for releasing the application. The release plan shows the order in which requirements will be addressed along with an expected schedule. The plan should be high level, so that the team can adapt to new information during the project, but should clearly forecast what the team expects to deliver in the next 3-6 iterations (ie. 6-12 weeks).

Step 1: Devise an incremental release strategy 

The plan should deliver value to stakeholders quickly. To do this, decompose the full scope of the application into subsets that can be released incrementally, with the most valuable subsets released quickly and additional functionality delivered in frequent follow-on releases. This approach maximizes the project’s impact by getting value to the business faster and minimizes risk by allowing feedback from early releases to be corrected quickly.

Key Insight: Prioritize the backlog based on goals

Selecting the right first release relies on the Product Owner to prioritize the application’s features. However this is often a difficult task when most of the requirements of an application are all seemingly important to getting the job done. In order to make this easier, teams can use a framework called Impact Mapping. With this method, teams map each major feature to one of the project’s goals, showing the impact implementing this feature will have on the goal. This allows the Product Owner to select those features that will have the greatest impact on the project’s goals.    



Step 2: Create the Release Plan

Because our Build process is iterative, detailed planning is done with each iteration and only locks teams into the next 2 weeks. This allows teams to adapt to new information or demand. However, we also recommend creating a Release Plan to provide stakeholders a longer term forecast. This Release Plan is a high-level, adaptable plan that forecasts what will be delivered in the next 3-6 iterations.

To create the Release Plan, we need two things: 1) the size of each backlog item represented as story points and 2) the team’s velocity, or the number of story points they can complete in an iteration. Teams estimate enough of the prioritized backlog to finalize the release plan and then communicate the plan to stakeholders.

Resources

Previous Next
Related
Recommended