A Recommended Workflow
...this doesn't need to be a clear picture in your mind of mobile app screens or smart watch integrations — it can be conceptual
Before you can actually start building a product, you need to craft a vision of what you see the final product being. However, this doesn't need to be a clear picture in your mind of mobile app screens or smart watch integrations — it can be conceptual. There are many ways to document the product vision, but they are outside of the scope of this guide. Why not try a combination of brainstorming diagrams, lean canvas boards, elevator pitches and mood boards.
In reality, there will never be a final product. You will almost certainly have to change your product and innovate with time. This is where the Agile methodology can help, as it makes it a little easier to change your mind, or pivot. In fact, your originally defined product vision can even change. If you're in the early stages of testing a hypothesis for a startup, your vision may drastically change in six months. If you're re-building an existing mobile app for a client, the vision may not change at all.
Planning is where your story map comes into play.
To start with, you need to create a first pass at your story map from your vision. This can be quite challenging, depending on how detailed your vision is. You should feed requirements into your story map by creating tangible user journeys. For example, if your vision outlines the following:
Problem
When people need the toilet in a public place it can be hard to find a public toilet.
Solution
Provide an interface (potentially a mobile app) to find a public toilet by geolocation, with reviews of the cleanliness
Your journey in your story map could be as simple as Find a public toilet. From there, you can define your steps and stories as outlined in How To Story Map. Keep repeating this until your vision is covered as best as possible. This will give you a skeleton structure of your whole product that is aligned with your vision. Try to start with what you believe are the most important features.
This process can happen over hours or days, and can be done with various people in the team. It's always nice to get stakeholder engagement early, so make sure you don't do this alone. Having said that, sometimes outlining journeys and steps can be done beforehand — bringing in stakeholders afterwards — to contribute to the user stories.
Once you have a full story map, you will need to add some releases
During the development cycle, you will want to re-visit your story map. This can be for many reasons:
Some data suggests that you need to add or remove to a journey or feature
You would like to re-prioritise the order in which your team delivers something
You need to change what is included in an upcoming release
A new requirement comes in from the business
Assuming you have analytics channels set up within your sales processes and product, this can inform your story map. Your story map should be constantly re-visited as new data comes in. The beauty of using release planning is that you can easily define a whole new release across the whole product by just re-prioritising your user stories.
When you are happy with a release, you need to get it into your backlog. From here, your team can size the stories and plan upcoming sprint effectively. The benefit of not having everything in the backlog from the start is that your backlog stays clean, populated only by planned releases. Remember that releases don't need to line up with sprints.
