Over a million developers have joined DZone.

User Stories - Tell it like it is

DZone's Guide to

User Stories - Tell it like it is

· Agile Zone
Free Resource

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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


Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}