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.
Comments
I am constantly getting reports just like you say “This doesn’t work.” What does “doesn’t work” even mean? We have been working toward the cucumber standard for a while now. Making a big difference.
I prefer an extended version of the first pattern:
As a [role], I want [feature] so that I can [benefit].
This can have a big impact on developer happiness and ensure that discreet tasks are linked conceptually. Software exists to provide some value and each feature is a means by which we provide that value. By including the customer benefit in our user stories, we ensure that that value is specific and known during development.
Hi,
Having automation jargons in the bug report shows the tester has just copy-pasted the error from the automation result and there has been no effort to translate it to user stories. This can have very adverse results. Since the description is poor it can lead to late fixing of bug or jumping of bugs from one team to another team leading to “Defect Tennis”. I call this Defect Tennis because the bug simply moves back and forth with no real action.
Regards,
Aruna
www.technologyandleadership.com
“The intersection of Technology and Leadership”
@Aruna I fail to see where automation jargon comes into play. I see Brian’s intent as a way to be deliberate on how you communicate the stories. With the suggestions he’s outlined (as well as the one from the commenter Brian) it requires the person writing it to think about each of the items.
If the problem is someone copy/pasting and being lazy, then that seems like it needs to be addressed elsewhere. I look at it as the difference between “I don’t have any format” => “I’ll start from this format” and “I have a format” => “I’m going to game that format”.
Nice post.
You can’t over-appreciate saying something the most beautiful way possible.
Dan
@Brian: I can see the benefit in that extended form. In a similar fashion, I’ve been giving some thought to the pattern that Dan Martell suggests
Feature X will move Y metric.Great points here. A great reminder of the fact that a little bit more due diligence in writing a good user story goes a long way.
http://agilescout.com/presentation-writing-better-user-stories/
Storytelling can be used in multiple ways in software testing. Stories in the Connextra (see the Rspec book) or GWT (given, when, then) formats are the most obvious, concrete and immediate to use examples.
Storytelling can also be used to develop test ideas (Michael Bolton’s article on test framing in Tea Time with Testers illustrated this well).
Stories can also be used to explain what we do to people with limited interest in testing (think executives) and to customers. Stories are a great way to engage people - especially people who are anxious about technology as we wrap details into a context that makes sense to people and a format that’s accessible.
Stories can also be used for status reporting - a great way to avoid silly metrics and provide more meaningful responses.
I suppose I could go on and on … I should blog more on this myself …