Agile Bengaluru 2010 - Jeff Patton's Story Mapping session

These are live-blogged notes from Jeff Patton's session on Story Mapping which I couldn't upload until late next morning, due to a lack of internet connectivity.

Jeff Patton: Started doing XP in 2000 (ex TW'er). User stories part of Extreme programming at the time, so he has a decade of experience of this thing. Claims to have figured this out only in the last 1 year. From my experience I know Jeff to be one of the most respected analysts in the industry and a name to reckon with in the area of agile customer experience.

Its common practice to use user stories in SCRUM today. 'Everybody touches these user story things today'. Developers, BAs, testers, product owners, what have you.

A lot of responses came out to define User stories:

• Wishlist
• Requirements defined in the words of the customer
• small usable output valuable to the customer
• unit of functionality
• business process to be implemented in the system
• non-functional requirements
• has a notion of value or priority
• a unit of testable functionality

Therefore: "User stories are different things to different people."

So we can't all be possibly right. But we are!

So who is a consumer of a user story?

A developer may need

• implementation details
• small in scope - shouldn't take too much time

A tester may need

• Acceptance tests
• User's perception of functionality

A user may care about whether the user story lets him achieve what he wants

A product may owner care about

• time to market
• cost to build

a project manager may care about

• no of resources
• schedule, cost, quality, constraints
• risks
• is it estimable?

a business stakeholder may care about

• return on investment
• quality
• burn-rate? did they mean velocity?
• how does this fit in my product strategy?
• competitive advantage
• is it big enough to give me profit?

a UX person may care about

• role/ persona we're building for
• user's goal?
• meta-details of the story? a.k.a context
• is it big enough to give me feedback?

By the time we address all these concerns and put all the details in, it becomes a real 'fat' document that perhaps needs a binder to hold! Everyone has a view on what the user story needs to have. Its really easy to abandon good old stories because its not easy to fit all this fluff into them.

Jeff threw out the word 'boundary object'. User stories are a boundary object -- its information that's used in different ways by different communities. Its interpreted differently across communities, but has enough immutable content to maintain integrity. The big challenge is to make user stories all they mean to different people without making them into requirements specification documents.

User stories are still a 'token for a conversation'.

Here's where story mapping comes in. Jeff then started off to demo building a story map and asked the group to come up with ideas for products.

Jeff picked an application for people new in Bangalore to know about auto-rickshaws, destinations, right prices, etc. They called the application - autorickshaw registry. The 'business value' of the application:

• public should be able to use this report behaviour
• police should be able to regulate auto drivers
• the public should be able to get auto-rickshaw information from this site

The benefit for the stake-holders would be:

• police can do their job better - provide more safety (overall better law & order)
• the public sees more accountability for auto-rickshaw drivers

Jeff ordered the story map by putting the persona on top and placing high-level coarse grained scenarios/goals under them and then user story-like requirements under them. This continued for a while with the story map -- with a really passionate customer who just kept hammering her needs onto him. Jeff did his best to facilitate and come up a with a story map. You can take a look at Jeff's blog to know more about the process of story mapping.

The cool thing about the story mapping process is that it tells a story of the system more than an isolated story in a flat product backlog. As Jeff would say, "the new product backlog is a story map". The fact that its attached to a concrete, real persona makes it meaningful. The ordering of a story map often is:

• Business Value (the purpose of the system)
• Personas (the people involved)
• Category of functionality (user activities - cluster of things that people do. eg: ordering and pricing rickshaws, SMS activities)
• Actions performed (user tasks)
• Details for that task

Jeff suggested that we should beware of templates (as a, i want to, so that) - they're useful but shouldn't be dogmas. A story map exactly explains all those three parts without getting caught up in the template.

An important point he mentions is that discussion is crucial to the process -- we can't be getting into a 'feature bucket' without understanding the system, the context and the value it brings.

• Story mapping is an approach to organising and prioritising user stories
• Story mapping shows decomposition and typical flow across the system
• Reading the activities from beginning to end, helps us understand the flow of the system

Product discovery workshops help us understand the product we're building as a story map. These sessions may include discussion on:

• the purpose of the system
• customers of the sytem
• users, their usage and consequently the value they'll get out it

A few things to remember about story maps:

• Building a story map may need a huge open space -- even floor space is cool
• A story map for a reasonable sized system can actually fill a room (can get very, very long)
• Adding tape lines t the wall lets participants organise stories into layers. Each layer makes a release!
• Planning incremental releases can be facilitated as a collaborative event.

It was really cool to see a video of the process from a Brazilian client of Jeff's. Great culmination to his hugely informative session. You can email Jeff for a PDF of the handout for his session. I think you will be able to find them on his website too.