You’re asked to write up some user stories for the new product your company’s working on. You do a couple of Google searches and come up with “As a ___ I want to ___ so that I can ___”.
Sound familiar?
We’ve all been there at one point. Looking for the perfect way to write a user story so that everyone on the team can know what we’re talking about.
But what if that’s not how user stories are meant to be written? What if user stories aren’t even meant to be “understood” by everyone?
What are User Stories for Anyway?
Most people think of user stories as concise sentences which explain a feature from a user’s point of view. But how much can you really learn from a one liner story?
Consider the following situation. A car accident happens on a semi busy Dhaka street between a car and a bike and a police officer is tasked with finding out what happened.
One witness saw it from his apartment window and claims the bike was speeding.
Another witness was standing 50 feet away and claims the car sped up at the last moment causing the accident.
Yet another witness saw it as they got out of their car at that very moment and they say it was a bump in the road which caused the biker to swerve so it was no one’s fault.
Same accident. Three different explanations.
How does the officer come to a conclusion here? Does he simply document these witness statements and move on?
Of course not. He should discuss these events further and if possible, bring together the witnesses to have a more comprehensive discussion.
And therein lies the key to understanding what user stories are for. They are there to get an understanding of each “user’s” view of the particular feature.
How do they view this feature? What makes it interesting for them? What is the feature’s purpose?
Now, of course condemning our thoughts to a single, stubborn line of copy doesn’t make much sense here. Rather, explaining it in a free form to get out what’s in our heads is the answer.
See it’s not the stories themselves that offer the end value, but what follows.
It’s the Discussion, not the Story
Just like our officer in the accident story would love to bring together the witnesses and have a more complex discussion, so should dev teams. When each team member brings their own view of the feature to the table several things happen.
Firstly, the team can gain new perspectives and ideas on this particular feature and how to make it even better for the end user. This should always be an ongoing goal for the team as it is.
Secondly, the team can understand the gaps in understanding between each member of what the final result should be. Gaps in understanding a particular feature, lead to products that aren’t cohesive, or at the very least, not fully optimized.
Thirdly, the original reason behind the user story comes into play, that is, a conversation between builders and those who want the product built for them.
In these discussions the real value of a user story is brought out. Through discussion and images and diagrams and sticky notes and all the other ways a team can get their creative juices flowing.
The user story is just the means to the end, not the end itself.
Coming to a Common Conclusion
The lifecycle of a user story basically goes:
Written story —-> Conversation —-> Confirmation
So, we understand the written story part now – an original and individual perspective on a feature that is not limited in words or structure.
We understand that the conversation is where the real magic happens. The conversation is the path we follow to arrive at the destination – confirmation of a team wide understanding of a given feature or set of features.
Confirmation is the point you want to reach as a team. A confirmation from each team member that they understand the feature or requirement and are on the same page about its function and its place in the bigger picture of the software.
Seems like a dream place for a lot of founders but one that is actually well within the reach of any dev team.
Creating a culture of discussion and shared understanding coupled with the right tools is the first step to achieving this state of software bliss.
In the end, user stories are only as useful as the clarity with which a user can tell them. Learning to tell better stories in more creative ways could just be the one blocker preventing you from creating the next big thing.
