Be a Better Storyteller
It’s no secret that we love user stories. We’re behavior driven and focus our daily tasks around user actionable stories. But near the launch of a project, or the end of a milestone, things can get hairy. Unmaintainable even. And workflow of the team can suffer, especially if there’s anyone working remotely.
The Right Way
I’ve come across a few different patterns of user stories, but the two I prefer clearly state the role and the feature:
As a \[role\], I want \[feature\] or
A \[role\] can \[feature\]
Some quick examples:
As a user, I want to edit my profile.
A user can edit her profile.
As a user, I want to connect my Twitter account.
A user can connect his Twitter account.
Why Any of This Matters
Working with other people? Working with them remotely? Stories written with a clear role and feature are easy to pick up and get started on by someone other than the person who wrote them. In my experience, you don’t need a quick conversation about the context of a bug or feature request if the story is written well. Check the tests, figure out what’s wrong or what needs to be added and dive in.
Brain dumps are inevitable. You’ll experience times where something doesn’t work, someone doesn’t exactly know why, but they do have an idea of what’s broken. User stories for bugs always seem to be implementation oriented. “Delayed Jobs won’t run”, “Post failed validation, an error wasn’t raised”. These type of open ended stories always result in a lot of questions. What went wrong, how might I reproduce this, which environment, staging or production, etcetera.
If you’re reporting a bug, take a minute to carefully consider how a user might encounter this bug and phrase it like you would a user story. Then, in the story’s description, describe the problem you’re having and the steps you took to expose the bug. That should be your braindump, not the actual story itself. It might feel redundant because you’ve already written the story once, but it’ll be a clearer indication of what went wrong along the way, or why your tests aren’t catching the problem.