In software, building the thing right is easy… identifying the right thing to build isn’t!
“The issue of the flat backlog”, by Erik Poels
Anyone who has ever worked with software knows how complex these integral systems can get. To keep track of all the changes and to make sure inter-dependencies are still intact after releasing an update is hard, even with a fairly small application. We write down the work that needs to be done in a so-called user story. This format helps to perform a task and clarifies the context of what we need to accomplish.
Starting off with the first few user stories is usually easy and the whole team knows what the expected functionalities are within the newly designed system. It gets more difficult when the amount of user stories starts to grow and everybody involved slowly loses track of the complete system. This is also called the issue of the “flat” backlog. Even when the product owner still has this vision of the final product, it’s hard to communicate where everything fits within the system. Luckily there is a way around it. Jeff Patton even wrote a book about it called ‘User Story Mapping’. This is a pattern that describes the way user stories are organized in a big matrix. It contains the complete picture so everyone has a complete overview and all the tasks are ordered from left to right. (Read this book, it will really help you understand how user story mapping makes growing your product a lot easier for your team).
User Story Mapping solves a few major issues relating to the traditional use of a backlog:
Ideally, a User Story Map is created before the actual production starts and helps to convert the vision and the goal of the project towards individual tasks for the different users of the system. After defining this high-level overview of the system, it’s time to bring in the experts and stakeholders. Bringing in all those people will feel as a big investment and you want to make sure this is the right thing to do. The most important thing you will accomplish by doing this is getting everybody involved in the production, with valuable input, fresh ideas and sometimes even major changes that will benefit the system.
After the creation of the User Story Map the scrum team focuses on the parts that need to be built in the next few weeks. During these ‘sprints’ they discuss in detail every solution that will fit the user story, so they pick the most effective and satisfying one to finish the job. This collaboration between the product owner and the scrum team will enhance the quality of the final product.
Mandatory Literature
User story mapping is a valuable tool in software development. This insightful book examines how this often-misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features. Author Jeff Patton shows you how changeable story maps enable your team to have more clear communication about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why.
We are software “architects, analysts, techies and designers” and throughout the years we’ve created a pragmatic and creative approach to identify the right problems to solve before you start with the development of the bits and bites. No long research studies, no thick reports but 4 clear steps to success.
Are you solving the right problems, or are you making software that nobody asked for?
Get in touch, we’d love to hear from you.