Breaking a Complex Solution into Multiple Releases using User Story Mapping

Imagine you’re working on a team and you get a requirement to add a new expense tracking feature. The prototype has received rave reviews and the internal teams are really excited to start saving time on the monotonous receipt submission process. However, there is a significant challenge.

There are requirements for OCR scanning of receipts to pull out relevant information, receipts are to be automatically categorised based on a set of complex business rules, the approval process has multiple steps, it needs to integrate with the finance system and the reporting requirements are complex.

The prototype used "smoke and mirrors" for these complex area, with default values for the scanning, categorisation and reports. Expectations have now been set with the users.

It is going to take weeks to develop the full solution. You could launch into a large project but as a team that recognises that 90% of features fail to deliver the expected value, you decide that you need to break the full solution into multiple releases so that you can validate your direction as you go.

Introducing User Story Mapping

User story mapping provides a structured approach to breaking down complex systems into manageable releases while maintaining focus on user value. This technique visualises the different features of a system, from the perspective of the users, which helps to maintain a customer centric focus while deciding on the most important features to build first.

User Story Map Backbone

The first step is to identify the high-level user activities that represent the core user journey.

Level 1

It is important to keep the backbone steps to a minimum so that it can be easily understood and communicated. The problem though is that the backbone is too high level to be useful for planning and prioritisation. We need to flesh out the high level activities with more detailed journey steps.

Mapping the Stories

With the structure in place we are now ready to map out all of the user stories that we need to build the system. There are actually three distinct actors in this system: the user who is submitting the expenses, the admin who is reviewing expenses reports and the system automations. We can use swim lanes to separate out the stories for these three different actors.

Splitting Stories into Releases

The next step of User Story Mapping is to split the stories into distinct releases. This is where the real complexity comes in, because you will get push back on delaying any of the features. Stakeholders will argue that everything is critical.

Let’s discuss some of the objections that you are likely to face.

Objections to User Story Mapping

“We’re a premium brand, we can’t release a half-baked product”

Quick does not have to mean cheap. You can still deliver a high quality product in a short time frame. The key is to focus on the core features that deliver the most value to the user. The MVP (Minimum Viable Product) name has been so tarnished by low quality releases that a lot of people don’t like to use that label anymore. We should use Minimum Lovable Product (MLP) instead because it highlights the need to deliver a quality product that users will love.

“Our feature doesn’t work unless every piece is in place”

I don't think that people are necessarily being difficult. I've been there before myself, adamant that every requirement was critical. One of the biggest challenges in software is battling the vision for your product with the reality of what you can deliver. The truth is every feature can be broken down into smaller pieces. It just requires a different way of looking at the problem. The good news is that this is a skill and it can be learned.

“You’re just going to stop after release 1”

One one team I was working on, the end users were great to work with. But every time we had a Steering Committee review they slated our progress and said it was not working for them at all. After the second time this happened we took the manager aside to ask what was going on as it was not a fair reflection of the work being done. He was worried that if he said everything was going great we would be moved off and he would be stuck with the current state of the product. This was his way to keep the focus on his area, even if it came at our expense.

This is a genuine risk because if our first release delivers enough value the business might decide that they don't need to invest any more in the product. While this might be painful for the users looking for a complete solution, it is a good thing for the business. It's up to the team and the stakeholders to argue for the ROI of continued investment.

“This is inefficient. It’s cheaper just to do a single release!”

In the past the cost of releasing was very high. It often involved manual testing cycles and manual deployments. But DevOps practices with Continuous Integration and Deployment have reduced the releasing costs to effectively $0. This might not be the case in your company, so if releasing is still expensive and time consuming you should start there before trying to split releases.

The other half of this argument is that the future requirements could change the design of the solution. If we only build the requirements for one release we’ll need to do unnecessary rework in future releases. What this argument is missing is that build costs are just one of the costs that we face when building software. There is also maintenance costs, opportunity costs and holding costs (the lost revenue that we could have earned if we shipped sooner). Depending on the outcome of our initial release, we might not build the more complex solution which would save the company a lot more money.

How Do We Decide Where To Split Our Releases?

Breaking down the problem starts with understanding users, analysing the market, and addressing technical challenges. Here’s how to approach it:

Who Cares? Understanding Pain Points

There are a lot of different people who can take advantage of an expense tracker, but there are also people who will receive a lot more value than others. Here’s an example quote from one of the sales managers that the team captured during research.

“I spend hours at the end of each week manually filling in expense reports. With a team of 50 sales reps in my division, that’s a huge amount of wasted time and money.”

As soon as we have something that is better than the manual process that the sales team are using now, we should release it to them. We can continue to improve on the system over time to make it even better but we need to get it into their hands as soon as possible.

Differentiation — Build or Integrate?

There is a phrase in software development: Not Invented Here. This is the belief that a team can build a better solution than what is already available in the market. Most of the time people underestimate the complexity of the problem and the amount of time it will take to build a solution.

Before diving into development, teams should consider existing tools. This could include either complete products like Accounting Software extensions or APIs that can be leveraged to speed up delivery, such as OCR technology.

Wardley Maping is a great technique to help understand which parts of the solution are commodities that teams should outsource and which are the differentiators that they should build themselves.

Splitting our Expense Tracker Releases

Putting it all together we could end up with a map like below. I say “could” because putting together a map like this depends on what users really care about, what technology you already have in place and the skills of the team.

Our first release is very manual with no automated OCR recognition, no automated categorisation of expenses, no automated validation of expenses against policies and no reporting. What it does have is the ability to upload photos of receipts and having a centralised place for submitting reports. Even though it is basic, it will save the sales team a lot of time.

Our second release can then focus on speed improvements: better categorisation of expenses, report completeness validations and some of the most important reports.

Finally, in future releases, we can add the complex OCR automation as well as integrations and more complex reports.

Conclusion

Breaking down complex problems requires a systematic approach that balances user needs, technical constraints, and business value. Through user story mapping, we can transform overwhelming projects into manageable, value-driven, quick releases.

The result is faster time-to-value, higher user satisfaction, and better alignment between development efforts and business needs.

Even if you are still planning to release in one big bang, I highly recommend doing a User Story Mapping exercise as it will help drive interesting conversations and help the team understand the problem space better. Happy mapping!