In this blog, I share an example of a real-world, agile enterprise modernization project that benefited from a User Story Map.

I’m the team lead for a project to convert a business solution from COBOL to a .NET microservices architecture. Other than some interesting challenges with designing a robust microservices solution, the business logic is very straightforward – input files are processed, databases queried, output files are produced and dropped in a folder, and our goal is to match the output produced by the COBOL solution perfectly.

Yet, we lost our way fairly early on in the project because we had a typical prioritized backlog.

Our project team is serious about adopting Scrum as its process for agile. New members to the team attend a full day of agile training and the organization keeps agile coaches on staff to support the teams and coach them on their practices. The business users, who are our customers, attend every daily stand-up, planning, grooming, and demo and help us navigate our course through the project.

We created the project backlog, which covers the whole project in our first few weeks of ramp-up. The team is engaged and discussions are lively; it’s really an incredible feeling to be part of a project so healthy. Still, none of us can recall what’s all in the prioritized backlog and how the stories might relate to each other. We just can’t hold it all in our heads.

And that’s why even on a straightforward, well-defined project with an engaged team, we still managed to veer off course.

Sailing Out of a Bay

I like the analogy for developing software that says it is like sailing out of a bay. You can’t sail directly to your destination without tacking and jibing to correct your course. In agile, you make small corrections every day at stand up and larger ones every sprint at planning, demo, and retro. Even when your destination changes, you can adjust your course to compensate.

In the worst of waterfall projects, you sail for a year without ever noticing your destination actually moved and you struggle to even make it to where you wanted to go in the first place.

To extend that analogy, a prioritized backlog is like having a log book to tell you where to go, but no map. You can definitely still get to your destination, but you will probably stray off course a little more. If you took those words from the log book and drew a map to help you remember their meaning, then you will have an easy reference for everyone on the ship so that anyone can notify the crew when the ship is off course.

Losing Our Way

On our project, it was around three or four sprints into the project when we started to lose our way, at least according to our original plan and according to the agile concept of building just enough of the system that it works end-to-end.

As a group we made a decision to focus on two core services in our five-service architecture. It wasn’t a bad choice, it made sense to everyone and we all agreed to it. In retrospect though, this is when we deviated from our plan of being able to run a file through the whole system end-to-end.

Then, around four or five sprints into the project, we lost sight of what was actually in our project backlog and how it related to what we were working on. It had been months since we created some of those stories and some were now duplicates or unnecessary.

Our project manager started asking questions about where we were in the project and where we were going. I struggled to answer those questions because I couldn’t make sense of all that was in our backlog. It was around this time that I took a spreadsheet and created our first User Story Map.

User Story Map

A User Story Map transforms your columnar backlog into a multi-column story of your project from left-to-right.

Every project maps a little differently, the columns can be steps in your process, the user roles for your product, how your user interacts with your product over a life time, or major components.

In general, nearer to the top and on the horizontal axis, you have a barebones, but usable, version of the product. These are the high-level requirements you would include in a Minimum Viable Product.

Going down the vertical axis, the successive rows will show the additional functionality or features, prioritized for importance.

For ours, I made a column for each service and underneath put the prioritized stories for that service. I could then plainly see there were duplicate and unnecessary stories. I could see how much work each service still required.

User Story Map Example

And, most importantly, I could now see the map of our project. I realized we needed to change course to work more on the services we had been neglecting so that our system could be tested end-to-end.

The team decided that changing course was a good idea, so we made the necessary changes and the project headed in a better direction. Our story isn’t over yet, but we are now able to test our system end-to-end even though the services between aren’t fully hardened or production-ready. But, that’s exactly where we need to be right now; we are back on course.

It has been a few more sprints since I made that first story map and it has already become inaccurate enough that I cannot rely on it.

We are using Visual Studio Team Services for our stories, but it does not do story mapping without an add-on like SpecMap, which I haven’t tried. On my personal projects I use StoriesOnBoard, and it has been delightful to work with. For now, I will need to manually update my map and share it with the team so that everyone can benefit from having more than just a prioritized backlog.

Further Resources

Thank you for reading.

If you would like to learn more about User Story Mapping, I encourage you to check out the books and other resources on Jeff Patton’s website, who wrote the book on User Story Mapping. I particularly like this blog post!