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:

Tuesday, January 01, 2008

New Name....Same Crap

I've changed the name of my blog!!!! Not that this makes much difference to my audience. This blog will, from this day forward, be known as "Something Smells". While my critics may consider the cause for this change to be self evident (Garreth, Rob?), I made this change for wholly different, and much shallower, reasons.

First of all I no longer fancied the old name (yes, I just used the word fancied). Second, after long deliberation in the shower at the American Airlines Admiral's Club, I decided to really re-enforce the code smell concept. Oh and I changed the masthead....I think the new title goes better with the masthead.

Why more on code smell? Well, I won't be writing more about code smell, but I do think that my general technique for coming up with interesting topics (don't say a word) is somewhat similar to how we find code smell. Also, I think the art of hunting for code smell is a bit misunderstood. For better or worse, we all do it (hunt for code smell) and the sooner we accept it the better we can start to become at it.

Enjoy, comment and try to be kind!

Happy New Years!!!!!!