User Stories - Tell it like it is

At every training session I do on Agile and Scrum, there two questions that are guaranteed to be asked without fail. What are user stories? and Why are they called user stories? Most participants understand that they're some form of user requirement but 99 times out of 100 they confuse user stories with use cases. Requirements are probably the most important aspect of software development. If you get the software requirements wrong, then no matter how good your software development team is, the project is doomed to failure.

The problem
First and foremost, software requirements is a communications problem. Clients or Customers need to communicate to the development team what they need built. Traditionally, requirements were written up-front and in detail and usually in the form of a requirements document. The problem with this approach however is that requirements are most often frozen or buried in these brutally hard-to-read documents. Not to mention the fact that requirements are often misunderstood due to imperfections in the written language. User stories at their very essence are designed to solve this communications problem and to break down the barriers between the end user and the software development team.

Breaking it down
There's lots been written about user stories by thought leaders like Mike Cohn. My own interpretation of a user story however is that there are two main parts - the "user" and the "story" It's really important to paint a picture for the development team about who is using the software. The type of user greatly influences the design of the functionality. So it is recommended that development teams spend some time defining user roles or personas and their description should be recorded in the description of the user story. For example:

As a "frequent flyer", I'd like to be able to redeem my air miles.

It is very interesting to see how personas are being used more and more these days. When I submitted my proposal for the Agile 2009 conference, I had to pick the persona that best matched my target audience. This really helps attendees to choose the talks that best match their level of Agile understanding. It becomes crystal clear.

Collaborating to elaborate
The second part i.e. the "story" part, is designed to tell the story. This should be written conversationally and is not meant to be very detailed. The reason is that in Scrum, requirements (or user stories) are fleshed out at the last responsible moment. And there is no better way to do this in person. It is meant to spark dialog between the customer and the team. And since this is done just prior to implementing it, you're guaranteed to have highly relevant and fresh information. And since the Customer is supposed to be engaged every step of the way, this should never pose a problem.

Capture the details
Details are captured by way of user acceptance tests and should also be recorded along with the user story. Most tools like Agilebuddy provide a way for you to record and track acceptance tests. These acceptance tests are a way to inform the team how to know the feature is done. This is crucial. Responsible customers should execute the user acceptance tests prior to accepting delivery of the software If you're looking for more details on user stories the User Stories Applied by Mike Cohn is a great read.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy or visit blog.agilebuddy.com