The user story template helps us build the right thing by identifying why we want a particular capability in the product we are working on.
As a <blank>
I want to <blank>
so that <blank>
Interpreted from a benefits modeling perspective and mapped directly into the structure as it stands, the template is
As a <stakeholder>
I want to <be able to perform or have performed some enabling action>
so that <I get some specific benefit>
The order seems odd to me, that is, identifying the enabling action before we identify the benefit. Most businesses drive initiatives from benefits first, and determine the most appropriate actions second. Maybe it should be
As a <stakeholder>
I want <this benefit>
so I need to <be able to perform or have performed some enabling action>
The best place for this kind of thinking? In the project charter – the vision section. Why have a vision statement when you can have a whole set of benefits and enabling actions? The fit nicely into the concept of story mapping too:
As a <stakeholder>
I want <this benefit>
so I need <this user story>
Now that’s a vision worth sharing.
2 comments:
Have you tried using Effect Maps (see http://gojko.net/effect-map/) and the alternative user story form (credited to Chris Matts):
In order to
As a
I need
Yes I was one of the reviewers of the book and was thinking along those lines ... love effect maps. I wanted an even greater emphasis on benefits realization to be alongside either an effect map or a story map.
Post a Comment