User Stories

The mumbo jumbo of use case, requirements gathering, and all that are a necessary evil of software design.  We developers cannot unfortunately just haphazardly build our UIs and other such things.  It is necessary that in some way the user interface is dictated by the users.

In the past, especially with waterfall, this has been a massive failure point for companies having software built.  The UI not reflecting actual use or features of what was actually needed (vs. what is asked for, because we all know that what is asked for usually isn’t really what someone wants).  To get to what someone actually wants and needs takes multiple sessions of sitting and going through the UI.  This of course entails all the underpinning architecture and functionality too.

The crux of all this is it eats up valuable developer time, which is why the solution in the past was always to put people in between the developers and the users.  However, that just means there is another communication failure point between the user and the developers.  Major problem…

Enter, User Stories.

User stories in the agile, sometimes eXtreme Agile sense, provide an alternative way to get specifications and requirements without the customer shooting themselves in the foot.  It has been documented so many times the customer either goes beyond or doesn’t provide even close to what they should in the requirements and causes development to slow to a minimum speed.  Sometimes development functionally stops while developers “thrash” and struggle to find day to day tasks.  This effectively kills a project.  I myself have seen entire projects, with burn rates in excess of a quarter million dollars (yeah, that’s $250,000) a month effectively not achieve a single tangible task because of faulty and ill planned requirements.

User stories are simple, so simple that they almost cause a customer to make the application request what it should be, simple!  A simple application is by far the most useful application for a user.  The second things get complicated it is usually because of ill planned requirements that state too much or too little in the way of what is actually needed.

A user story goes something like this, “A user can create a document to provide a customer bill.”  The story doesn’t tell a developer what type of document it needs to be.  The story doesn’t tell a developer that it needs put in a particular place or put into a bit stream or anything in an implementation sense.  The story simply states what the user needs to do to perform a business need.

The user story is something that should be able to be placed on a brochure or pamphlet as a selling point of the application.  If it is something you wouldn’t put in a document like that, it is highly likely that you’ve either given too much or too little information in the user story.

Some specifics about user stories, and identifying a good story versus a bad or unusable story is that they must be;  independent, negotiable, valuable to the customer, small, and very important to the developer, it must be testable.

I run into a little problem with project managers, scrum leads, or whoever taking these and estimating schedule times based off of these things, but some very well respected agile proponents suggest that a user story must also be estimatable (which is not a word really, so maybe it is just a joke).  I assume that they intend to schedule and estimate a project plan of some sort with user stories.  This can be done, but a team should not be dictated a strict schedule based entirely off of user stories.  In a very Six Sigma, Lean, Agile way estimates at this level are still NOT measurable with a high level of accuracy, there is still a double digit percentile of risk involved that must be mitigated if planning is done at this level.

But I digress, back to the user stories…

Beyond the Written User Story

Beyond the basic user story there are other elements of what has to be done.  The most important part, more so than even writing down the user stories, is to communicate the user story.

During the iteration the team must get these stories and organize them in a way to have current work, backlog, and done.  Each of these unto itself is worth an article each, but I’ll continue on with user stories.  Keep in mind though that each of these points is very specific in the use of user stories.

The Gurus

For more information check out InfoQ for some decent articles.  For the master of user stories check out Mike Cohn over at Mountain Goat Software.  Mike has an article titled “Advantages of User Stories for Requirements” which is a must read!

So get your user stories together, or fail.