We work with a lot of companies in varying states of maturity. Some prospective clients …
User stories are an important, yet oft-overlooked piece of effective software and product development. Let’s start with some of the basics.
Defining a User Story
The basic definition of a user story is:
“A description of functionality that will be valuable to a user of a system or software.”
Let’s break that apart:
- Description. This description should be well articulated, but not overly complex. Anyone should be able to read it and explain it back to you.
- Functionality. It must be specific enough that it *does* something. This is not marketing copy.
- Valuable. To me, this is the most important part. Why should we be building this thing, anyway? Does it save us time? Make us money? Is it just mind-bendingly awesome?
- User. Who are we doing this for? Bob in Accounting? The executive team? Our core user group? A small, but valuable, subset of our users?
- System or software. The domain in which we’re working. Where does the story fit in the overall arc of our product?
Why write user stories?
Why does anyone need to take the time to write user stories for an app or product? After all, developers can talk to clients, and they can take notes. Why do we care about using a standardized syntax to create my requirements? It sounds like a waste of time.
Stop. This pitfall happens far too often. You’ve probably heard this story before:
A requirement is given as a hallway conversation or email note by a busy executive who’s trying to get something done. Two weeks later, the work is complete and it bears *zero* resemblance to what the executive had in mind. Therein lies the main problem: we’re trying to collect information from each other’s minds and, without a common tongue, we often miss each other’s point.
User stories allow technical and non-technical folks alike to collaborate, plan and outline a product’s requirements. They’re the common language of our trade. They’re also incredibly valuable, to the point that I often think of them as currency. With a well-defined and well-written story, I can create the things I need and want without ambiguity or confusion.
Writing a User Story
The basic components of a user story are…
As a << user >>, I want << feature >> so that I can << receive value >>.
So there are three modular pieces: Users, features, and value. As mentioned before, the value is the most important part – and I often write that part first. Why should we care about this story? What is its happy ending?
What does the thing actually need to do, and who does it serve? There’s more to it than that, but that’s the basic operating syntax.
In Part 2, we’ll talk about how to actually write them and how to collect requirements for good stories. It’ll be fun.
Editor’s Note: This series was originally drafted by Jon Arnold, but was not published until after he left Centresource for his next adventure as Product Manager at Taonii. You can find Jon on Twitter @jonarnold.