Saturday, January 26, 2008

Writing User Stories

Writing user stories should be easy. The reality is that most users don't know how to properly write a user story. Suppose a client asks you to write a wire transfer subroutine for systems at two different banks. (below I will highlight proper Stories in green and improper stories in red)
The client says...Write a wire transfer subroutine for systems at two different banks.
While a need is expressed, I would submit that this is not a User Story. What's been stated here could be the beginning of a vision statement, perhaps for the next release or the next Iteration. Let's try to distill this a bit.
So the client reconsiders and says.....System A should use a web-service exposed by System B to electronically wire funds.
A common pitfall in writing User Stories......getting too technical. The statement above assumes that web-services will be used and it may be perfectly logical to assume that they will be used, but let's examine what a User Story is really intended for. First and foremost is the "USER";specifically, what actions a user will perform and what she will experience in return. The examples above don't expose any User Experience information. Second, is the "STORY"; how the user gets to this point, what the user expects to happen.
A user, wanting to transfer money to account XXXXX, logs into bank A's system She selects the wire transfer option. A message asks her to enter the account number and bank to transfer to (bank B). The system then asks the user for the amount to transfer. After submitting the amount the user may log into bank B and see the new wire transfer as a deposit.
This example gives us more insight into how our client intends to use the system. This provides a better foundation for acceptance tests. It also doesn't assume any particular technology. XP projects have an evolutionary design. So, whether or not the system uses web-services is unimportant.

With our story in hand we can begin to develop acceptance tests. Once acceptance test are written we can begin the process of costing and eventually developing the story.

Further Discussion
While users should avoid getting too technical, users should also feel free to express common UI elements. In most cases they have a good idea of how they want to do their work. If you have user experience people or just smart developers you can help suggest alternatives. The point is to get insight into how a user "uses" your software.

What you DO want to avoid are stories that specifically suggest infrastructure or service elements. Things that throw red flags for me are terms like "Web Service", "Array", "SQL Query", "Stored on the Hard Drive".

Checkout Part 2: Writing User Stories using the 5Ws.

Here are some other good references on writing User Stories:

5 comments:

Gareth said...

I think you have some good points here. We tend to get stories that are already framed in a very specific and technical way. We don't have access to the actual user to talk to them and find out why they want a "web service".

They think they are doing us a favor by simplifying the customers requests down to a technology or converting it into langage that fits with their mental model of the system. Really they are doing us and the customer a disservice. Vital context and requirements are lost. It's part of our job to ask the right questions of the user and get a well formed story. Really drilling down to what they want to accomplish in an abstract sense.

e.g.

"I want to transfer money to my spouses bank account at another bank from my computer."

v.s.

"Build a web service to transfer money to another bank."

Neither one is a great story but the first is a much more useful starting point. There is more information and context there. It brings up other concerns like security on the home computer etc.

Agile Jedi said...

You're right. So often we try to solve a technical problem and we forget that we are just filling a user's need.

It shouldn't be hard to "Do the simplest thing possible". The great thing about Stories, as opposed to use cases, is that they can be less technical. Since we don't restrict the technology up-front we can evolve a real solution quickly.

Thomas Eyde said...

A use case doesn't have to be technical. It doesn't have to be UML, nor a bulleted list. It may well be a narrative, almost like a user story.

However, I have always seen a user story as something not more than two sentences. In that regard, the green user story looks like a use case to me.

Agile Jedi said...

Well, I've done this for too long to stumble into the bear trap of "what's the difference between a user story and a use case."

From a pragmatic perspective the answer is, none. Uses cases tend to be written by designers. The term User Story just affirms the fact that we're an agile shop...so yes it is superfluous (also I prefer the term 'story' when talking to users).

I "prefer" the green story for various reasons. It makes writing acceptance tests easier. It let's me know how a user visualizes "using" my software and it doesn't discuss infrastructure elements that are best left to the engineers.

Your preference may differ.

NRG said...

Depending on the goal that you or me have set, anyone amongst young learnes such as we are can look for someone who will agree to compose a big research in short time. As stated in papersmart company student papers for sale the meaning of details in educational process for an average man or woman is highly estimated.