Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
We recently held an internal poll here at Thoughtworks about how you should write user stories. The results? Highly weighted toward common agile formats:
On the Mingle team, we’ve grown to predominantly use, “Other.” Why? Well, here’s what I offered:
I've written stories with both the traditional Agile (ala Mike Cohn) and Feature Injection formats and find both unsatisfactory. Something just doesn't sit well when I'm trying to fit the essence of a story into a prefab form. If I have to follow a format, I spend more time trying to conform to the format than distilling the valuable work that needs to get done.
The rigidity of formats can compromise the ability to communicate value and purpose; they make the story writing process feel unnatural, if not forced. So, I find myself moving toward "free form" story writing.
This all said--and here I go contradicting myself--if I find the structure of traditional formats helpful in distilling the value of a story, I'll use them, as in the following example:
As a scrum master I want to create a card by dragging the magic card onto a cell in the grid view so that I can intuitively specify where I want the newly created card to appear on the grid view.
I simply don't want to have to use them. Teams should be able to work the way want to. Whatever form works best for the story, the writer and the team should be the form that is use.
One of our customers recently asked a similar question about how to achieve consistency across user stories. My response: "I would encourage BAs to write stories that capture value in a manner that is best suited to the team and the project. Forcing a structure or format could inhibit teams from effectively capturing value or create more needless work (i.e. waste) by making it more difficult to. As long as the story captures value and the team understands why you’re playing it, the format doesn’t really matter.”
There has been a lot of debate around the best way to write user stories. Regardless of your stance, it’s important to recognize the exercise traditional story formats provide: focusing our attention on value and our efforts on answering the question, "Why?" Why are we investing in this work? Why will it provide value to the customer? (You might have other "why" questions to answer, but these are a few to keep in the forefront of your mind.)
My point, in short:
The greatest challenge in any format is being mindful throughout the writing journey, not focusing on simply capturing a requirement or successfully filling in a formatted structure, but really honing in on value, gaining insight into that value and achieving ownership of that understanding.
How do you write user stories for your team?
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
Thoughtworks acknowledges the Traditional Owners of the land where we work and live, and their continued connection to Country. We pay our respects to Elders past and present. Aboriginal and Torres Strait Islander peoples were the world's first scientists, technologists, engineers and mathematicians. We celebrate the stories, culture and traditions of Aboriginal and Torres Strait Islander Elders of all communities who also work and live on this land.
As a company, we invite Thoughtworkers to be actively engaged in advancing reconciliation and strengthen their solidarity with the First Peoples of Australia. Since 2019, we have been working with Reconciliation Australia to formalize our commitment and take meaningful action to advance reconciliation. We invite you to review our Reconciliation Action Plan.