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 the outside world — 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:
1 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.
2 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.
3 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 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.
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, to deeply understand the user needs, while avoiding 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.
When describing a product as a backlog of User Stories, there is no good reason to constraint your thinking by budget, time, feasibility or cost.
A good practice is to think big and allow ‘crazy’ User Stories to 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.
Epics can take the form of higher-level stories, which describe large pieces of functionality — they typically require 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 a 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 setup 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 which 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.
Check also: How to become a great Product Manager
Tag stories, add metadata
Complex products require hundreds of User Stories. For easier navigation and administrator, 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 exploring, monitoring and understanding your backlog.
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.
In special cases — such as a brainstorming or ideation sessions — it’s OK 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.
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 analyse the stories — from a technical point of view — and create the necessary technical artifacts.
Ideally, stories are mapped with certain sections/ documentation which provide all the technical details needed from a software engineering perspective; they provide the entry points for detailed technical specification documents and other detailed artifacts.
An always-on (digital) visualization of the top-priority User Stories by category, theme or epic could be extremely useful in terms of collaboration and alignment within/among teams and stakeholders. Along with statistics, issues, blockers and progress indicators, a story mapping can be served via interactive screens in the collaboration space.