Being Agile: How (and Why) to Write Great User Stories

What’s the (user) story?

User stories are simple, yet extremely powerful constructs: they describe pieces of functionality from a user’s point of view, expressed in a solid, compact way. They reflect what a particular class of user needs and the value to be gained. The format is very simple and easy to use. There are several variations, including: “As a <role or persona>, I can <goal/need> so that <why>”

User stories provide an excellent way to define your product with clarity. A set of well-defined, prioritized user stories can help you articulate the functionality of your product in ‘plain English’ — with no technicalities and implementation details. Properly written user stories provide a solid basis for communication and collaboration and help to set the focus on what matters most to the user. Compared to other means of capturing and documenting user requirements and product specification, they have at least the following advantages: They help to achieve cross-team clarity, they encourage participation by non-technical members and they help in defining the entire product.

How to write great user stories

The format is straightforward, and writing stories is easy. But writing great ones might be a bit tricky. Here are some guidelines to consider:

User stories ≠ tasks

User stories are not tasks. In fact, a single story may need hundreds of single tasks to be successfully delivered. Tasks are about implementation; user stories are about definition.

Stay high-level

You need to be high-level, but also accurate and to the point. Stories must be simple and solid. This will help team members and stakeholders deeply understand the user needs, and avoid spending time clarifying buzzwords, terminology, and acronyms.

Understand the users

You need to discover and study the real users of your product — capture their profiles, points of view, expectations, and the associated ‘pain points.’ User research and other techniques can generate insights to help you better understand the users and their needs.

Think as a user

The <as a particular class of user/ persona /role> part of a user story, defines the angle, the perspective — how the particular user perceives the functionality summarized in the story.

Think big, capture everything, prioritize wisely

When describing a product as a backlog of user stories, there is no good reason to constrain your thinking by budget, time, feasibility or cost. A good practice is to think big and let ‘crazy’ user stories enter the backlog. The administrative overhead of maintaining an extended product backlog is small; the value deriving from it — in terms of product clarity, vision, and opportunities — is massive. Given an effective prioritization process, it is good practice to keep enriching your product backlog with new user stories, describing new user interaction scenarios, ‘random ideas,’ or the output of product innovation activities.

Depending on the context, prioritizing user stories can be a tricky process. You need to estimate the value of each story, for the user and for the business. You need to size the complexity and estimate the feasibility and the cost/effort required to build and release the feature. You need to identify cross-dependencies in your backlog — enforcing specific ordering between certain entries.

Set up for success — not just acceptance

Teams often define user acceptance tests and related acceptance criteria. Acceptance though is not enough — you need to set up for success. As a product manager, you need more than a confirmation that ‘it works as it should’ or ‘according to the specs.’

You need metrics that are also linked to direct user feedback, capturing how happy and engaged your real users are. While acceptance is good to control the development life-cycle of the feature, success is about mid/long-term impact and value created for real users of your product. You need to define both — at the product and/or epic and/or story level.

You still need specs

Having a prioritized set of well-defined user stories is great, but it’s only the beginning. The team needs to analyze the stories — from a technical point of view — and create the necessary technical artifacts.

Ideally, stories are mapped with certain sections/documentation that provides all the technical details needed from a software engineering perspective. They provide the entry points for detailed technical specification documents and other detailed artifacts.

Visualization helps

An always-on (digital) visualization of the top-priority user stories by category, theme, or epic could be extremely useful for collaboration and alignment among teams and stakeholders. Along with statistics, issues, blockers, and progress indicators, a story map can be served via interactive screens in the collaboration space.

User stories provide a great way to quickly and accurately describe the functionality of a software product or system. They are also very effective in capturing the outputs of brainstorming sessions, design sprints, hackathons, and other innovation-led processes — where a feeds of ideas need to be articulated in compact, structured ways.

Check also: our unique Innovation Toolkit - a collection of seven innovation templates that empower teams to frame problems, shape ideas, run hackathons, and more.