Prerequisites:
Product features are mostly known, but requires prioritization.
Customer journeys for the desired future (new product) are known.
For a new business idea (untested customer benefit): Customer research has reached a point of diminishing returns where you simply need to build a prototype to move forward with customer feedback.
Upgrading your existing product (incremental customer benefit): Most requirements are known where we are supporting the upgrade of an existing, saleable product.
What?
A story map is a visual tool that translates the customer journey and product requirements into the agile software development process.
A story map is a team contract between the business and engineering team.
Why?
Ensures the entire team is aligned to ship the most important features first.
How?
Product managers and the engineering team take their customer journey and break it down into epics, which are actions or features that your customer uses while using your product.
The team breaks down a single epic into 'user stories', which are the smallest, independent units of work. (You can google what user stories and epics are).
The priority of work begins from the most left epic of the story map, starting with the first stories from top to bottom. Each epic and corresponding stories to the right is of lesser and lesser priority.
As customer journeys and feature lists can be quite extensive, a story map should begin with the simplest version of the customer journey that could be shipped i.e. a product with a minimum number of features that can be shipped for the purpose of getting feedback or testing assumptions, but not necessarily saleable or valuable.
As the product is shipped regularly with more user feedback received, then the team can add or re-prioritize features via the story map, until the product has a minimum number of features that would make it saleable and valuable.
The story map is a living document.
Story mapping is done at least once a sprint as part of the agile development process.
The story map does not have a timeline (kind of).
Prerequisites
You have quantified the development pace (or sprint velocity) of your team.
Eventually, the team will create an extensive list of features as part of a rich user experience; however, you want to get your product to market as fast as possible, and it's simply not feasible to ship all your features at once.
Release planning is simply the prioritization of features such that your product has enough value to gain traction as soon as possible. It is also possible that a valuable feature needs to be pushed to a later release due to technical difficulty and market timing; however, a lesser product is enough to gain feedback or sales.
How?
Releases are separated by groups of prioritized features that are shipped together.
Each release has a timeline estimate based on your knowledge of your team's development pace.
Releases are derived from story mapping.