Discover the story, User Story Mapping

A few months ago after giving a workshop Story mapping I was asked by Kenny Baas to help kick start a new project for the Java Young Professional Program @Devoteam. Kenny acts as a mentor for the group while they gather experience at customers and through in-house project like this one.

Although It’s better to have some time in between sessions we decided to make it an all-day event. Due to not being able to map agenda’s over a longer period of time. By the end of the day we should have achieved the goals beneath:

• Get everybody on the same page and talking about the same thing
• Discovering the story behind the wishes and ideas of the product owner (PO) and stakeholders
• Get a backlog ready for the team
• Discover the Minimal Viable Product

The product “DevoTime” that this team is to build, is a time management system for temporary employment agencies.

Creating the back bone by “Talk and Doc”

The PO explains the idea and vision about a product that needs to be developed while the rest of the team take notes. Writing down ideas and key actions about the story and asking only questions to clarify it. Ideas or implementation suggestions should be kept for them self because it would draw away attention from the story the PO is telling. Many engineers find it difficult to stay away from the implementations details and solution minded thinking. It’s a mindset that needs to be developed. Development of the mindset works best with some experienced coaches in either DDD or Story Mapping. When the PO thinks the story is finished and the team doesn’t have any clarifying questions left its time to turn the table. The team starts telling the story by the cards they just created, placing them on a single line on chronologically order. All the cards should contain a verb like “Printing a report” or “Sending reminders”. During this talk the PO gives feedback over the story now told by the team. At this point you will soon discover that although the PO is well prepared the told story was not complete, and will never be. Whenever a gap is found a new card is placed on the back bone. After a while you have your backbone, telling the story of the product by actions that it should be able to take and in the process a ubiquitous language is emerging.

Creating Persona’s

Important is to look at your product from different views by playing a “What if game” or by creating persona’s. By writing down the different persona’s, you can relate to why somebody wants a feature. Walking by the backbone the team discusses and maps which personas should have an interest in the action on the card. This comes at hand later on to remember the action’s context. Place these persona’s on the wall and make them easy to identify by using avatars.

For example:
Developer temporary employment agency Bio: Writing hours is an evil necessity. Forgets too often to turn in on time. Always connected, mostly by a mobile device.

Goal: …

Creating Themes

The entire back bone can be quite large and often you will run out of wall space and that is a good thing. Now it’s time to find the theme’s that groups these actions taken, this helps you put the actions in an even better context and is more easily referred to. Place the themes above the actions on the backbone they are related to.

Extracting the Minimal Viable Product

By now you are probably aware that this product can never be created at an instance. You need to decide together with stakeholders and PO’s to what is the MVP. Place a line or a marker on the wall and move all actions that are not absolutely necessary to be implemented at the first release down the line. You can ask yourself questions like “A reminder system would be nice, but I can still administer hours and use Excel provide reports to management until that action is implemented properly later on”.

Creating the user stories

Now you can focus on the User stories that need to be implemented to support the actions talked over all day. You know the different persona’s interested and the reason why. By dividing the group it’s easier to cover the ground of the backbone. Writing the basics of the “As a <Role> I want to <Wish> to help me <Reason>” and map that to the backbone. Any story created will be refined later on together with the PO.

Finishing the day

Because the wall we used was in a board room we claimed for a day, we needed to administer the work beside taking pictures of the wall. The next day there were other meetings scheduled and there was no certainty that the wall would be in the same state the next time the team collaborated. Another reason is that during development you want a tool supporting you working with geo locations or managing changes. I always prefer a physical information radiator but in this case we decided to support it with Team Foundation Server. With the addition of the extension Persona giving us the possibility of mapping the created biographies to work items by the use of tags.

The mapping on the board is as follows:

Themes => Epics
Actions => Features
PBI => PBI

After a hard day’s work the team managed to succeed on all goals, learned to speak the same language and has a clear vision on what should be included in a product and what not. But most importantly what the story behind the product is. Next time they start they can pick up with the PBI’s refining it and continue with the DDD implementation.

Even though we reached our goals it’s important to maintain the information radiator, constantly updating it when you find new stories behind the product. Maybe you want just some small cards with titles and numbers referenced to TFS work item-id’s. I know it feels like double administration but it’s worth the hassle to have it in your face all the time and to use it for insights in forming the boundaries of your DDD.

For more information about story mapping see: User Story Mapping, Discover the Whole Story, Build the Right Product. By Jeff Patton

Try it out, till next time. Erick Segaar