You've heard of this thing called a User Story right? Perhaps you've even seen the template:
"As a <type of user>,
I want <some feature>
So that <some goal>."
But perhaps you've wondered how to put a feature like "read the users name from the database and put the value in txtbxUserName" into that format.
Occasionally, I write about Agile on this blog. In that entry, I wrote about a broader view of Agile from a developer perspective. In this one, I made a case for leaving the work up to the pros. This time I'm focusing on something much narrower — the User Story.
The Wrong Way
Perhaps not "wrong" way, just not something that's going to align very well with the benefits of Agile.
"As the one telling you how to do your job, I need you to write code that reads the username from the Users table and put that value in the txtbxUserName field so that it shows up on the page".
Or perhaps "as the project sponsor, I want a check box there so the users have to check the box before they can submit the page."
It can be a bit awkward to put those kinds of instructions into User Story format...especially when the goal is not for the user but for the project sponsor or manager to tell a developer what to do. You can succeed at writing good user stories if you frame them in more general terms — don't think about implementation details. A good test is — if it's awkward it isn't right.
Maybe Better"As a user with access to multiple user accounts, I want to know who I'm logged in as so I know which account I'm using at any given time."
"As the company's legal counsel, I want the user to accept responsibility for using our services so that we have a leg to stand on if something goes wrong." That's the "I have read and understand the 30,000 words of legalese" checkbox.
Real Life ExampleFor another look, let's imagine were doing some work for a burger joint where their customers expect one thing — getting their food quickly. They want to order quickly and they want everyone else to do the same so the whole thing can flow like clockwork and they can be on their way to consuming those cals in under 5 minutes.
What does that story look like? Actually it may be helpful to have multiple User Stories since there are multiple user types or personas. Let's see about defining those now:
Regular Customer - knows what they want and orders the same thing all the time.
Infrequent Customer - didn't visit much and needs a minute.
Bulk-Orderer (team mom) - is ordering for the office or a party and has a bunch of items to order.
A story from each persona might look like this:
"As a regular customer, I want to place my usual order and get on my way so that I don't have to hassle with getting my food."
"As an infrequent customer, I want to take my time browsing the menu so that I can figure out what I want to order."
"As a bulk-orderer, I want to place my order without confusion so everyone gets what they wanted."
|We're going to need a lot of cheeseburgers to feed that many Air-Force Cadets! |
Who ordered no onions?
Now that we see the
user stories in a more "user-need-goal" format, we can start to think
through different ways to resolve the issue. That part of the process is a
conversation. A conversation between the team and the customer.
That's a Wrap...(for now)In this entry, we've seen how we van write User Stories from the perspective of the users, through different user personas. I haven't captured all of them and that's inevitable. The magic is that as we start rolling out features to support the users based on their stories, related stories will filter in.
You may have heard a little about different roles such as Team Member and Customer — especially about who plays which roles. We'll take a look at how that works in the next entry — there are some things to think about depending on your organization.