A user story is the basic unit of Agile development. User stories should be written by the business, not by the development team. They should clearly state the business value that the project is expected to create, as well as the user that will benefit. The focus should be on the problem being solved, not the software being built. This not only increases efficiency, but also provides flexibility for the development team: how they solve the problem is up to them.

There’s a generally accepted template for writing user stories: “As a [user type], I want to [specific functionality] so that [tangible benefit].” I’m not crazy about using this convention because it seems contrived to me, but it does make it easier to understand the priorities of Agile development: a feature exists to provide a benefit for a specific user or user group. If you can’t express functionality in this manner, then it is either superfluous or a technical requirement (there’s a separate document for those, which is written during and after development, not before).

A great user story should follow the INVEST model: user stories should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable (you can read about this in more detail in the links provided below). The main thing to remember, though, is that we’re really just trying to create software where every component can be proven to solve a specific problem for a specific user. It all comes back to justifying programming effort in terms of the value it provides once it’s been released into the wild. Let’s look at some examples, based on developing a tool to keep track of tasks:

“As a task list creator, I can see all of my tasks together.” This story is too vague, and will result in developers guessing about the true purpose of this feature.

“As a task list creator, I can see all of my tasks together so I can download them to MS Excel.” This one is too specific. MS Excel is a technical requirement, and should not be part of the user story text. The real need is for a downloadable version of the task list; limiting it to one specific format at this point may lead to problems later on.

“As a task list creator, I can see all of my tasks together so I can download them.” This is better, but it still doesn’t answer the question of value. Why do I need to download the tasks? This looks ok, but reality I have created a false dependency between two separate features.

“As a task list creator, I can download a task list to so I can share it with project stakeholders.” Now we’re getting somewhere! The user needs to share the list with other members of the team, which is why she needs a downloadable version.

User story writing is iterative and investigative. At this point, I could argue that downloading, just like display, is an unnecessary step, and that the real feature is for some mechanism that allows all project members to see the task list, and the true need is for the team to work on the list together. That’s where the value-add is. Everything else is bells and whistles. Maybe downloading is the most efficient way to share the list, but that decision is part of the development process and should be documented in the technical requirements. Maybe there are other reasons to add a download feature; those belong on separate stories.

As a business-side stakeholder with an engineering background, my first attempts at creating user stories did not go well. I like to tinker and get my hands dirty, so trying to keep design out of my user stories proved difficult; it’s easy for me to get bogged down in technical details and focus on fixing what’s in front of me, rather than asking whether it’s even necessary in the first place. Any time design creeps into product requirements, it adds a layer of abstraction that makes it harder for a development team to understand what it is you really want. It took me a while to learn that lesson (you could argue that I’m still learning it). Besides, when a product owner gets involved in designing software, it’s hard to avoid creating an attachment to the specific design, regardless of whether it meets user needs or not. It’s best to stay out of that process altogether (no matter how much fun it may be) and maintain the focus on the user.

Writing user stories can be frustrating, especially if you’re new to Agile, but they are a great way to discover the true user needs that should drive your software development project. If you want to learn more about user stories, you can go here, here, or here. I’ll be back next month to talk about prioritization and scheduling.

What’s your experience with user stories? Do you have any tips on writing a great user story?