What makes Good User Stories
How to write quality UserStories
UserStories are a most effective and efficient way of rationalising and articulating expectations towards capabilities of a system. They can be seen as lightweight requirement, or more orthodox ‘agile’ as ‘a reminder to have a conversation’ about such expectations. While we should always adjust ways of working to best suit current context there are a number of criteria that, generally speaking, make for top quality Stories.
Why bother
High quality Stories optimise delivery outcome by
optimising communication (lean, just-in-time, evolving, conversation starters)
ensuring value focus (user-centric view, expression of rationale / goal)
and are a key-ingredient in making delivery more efficient and effective. They are a lean way of communicating relevant information, reducing overheads and ambiguity intrinsic in waterfall-style working and specifically specification.
Stories Evolve
User Stories are not static like waterfall specification, instead, they have a Lifecycle and evolve over time as more information becomes available or is required.
At business level we define intent and rationale and an outline of expectations towards final functionality, which, at implementation level, will be embellished with relevant detail to aid implementation and testing.
Business Level UserStories: What ‘good’ looks like
At this point the story’s purpose is to guide subsequent detailed analysis and solution design by expressing need, rationale and intent.
Valuable and User Centric
Every story has a user and must delivery value to this user. We define
user (Who)
goal (What — Need)
rationale (Why — user value)
how this translates into business value (Why — business value)
Good stories express the goal (direct value) ‘… see a list of products so that I can choose the most appropriate one.’, great stories express ultimate value ‘… see a list of products so that I can easily choose and subsequently buy the most appropriate one’.
Small but narrative complete
At best a story is the smallest unit that delivers some value (at worst it should be just small enough so we can delivery it within the maximum time allowed by our feedback cycle (which in terms of Scrum usually is a Sprint)).
Stories should also be ‘narrative complete’, i.e. cover the end2end journey to achieve a tiny goal from triggering event to measurable and valuable outcome. This also means that while stories will build upon each other to build up ever more valuable features, they are independent (only) in the sense that even early stories deliver value (later ones of course may evolve and thus depend on earlier ones).
Solution Neutral
At business level stories should be solution neutral (except in cases where the solution is part of the requirement which can be the case where we evolve an existing feature).
Just enough detail to aide analysis and solution design
As the story aids subsequent analysis and solution design we stay solution neutral and only note detail, specifically acceptance criteria, relevant for these activities. Usually this means focusing on the high value, high risk, non-trivial, non-obvious items. At this level they can be prose form, bullet pointed or BDD style.
Implementation Level UserStories: What ‘good’ looks like
When we transition to this level, we evolve the story, so that it reflects the solution design chosen as outcome of the business level story and subsequent analysis, cost-benefit assessment and feasibility check, and expresses it in sufficient detail to allow implementation and validation.
Solution Specific (functional)
We are now becoming more solution specific in the sense that we are expressing expectations towards functionality (but, generally speaking, we should not express technical specification in stories).
Detailed and testable
At implementation level we add sufficient detail to support implementation and validation. This means that we will need to capture all scenarios, cases and rules (see template below), and dependent of methodology will want to express them formally to support BDD practices.
While our default position should BDD scenarios a story is NEVER a replacement for conversation and we should allow ourselves to fall back to simple prose or bullet-list expression if more efficient.
We should also consider that in some cases diagrams, wireframes, prototypes or other artefacts can be better ways of conveying information.
Still keep it brief
Stories that can’t be seen on a single screen are usually either too ambitious and need breaking down or over-documented. More is not better. No-one likes reading a lot. Having said this, it is worth documenting detail where it aids as a reminder about previous discussions and decisions. In Lean we reduce waste by specifying as little as possible, while not adding risk. This is the balance we need to find.
One-Stop-Shop
Stories should be a one-stop-shop for a developer, i.e. all information required for completion of a single story should be either in the story or referenced off it.
Where we reference artefacts (e.g. further detail, copy, visuals or wireframes) we should consider keeping them in an external repository (shared drive, Confluence) and reference them so that overheads and error during updates are minimised (of course this may bring version control complexities which we need to weigh up).
Stories are for your Team
Stories are an intermediate artefact. Their sole purpose is to support implementation. Stories are ‘good’ when they facilitate implementation.
Hence what ‘good’ means is strongly dependent on context: primarily what the team requires to do good work (immature team may want a bit more detail, mature teams may work much faster with top level guidance only) and secondarily what the organisation requires (highly regulated environments may use stories to support tracing of feature-risks against validation cases to satisfy compliance).
How do I know I am writing good stories?
High match between delivered features and product owner expectations as well as low number of bugs are good indicators for quality stories.
Also, less is more it may be worth playing with the level of detail as well as format and measure outcome against this and thus continuously improve story writing.
Be mindful though that quality stories help us deliver right but not a guarantee for delivering the right thing.
Hang on, what about INVEST, SMART and others?
Traditionally story quality is defined by the INVEST acronym, and while there is value in it, I disagree with some aspects and find others not helpful (‘I’ndependent I disagree with and ‘N’egotiable simply does not compute with me). Hence the above view where INVEST is merged with SMART and extended further.
Epics, Stories, Themes & Features
In short, Epics are large Stories used to group stories for convenience. Often we use Epics early in our exploration and then break them down into stories as we go. But we only ever implement stories. Consequently the information provided in an Epic is only business level and spans more feature-breadth.
A more in-depth explanation here.
Template
This template applies to both, business and implementation level, but at business level (and for Epics) we will be more high level and less formal in the sections Acceptance Criteria and below.
Title
{A 2-3 word title}Story
As a <user / personal> I want to <action> so that <goal, rationale>Context (optional)
{Business-, domain-, current- or historic-context of interest to understand problem, rationale or guide solution design}Acceptance Criteria / Scenarios
{Main Courses / Ideal Scenarios
Alternative Scenarios / Exceptions / Errors.Items to consider include, but are not limited to: transactions, data capture, personalisation (prepopulation / defaulting), system interfaces, reporting, analytics, monitoring, misc supporting activities, business rules, validations.Also consider non-functional requirements such as: devices / clients, branding / design, accessibility, localisation, performance, security, resilience, legal}Dependencies (optional)
{Dependencies on other stories, systems, etc}Notes, Considerations, Questions, Todo (optional)
...Related Artefacts (optional)
...Value & Measurement (may not apply to low level stories)
{How will we measure success?}