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:
- 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
- Acceptance tests
- User's perception of functionality
A product may owner care about
- time to market
- cost to build
- no of resources
- schedule, cost, quality, constraints
- is it estimable?
- return on investment
- burn-rate? did they mean velocity?
- how does this fit in my product strategy?
- competitive advantage
- is it big enough to give me profit?
- 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?
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
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
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
- the purpose of the system
- customers of the sytem
- users, their usage and consequently the value they'll get out it
- 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.