Sunday, November 13, 2011

StoryMaps - Let's talk about it

OpenSpace Session at ALE2011 Unconference at 7 Sep 2011 in Berlin
Conveyor: Christoph Oberle, christoph.oberle@online.de, @OldAgile

Participants

Eelco Rustenburg, Yves Hanoulle, Arne Roock, Mads Troels Hansen, Alexis Monville, Rachel Davies, Marco Bontempi, Antti Kirjavainen, Claus Malten, Ivan Kostial, Michael La
usegger, Franck Depierre, Christoph Oberle and some other

Summary

At the Agile Lean Europe 2011 Unconference in Berlin in the Keynote of Rachel C. Davies she mentioned the concept of StoryMaps. To learn more about this I proposed a session for the Open Space titled “StoryMaps – Let’s talk about it!” In this session we lea
rned a lot about this method to structure UserStories in more than one dimension and about the process, how to use it. In addition we shortly discussed the way to find the needed UserStories starting from the Vision, using Goals and Personas. The methods shown here are used in the community for a while, but apparently nobody has described them together until now. As a follow-up of this session a StoryMap example was given by Eelco in another OpenSpace session at ALE2011.

Two-Dimensional UserStory Splitting

Our first question was, who can tell, what StoryMaps look like.

They are two-dimensional arrangements of UserStories which somehow belon
g together.

Eelco prese
nted this picture:

It shows the StoryMap for one bigger UserStory (or Epic). In the upper left corner the Epic is shown. In the horizontal dimension the decomposition of the Epic into functions is shown. So looking at the columns in the matrix, the Epic gets more and more “fully functional”, if you include more columns from left to right. In the vertical dimension the decomposition of the Epic according to some classification of the features is shown. E.g. the first row (or slice) could be named “working skeleton”. Here the UserStories for those features are shown which together define the minimum set to get a working prototype. The second slice could then be named “ready to go live”. Here those UserStories are put, that contain the features, which have to be added to the “working skeleton” to make it a shippable product increment. The third slice could be named “wow!” and contains those UserStories which would implement the exitors, the features which make the product competitive and exiting for the users.

With this decomposition of bigger UserStories into sets of smaller UserStories it is possible to get a common understanding about the functions, which are part of this bigger UserStory and about the features, which have to be part of the product increment. Especially the positioning on the vertical scale can be difficult and can be a fast method to surface different opinions about the need for some feature.

In the beginning of the development for an Epic the “working Skeleton” slice is the natural candidate for the first set of UserStories to be offered to the team by the PO. Then perhaps the “working skeleton” for another Epic plus some UserStories from the “ready to go live” slice of the first Epic can be offered to the team by the PO.

This means, after defining the StoryMaps for the Epics, the resulting UserStories are put into the (one-dimensional) Product Backlog (PBL) and prioritized by the PO.

This decomposition of bigger UserStories can be used whenever the size of a UserStory in the PBL is bigger than what can be handled in the sprint. After the decomposition, the resulting UserStories are put back into the PBL.








Silent Techniques for Positioning UserStories in the M
ap
To populate this two-dimensional representation with the UserStories silent techniques can be used (similar to the
Magic Estimation method to estimate the size of UserStories, read here: http://campey.blogspot.com/2010/09/magic-estimation.html).

Example: For every function of the Epic the decomposition into User
Stories according to features is done.

Then in a first phase of 1-2 minutes everyone puts his UserStories in the column of the described feature and chooses the row where he thinks the UserStory belongs. This is done silently without discussion.

In a second phase of 1-2 minutes everybody looks at the whole map and repositions those UserStories where he thinks they are not at their right position. The facilitator watches the process and sees, for which features a follow-up discussion is needed.

From Vision to Epics
The second question we discussed was “How do we find those Epics or bigger UserStories?”
What is the process to come from the Vision to the Epics?

Ulrika has drawn this picture:


At the top you see the vision.
From this vision you define some goals that have to be reached and arrange it on the timeline (e.g. for the next quarters of a year).

The next step is to assign Personas to the goal and then find the UserStories which will reach the product goal for this Persona.

Those UserStories at the bottom of the picture can then be decomposed with the StoryMaps (see above).




Conclusion
We have got an overview about the concept of “StoryMaps”.

We agreed that it is a useful tool to have conversations about the decomposition of bigger UserStories with the stakeholders.

We have talked about methods for facilitation (silent techniques).

We put it into context with the process to create UserStories coming from the Vision.

We discussed the mapping from the (two-dimensional) StoryMaps into the (one-dimensional) Product Backlog.

It was a great session! Thank you for participating!

Addendum
In a private mail one of the participants told me about his experiences:

"... I could already use this approach with great success (means fruitful discussion). However we have used different dimension on Y axis, it worked very well - in our current situation the certainty (Clear, Clear BUT, To Be Clarified) was better description than releases.

What I find nice on this approach is the binding of user stories to certain features. Doing this one brings more information about the user story context without the need to write it down on every card. The whole discussion is than much more focused and always in particular feature context - not wild wide without end. :) ..."

No comments:

Post a Comment