User Stories - Tell it like it is
Join the DZone community and get the full member experience.
Join For FreeAt 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
Opinions expressed by DZone contributors are their own.
Comments