What is a User Story?

A child of the Agile Approach to delivering information technology, User Stories are becoming a common tool in the business analysis world. For those of you who are unfamiliar with this relative late-comer to the business analyst’s requirements elicitation toolbox, let me quote Wikipedia: “… a user story is one or more sentences in the everyday or business language of the end-user that captures what the user wants to achieve”. That sounds simple enough, doesn’t it? Well, buckle your seatbelts, folks, this could be a wild ride.

For starters, a User Story is not really much of a story at all – unless you love extremely short stories that lack character build-up, a story line, suspense, or (necessarily) happy endings. What passes for a story in the world of software development is one, two, or “a few” sentences that focus on one specific outcome that someone needs or wants the future software application to deliver. Talk about killing the suspense up front! Actually, the “official” limit to the length of a User Story is that it should fit on one side of a 3 X 5 (OK, go whole hog and use a 5 X 8) index card. Unless this story is written by one of those gifted people who can write the Lord’s Prayer on the head of a pin, this does not leave a whole lot of room for details. That’s OK. A User Story should lack detail, that’s the plan.

Context for User Stories

User Stories do not exist in a vacuum. What do you need to know about the project before you can start to capture User Stories? First and foremost, you need a project (duh!). To have a project, you need at least an idea of the scope of the project. What’s in, what’s out, what’s in the gray zone? Without scope, you could collect any number of User Stories that are quite interesting, but totally irrelevant for your project. That would be a waste of valuable index cards not to mention everyone’s time and creativity.

So, how do you capture the scope of a project? You could use a context diagram, if you wanted to go “old school”. A context diagram is a simple picture that draws a circle around everything you can change and indicates things that you cannot change but which interact with things inside your circle in some manner. If you do not like to draw, you can also express scope in a series of statements, like, “The application will support picking and packing of orders but not affect order entry or shipping.” Actually, using exclusions is a fairly common expression of a scope statement.

A critical note regarding scope: do not expect it to be a universal constant. Scope, like everything else on a project, is subject to change as time passes. It evolves as our knowledge of what the project can deliver increases. What you are really dealing with at any point in the project is the “currently defined scope”. As necessity changes, so must the scope of the project change.

Users Create User Stories?

First and foremost, as the name implies, end users should create their own user stories. Unfortunately, whoever creates a user story can get very creative and verbose in describing what they want (need) the application to do. All too often, they like to get into the nitty-gritty detail of telling IT not just what they want the application to do, but specifically how they want it to do it and sometimes, how they do not want it to do it. Their idea of a story might just be influenced by their idea of what a “story” should be and a budding author might sense this golden opportunity to further his/her writing career. This enthusiastic involvement in the project should not be discouraged, but it needs to be channeled to ensure that the User Stories they create do not consume all of their waking hours AND that their User Stories provide the expected value to the project (more on how to accomplish this shortly).

How About Other Stakeholders?

Just to throw in an unexpected twist, consider that end users are not the only people who might want to write a user story. Actually, you should apply a very expansive definition of the word “User” to identify potential authors. I maintain that anyone who will or could interact with the evolving application should be considered a source of User Stories. After all, people who will develop, maintain, test, or manage the app have needs, too. If their needs are not met, the app will either fail outright or (potentially worse) turn into another maintenance nightmare that saps the corporate IT budget unnecessarily for years to come. When gathering User Stories, cast a wide net. The only caveat is that each “User” should only write User Stories related to his or her use of the app. Getting analysts or developers to write the end users’ stories because the latter do not have time leads down a road that IT has travelled all too often in the past. Be brave and take the road less travelled. In the IT universe, that is the one that leads to successful apps.

Three Emerging Careers for IT Business Analysts

Upon completion of this course, you can:

• Define strategic, tactical, and operational business analysis audiences, techniques, and results
• Recognize how to leverage the distinction to further your business analysis career
• Discuss what it means for the future of the business analysis profession
• Differentiate business analysis techniques required for each level of business analysis

When to Capture User Stories

Ideally, you should get as many User Stories as you can as early in the project as possible. Let me revise that. The best time to get a User Story is as early in the project as you reasonably can. The concept that an app is defined, designed, built, used, and retired died sometime in the ‘60’s. Applications are living things and, like all living things, they evolve, they grow, they get sick, and they need ongoing TLC to continue to provide value to their users. User Stories can provide a good helping of that TLC. Recognize that as the app evolves, new User Stories may be needed to describe additional user (expanded definition, see above) needs. This is not a sign of a sick patient; it is a sign of reality.

Structure of a User Story

In the interest of avoiding both writer’s block and too much detail in a user story, many organizations have agreed on a de facto standard structure for a user story, such that:

This structure actually goes a long way to ensuring that the User Story provides the expected value to the project. Some perfectly legitimate examples of User Stories are available on Wikipedia at http://en.wikipedia.org/wiki/User_story.

You will also find there some hints as to what you need to “complete” the User Story, as in “Acceptance Tests”. That is a phenomenally interesting aspect of the Agile approach that incorporates something we have been preaching for years, to wit: “… unless you know how to prove whether your needs have been met once the app is delivered, IT can not understand your needs well enough to develop the app”. According to User Story theory, the front of the ubiquitous index card contains the User Story and the back is used to capture the acceptance test for the User Story (which sounds like a great topic for a future post).