In the previous post, I described levels of Agile planning, and Release planning is a step that we need to have a tactical and actionable plan for a release. In this plan, it might contain product backlog items including user stories and tasks. The question is how to come up with a release plan without losing a big picture about the product? Thank Jeff Patton for writing the book “User Story Mapping: Discover the Whole Story, Build the Right Product”. As the title, Jeff tells you the whole story of how to build the right product and focusing on the technical of user story mapping.
In this post, I will not explain what is User Story Mapping due to the book has already described very details. Rather I will share how we applied the technique to organize our backlog and come up with a release plan. The way we did might differ from the book guidance but the idea is the same.
Start from high-level Epics, we arrange epics from left to right by prioritization or user flow. That means epic with “must-have” will be on the left and the epic with “could-have” will be on the right. For example, we have Epic 1 and Epic 2 in the picture above. Under Epic1 and Epic2, we break down those epics into features and prioritize those features horizontally from left to right similar to what we did with Epics. For each feature, we continue to break it down into user stories and prioritize those stories vertically from top to bottom. That means user stories with a high priority (must have first) will be on the top. Now that we have a full picture of our backlog from Epic à Feature à User Story and be organized by prioritization from Left-to-Right and Top-to-Bottom.
Now, the team will begin to create a release plan based on the backlog picture above. Starting by creating some horizontal swimlane to describe by Sprints. For example, We have Sprint1, Sprint2, Sprint 3, Sprint4, Sprint5. For Sprint 1, the team has discussed and decided that US1.1.1 and US2.2.1 must be added to the Sprint for development first. And then Sprint2 then Sprint 3…Sprint 5. And the team agreed that the first release (MVP) will be after Sprint 3. And the second release will be after Sprint 5 (for example). That means the first release (MVP) will cover Feature 1.1, Feature 1.2, and Feature 2.1 of both Epic 1 and Epic 2. And the second release will cover Feature 1.2, Feature 1.3, and Feature 2.3 for both epics. In this way, we know for each release how many sprints (time) does it take to be delivered and which features will be included in the release.
Please do remember that the release plan still a high-level plan based on assumptions of the team during the mapping workshop. The team should maintain this picture over time and adjust the plan based on the actual happened during the development progress.