Think of a User Story as a short-story that a user will be able to tell about what they want to do and why they want to do it. It’s not the feature the product will have or the actions they’ll perform, it’s what the user will be able to do — as in achieve. One story may actually mean subtle or significant changes to multiple features, involving several actions.
“Stories aren’t a different way to write requirements, they’re a different way to work” -Jeff Patton
User stories are a paradigm shift, a different way of working. Jeff Patton explains this superbly in slides 1–50 of his User Story Mapping slides (I highly recommend you flip through them). Jeff highlights that “Stories aren’t a different way to write requirements, they’re a different way to work”.
The misunderstanding that User Stories are just a different way to write old-style software requirements has contributed to continuous deterioration in how the Connextra template is communicated across the industry — changing User Stories into product features (or user action within a feature). Product features and actions within them generally describe the product (not the problem)… again, like old-school requirements.
“A further problem with requirements lists is that the items on the lists describe the behavior of the software, not the behavior or goals of the user” –Mike Cohn, User Stories Applied (2004) Addison Wesley
Unfortunately, the problem wasn’t with the Connextra template, it was with widespread misinterpretation of it. This misinterpretation propagated so far and wide, that many teams now experience the problems caused by slicing work into product features (problems that User Stories are designed to solve). And now people are saying — “User Stories are broken!” and “the Connextra Story Template doesn’t work”. Clearly, comparing apples and oranges, much like in the opening story.
The Connextra template does work, if you are actually working with User Stories. The wording of the original template highlights the who, what and why from the user’s perspective:
As a <someone>
I want to <do something>
So that <some result or benefit>
This helps us start the right conversation; exploring the short story a user could tell about something they’ll be able to do — hence the term ‘User Story’. The “As a…” helps us start empathizing with the user. The “I want to…” gets us thinking about what they want to do (not how they want to do it). The “So that…” get us closer to their motivation — why they’d want to do this.
Unfortunately, many people mistook User Stories to be just a different way to write requirements — which they’d always expressed as features & functionality. In their efforts to help colleagues and peers understand user stories in the same way, several people began sharing this template:
As a [role]
I want [feature]
So that [benefit]
Many teams found that whole features were too big to implement in a short enough window, so we also saw a variation on this where the interactions within the feature were described:
As a [role]
I want to [action]
So that [outcome]
Others sticking with the larger feature model, asked about the ‘benefit’ part — what’s that for? Is it the benefit to the user? If it’s about the user, then where do we ‘document’ the business benefit? The question of ‘value’ and ‘business benefit’ was seen to be missing so we started to see:
As a [role]
I want [feature]
So that [business benefit]
People didn’t always know what the specific business benefit of a feature was so they started writing “As a… I want ” and left the “So that…” part out. So, a different format was put forward to encourage thinking about the business benefit and we ended up with a catch-all for feature or action — “functionality” — plus the business benefit as the opener (which became a confusion between what the business wanted and what the user wanted):
In order to <achieve some value>
as a <type of user>
I want <some functionality>
Whether it was the intent or not, I believe that these variations make it easier for teams to think they were working with User Stories when in fact they were simply capturing product-features and business-benefits like old-style software “requirements” – only dressed in a User Story like template.
User stories are about the user — hence the name. It’s a way of working, not a way of writing requirements. This is an area we all need to get better at explaining.
What we write on the User Story card (or electronic equivalent) using the original Connextra template helps us start the right conversation about users’ needs, slicing by value to the user. Starting the right conversation to slice by business value is a different problem.
The original Connextra template works just fine for User Stories that tell a story about the user. The template wasn’t trying to fix the mindset of slicing-by-feature. Books like User Stories Applied were there for that. The misconceptions began when people assimilated User Stories through product-feature-biased filters and tried to ‘fix’ it — rather than question their own understanding.
This left many teams with “features dressed as stories” caused by a fundamental, yet common, misunderstanding. Who knows, I may have once shared in that misunderstanding myself. Now, we have an opportunity to change this by learning more truths about User Stories so that we can all benefit from increased agility.
Have you been working with features dressed as stories? If so, and you want that to change, here’s a place to start.