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:
- Traditional formats can be great for training purposes (and could be beneficial for multi-lingual distributed teams). But once you learn the rules, you should have the right to break them. Focus on fluidity and getting real.
- Stories—regardless of what format they’re written in—should spark conversations that result in a shared understanding among the team and help continuously deliver value to the customer.
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?