How can Story Mapping be used for product backlog creation

The Product Owner may have very firm and attractive vision of his product, however it takes number of steps prior to creation of Product Backlog Items that reflect this vision. During this workshop Scrum Masters and Product Owners will learn how to use Story Mapping to understand the product as whole, what is the most important and valuable functionality, what makes it attractive for customers, what can be goals for consecutive releases.

When: Thursday, November 9, 5.45pm
Where: Plus Jeden, Za Bramką 1 in Poznań, 1st floor
Language: In case of having non-Polish speaking attendees, the workshop will be held in English.

The Product Owner may have very firm and attractive vision of his product, however it takes number of steps prior to creation of Product Backlog Items that reflect this vision. It becomes a challenge with complex products, especially the product that already exist and was developed for years.

What kind of solution would be the best answer to business needs? What are possible options to choose from? What features to start with? How can we effectively use our advantages? What are the dependencies to deal with? The Product Owner should be able to answer these questions. The Scrum Master must be able to help answering them.

During this workshop Scrum Masters and Product Owners will learn how to use Story Mapping to understand:

  • the product as whole,
  • what is the most important and valuable functionality,
  • what makes it attractive for customers,
  • what can be goals for consecutive releases.

Summary:

Since the meeting was held in English, so will be the summary :smiley:

As usually, Bartek Juszczak did a short introduction to the topic and said a few words about our guests who made all the way from Cracow to talk to us about user story mapping and how to use it for product backlog creation.

Andy and Rafał started right away with some basic but essential theoretical knowledge on the method. They explained it step by step on a simple example – a web application enabling to book a hotel room. The process of creating a user story map for this system was clearly shown on consecutive power-point slides – a quick way to help get the idea (“show, don’t tell”).

We learned that there are usually three levels of details for such a map. To start, we can (but don’t always have to) embrace a particular perspective, e.g. the client. The mapping began with big “activities” that a user would like to perform in the app, such as “search a hotel” and “select offer”, written on blue boxes and put in chronological order horizontally. Those were then divided into smaller actions (steps) represented on green cards, again following chronological order. For instance: the search criteria: city, dates, persons; search results and sorting, selection etc.. The last level contained details describing how exactly those steps could be performed. The order here was from the simplest on top to the most complex on the bottom.

After that, we moved to the second part of the meeting during which we participated in the process of creating a user story map. This time the application to build was a taxi ordering system. The workshop part was very well prepared and conducted: we were divided into groups of 4-5 persons, each group received a sheet of paper with assumptions and instructions to take into consideration. Every group was supposed to analyze the activities, steps, and details from a specific point of view: taxi driver, dispatcher, client, accountant… There was obviously a timebox, too 😉

When we were quite done (“Can we have like 5 more minutes pleaaaase?”), we began to physically create the map on the wall. We started with what we thought to be the blue cards – most high-level activities. There was a lot of confusion with combining different roles points of view, but we were skillfully guided by Rafał and supported by Andy’s comments on our activities, decisions, and doubts. When we started to map lower-levels cards, we often had to change a card’s category (level), rephrase it, specify the type of user or add steps and details that we hadn’t come up with earlier.

Once we finished, we had another piece of theory: this time it was about using the map to plan releases. Rafał and Andy familiarized us with the concepts of “walking skeleton” and “minimum viable product” (Bartek Juszczak proposed also a “minimum marketable product” definition). With this knowledge, we returned to the map and tried to slice it in order to get a “walking skeleton” and an “MVP” version of our product. This exercise raised a lot of interesting conclusions and questions which the guests willingly and abundantly answered.

Personally, I feel I learned a lot about the user story mapping, and I think I will finally dare to conduct this activity in my company.

Summarized by Ewa Wiktorowska

Slides from the presentation: Agile Poznan 2017-11-09, User Story Mapping

Andy Brandt Code Sprinters

Bio

One of Poland’s most experienced Agilists. He trained more than a thousand Scrum Masters, mentored many prominent Agile Coaches and trainers in the community and consulted numerous organizations helping them use Agile better. Author of the popular “Agile w praktyce” book and “Andy Jedzie” vlog.

Rafał Markowicz Code Sprinters

Bio

An Agile Coach and a Scrum Master with more than 10 years of experience in Agile, participating in IT projects since 2001. He is an Agile practitioner working with (and often within) development teams. As a Trainer he teaches Scrum and other Agile methods, he conducts trainings teaching techniques such as test automation, BDD and Specification by Example. Rafał remains an active developer specializing in test automation and quality assurance. He holds PSM-I, PSM-III and SPS certificates. On behalf of Code Sprinters, Rafał helps organizations in transformation to Agile.