The Definitive Guide to Writing the Perfect User Story

Mary Wrenn
Aug 26, 2017 · 3 min read
Pro tip for POs: download Sketch to make clip art

Prepare to be disappointed. No — really.

In my vast and varied experience as a Product Owner (read: a whole 2.5 weeks), I’ve spent a fair share of my time (late at night, on weekends, in meetings with 25+ attendees…) attempting to craft the perfect user story. I’ve scoured Medium, internal enterprise resources, and just about every link on Google that seemed remotely relevant.

I wanted to know what was in the secret sauce.

How are there rock star POs out there writing user stories that get developers excited, ready to develop? Fresh out of college, I’m looking for a text book to spell a simple formula:

Gherkin + Secret Ingredient = Perfect User Story

Soon after I was handed the title, the Product Owner role started becoming less about what was going to help my developers create good features and more about what was going to stroke my own ego. I caught myself digging through requirements and stories that spanned over four pages… Single spaced. Before I knew it, I was sucked in. Process was key. Clearly, what I was missing was a more verbose writing process. How would the devs know that the customer wanted not just a drop-down menu, but a menu that dropped down when clicked? About this time, I realized I was not just drinking the Kool Aid — I was bathing in it. So, I sought out some advice. And here’s where I reveal my secret.

The magical formula for the Perfect User Story: There isn’t one. It’s whatever works best for your team at that time.

I hear the chorus of groans — but hear me out. It turns out that every team works differently — shocking, I know. But the more I looked into what other teams did, the more I found that I’d have to learn how to write stories on my own. Some teams dove deep into granularity, detailing every possible step of the development process and breaking down tasks to the minute. Other teams worked more flexibly, with one liner Gherkin stories and maybe two Given/When statements. Is one way better than the other? Not necessarily.

It comes down to developer feedback.

The team with the granular stories decided to pursue that route because they’re all detailed-oriented people and are working with a very particular customer. The developers and PO found writing down all the details helped them deliver a product that the customer actually wanted. The team with the brief stories wanted to give the developers more freedom to suit the needs of a more flexible project.

The key take-away: user stories aren’t for the Product Owner, they’re for the development team.

So, in short — sorry, you’re on your own. You’ll have to embrace the learning curve alongside your team. Write requirements. Give them to your dev team for feedback (be sure to swallow your ego first). Take the feedback, write it again. Most importantly: give them options. Don’t dictate your user story, start a conversation. Ask the developers what makes the most sense to them and test it out. Know the process is flexible too — you’re not married to one format forever.

If software development should be iterative, shouldn’t our processes around it be too?

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade