User Stories in Agile: The Whys and Hows
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>”
Or, in another instance:
“As a <particular class of user>, I want to <be able to perform/do something> so that <I get some form of value or benefit>”
Why User Stories?
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 using ‘plain English’ — with no technicalities and implementation details.
The ‘user story’ approach empowers meaningful product discussions, both within the product development team and with external stakeholders.
Properly written user stories provide a solid basis for communication and collaboration — focusing 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:
User stories help to achieve cross-team clarity on what to build, for whom, why, and when. Since they are easy to define, understand, and revise, they can become the standard way to communicate and summarize the functionality of the product by both technical and non-technical members. They are extremely useful for product scope discussions or as entry points for technical deep-dives. They are key elements of agile engineering.
User stories encourage participation by non-technical members. Modern software projects are typically complex, involving a wide range of technologies, acronyms, and implementation options. In many cases, the terminology or the technical language is not commonly understood — even within a single team — thus introducing ‘noise’ and risks to the project. User stories remove this technical dimension, so any member of the team can contribute, simply by thinking ‘as a user’. The team can use non-technical language and effectively collaborate in defining, challenging, or prioritizing user stories. The impact on collaboration and team dynamics can be significant.
They help in defining the entire product — as a set of solid, wisely-prioritized stories. The product development team can think big, define the super-set of user stories, and then assign priorities (which reflect the expected value for the user, complexity, dependencies, and other business priorities). You don’t have to make hard decisions and flag items as ‘out of scope’. Instead, you can assign a lower priority to those ‘crazy’ ideas, while moving up the user stories reflecting the core functionality of your product. Defining the ‘cut lines’ which determine the scope for each iteration, phase, or version, is then a matter of the resources available and the velocity of the team.
Writing 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.
When compiling your stories, focus on providing clarity about your product features —the what, not the how.
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. Just use simple and accurate language.
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.
No matter the techniques, you need the set of key users — ideally in the form of personas — before you start compiling user stories.
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.
This is of critical importance — the product owner and the entire team need to think from a user’s point of view and understand the underlying needs and the expected value.
Think BIG
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.
Use EPICS
Epics can take the form of higher-level stories, which describe large pieces of functionality — they typically require a significant amount of work, across multiple sprints. Another way to think of epics is as groupings/ containers of related, smaller stories, all serving a common goal. Epics are good for organizing your stories and providing the big picture.
Don’t discard — prioritize instead
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.
To manage the potential noise, you need to properly group and prioritize the new entries. In any case, do not filter out/discard items from your backlog: de-scoped items are usually forgotten, while de-prioritized items remain discoverable and can become relevant under the right conditions.
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, 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.
Setup 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.
Tag stories, add metadata
Complex products require tens of EPICs and hundreds of User Stories. For easier navigation and administration, you need to effectively name, categorize, and tag your stories. After the first few revisions of a story, you should avoid renaming or drastically changing its description as this might introduce confusion and gaps in the team.
Properly managing the metadata of your stories—status, progress, links, priorities, resources, etc. — helps to explore, monitor, and understand your backlog.
Check also: The Innovation Culture Defined: What it is and How to Develop it.
Don’t stick to sticky notes!
Yes, a wall full of colorful sticky notes looks fancy and helps your team appear busy and productive :) But you need a serious system and special tools to help you properly manage, enrich, prioritize and share stories (check our article on the key principles of a great ideation platform)
In special cases, such as a brainstorming or ideation session, it’s okay to capture the first set of user stories by using sticky notes—provided that you then document all of them into a proper product management system. If you don’t, and you just keep your stories on sticky notes, chances are that you will miss opportunities in terms of clarity, innovation, efficiency, and collaboration.
Check also: free templates for ideation & brainstorming
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 to specific 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.
Check also: our unique Innovation Toolkit - a collection of seven innovation templates that empower teams to frame problems, shape ideas, run hackathons, and more.
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 stream of ideas must be captured in a compact, structured way.
The ability to quickly test ideas via functional prototypes can boost innovation performance. In this article we present a practical guide on how to achieve an increased level of prototyping readiness.