5 ways to get the most out of your user stories

User stories have long lifespans and can be used for everything from user research, to wire framing, development, testing & QA, and product roadmaps.

“As a site administrator, I want to assign tags to entries in the directory so that they can be grouped for display and searched by keyword/tag.”

If that kind of statement seems familiar to you, you’ve probably written or encountered a user story or two. The key components of a user story are

• As a <user>
• I want to <do something>
• So that <desired result>

When you put it together, you’ve got a single sentence detailing a key way that someone will interact with a product or feature.

Why bother?

The first time I heard about and was asked to write user stories, I found them repetitive and stupid. It was in the context of writing requirements, and I believed that writing requirements the old way, aka “the system shall…” was more efficient and just easier. Coming from a waterfall background as a technical writer, I really liked the old way!

But over time, my opinion about user stories and their usefulness has changed. User stories seem tedious, but can serve as statements that can be written once and then reused throughout the life of the development project.

When written well, user stories communicate exactly what’s being built to everyone involved in the project. They also communicate who’s using it, their role, and what they’re getting out of it. These statements, together, create a much more comprehensive and layman’s view of the product than “system shall” requirements.

Traditional requirements focus on what the system needs to do. User stories focus on what the user wants to do and why.

User stories are better for developers and analysts

At my first job where we used the waterfall approach and wrote requirements long before they were put into action, I remember a lot of back and forth with software development teams over requirements.