People often mistake User Story Mapping as a tool to start projects, but it is entirely suitable for building up an old project or design.
When looking at your application it is easy to first create User Story Map based on the products functions.
Establish the tasks, the goals and flesh out the map. Sometimes you may taken things for granted and forget certain tools of the application are actually tasks so it’s a good idea to bring in people from other teams to help identify all the functions of your project.
We once took an old tool and needed to update the codebase, as well as introduce new features and improvements.
A few options may be available to you, depending on the code. Are you able to update the tool in sections? Are you able to approach the update in sprints/versions? Do you need to rebuild the entire program from scratch?
We first built the map of our tool, you can see below our “Moviebuddy” example.
We then worked through identifying which sections were redundant. We identified these and added them to a new column to the side. Essentially removing them from view.
We then talked out and identified which parts of the code would be updated and what we could do first. We labelled this as version 1 and aimed to get the core functions updated.
We were able to identify one function which we were able to upgrade. We also added new cards which reminded us to update our code standards and highlighted them green to ensure they were completed.
We then moved along to the next version which allowed us to introduce our new payment gateway to the application. A function that had alluded us due to the old codebase.
This allowed us to deploy more frequently and provide value sooner as we updated sections of the site. We still had a lot of ‘old legacy code’ but as we added new features we moved the legacy code functions inline with our updates.
As you can see using User Story Mapping can be brand new projects, or old existing projects.
Moviebuddy is all fictional for the purpose of training.