Agile User Stories are short, simple descriptions of a feature or function told from the perspective of the person who desires the new capability represented by the story, usually a customer. They focus on the result or value that the user or customer gets. User stories can be big (but not too big!), and they can be small. When stories are really big, they are usually called epics, which then would be broken out into smaller user stories. A single story does not need to represent an entire feature.
User Stories typically follow a simple format:
As a <type of user, “Actor” or “Persona”>, I want <some action> so that <some goal/achievement>.
For example:
- As a Copy Writer, I want to read an educational article on testing subject lines so I can optimize the open rates of my email.
- As a Logged in Customer, I want to be able to filter my dashboard by list so that I can isolate data by a specific list.
- As a Conference Attendee, I want to be able to register online, so I can register quickly and cut down on paperwork
- As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.
- As a Developer I can select from configuration options, press a button and have a VM in less than 10 minutes.
Note that an agile user story describes “what” will happen, but not *how* it will happen (so not: ‘…I want to pick an option from a list of three possibilities, using a radio button display’).
INVEST
Packed into the simple format is a great deal of power, provided the following elements are considered (nicely summarized by the mnemonic “INVEST”) :
Letter | Meaning | Description |
|---|---|---|
| I | Independent | The user story should be self-contained, in a way that there is no inherent dependency on another user story. This also means the story is demo-able to the Product Owner/Stakeholder for feedback and potentially releasable (can be beta, a dark feature, or flagged). |
| N | Negotiable | User stories, up until they are part of an iteration, can always be changed and rewritten. |
| V | Valuable | A user story must deliver value to the end user. (Internal or external) – otherwise we call it a task, or a bug, or technical debt. (For more, see: How to Create Value-Driven User Stories) |
| E | Estimable | You must always be able to estimate the size of a user story. |
| S | Sized appropriately or Small | User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty; typically sized so that it can be completed within a single iteration (Sprint). Ron Jeffries, the inventor of User Stories, said that the user story should be small enough to be written on a single index card (3 x 5 or 4 x 6, not 5 x 8 :p ….) Dan Rawsthorne, In Exploring Scrum, wrote: Basically, a good Story is one that is small and well-understood enough for the Team to agree to and not be confused by it. |
| T | Testable | The user story can be tested, and has clear acceptance criteria, and a definition of done. |
Other elements that don’t fit so neatly into the INVEST mnemonic:
- A story often spans multiple disciplines (copywriting, design, engineering) as well as multiple architectural layers: UI, client, and backend. It’s kinda implied by independent – a slice of functionality.
Agile User Story Acceptance Criteria
User stories are designed to start a conversation between the requester (Product Owner, Reporter, or Sponsor) and the Team about the best way to satisfy the story.
The acceptance criteria provide a way to clearly demonstrate that the team has indeed made the User Story come true; they are the “proof” that confirm the story is finished and working as intended.
Acceptance criteria:
- Define the boundaries for a user story/feature
- Remove ambiguity from requirements
- Help the product owner answer what she needs in order for this feature to provide value (typically these are the minimum functional requirements)
- Help the team gain a shared understanding of the story/feature
- Help developers and testers to derive tests
- Help developers know when to stop adding more functionality to a story
Good acceptance criteria:
- State an intent not a solution (e.g. “The user can choose a privacy level” rather than “The user can select the privacy level from a drop-down”)
- Are independent of implementation (ideally the phrasing would be the same regardless whether this feature/story would be implemented on e.g. web, mobile or a voice activated system)
- Are relatively high level (not every detail needs to be spelled out)
- Are written before any work starts on the user story. (Acceptance criteria may be added to or refined as the development progresses and the team learns more.)
Tasks
As mentioned above, a user story is the “what’ – not the ‘how.” The “how” of a story is determined by all the individual tasks to build it. Tasks might include copy writing, image creation, as well as design/layout and engineering work as needed. In JIRA, these are typically “Subtasks” to the parent issuetype=story card. In some cases – like really small user stories that do not touch more than one layer or function – stories do not necessarily need to be broken out into subtask cards.
Shu-level teams often approach task breakdown of a User Story such as “As a new user , I would like to sign up to XYZ website so that I can start using its awesome services” incorrectly in the following way:
- Task 1: Design end-to-end functional tests.
- Task 2: Generate test data.
- Task 3: Develop database layer.
- Task 4: Develop business logic layer.
- Task 5: Develop user interface layer.
- Task 6: Develop end-to-end functional automation test.
While that breakdown seems logical and straightforward (and it can work out just fine) in reality it is mini-waterfall and will likely give the team some headaches.
For example, focusing specifically on Tasks 3, 4, and 5, it is evident that the product owner will find it difficult to verify and validate the requirement until all three of these tasks have been completed. Asking the product owner to verify the database schema changes and related stored procedures (Task 3) won’t necessarily provide reassurance that the development is heading in the right direction (as far as the user functionality is concerned).
Instead, apply a “vertical slice” mindset to break up the above story into constituent tasks:
- Task 1: Develop username/ password functionality (including test design and automation).
- Task 2: Develop email authentication functionality (including test design and automation).
- Task 3: Develop landing page functionality (including test design and automation).
This approach breaks up the story into encapsulated end-user functions, each incorporating some amount of database work, business logic, and UI. By doing so, it becomes possible to start validating much sooner: Feedback in hours rather than days! (Or as in the case of Elephant Carpaccio, a training game for scrum teams, in minutes…)
“Hang on a second – if we can thin-slice a story into smaller functions, then why not make these functions into separate stories rather than subtasks?” Good question.
Mike Cohn provides this advice: “The key is that stories should be written so that the customer can value them.”
Referring to the example above (“As a new user , I would like to sign up to XYZ website so that I can start using its awesome services”) although signing up for the website is certainly something that the customer can value, using a standalone email authentication function is not necessarily of value.
A second answer comes down to independence. If you can split a story into smaller ones and it is possible to independently prioritize them, it makes sense to treat them as actual stories rather than tasks. Referring again to our example, none of the tasks can be separately prioritized because the functionality that the customer values would be incomplete and incoherent.
Instead of eating our cake in layers, let’s eat it in tasty slices so that we can enjoy everything it has to offer in one go!
Epilog
Mike Cohn has a great post: “Not Everything Needs to Be a User Story: Using FDD Features” – And good candidates for the FDD feature approach would be those stories that the team starts to write as: “As a developer…” or “as a product owner….”
An FDD feature is written in this format:
- Starts with the action (a verb) and ends with what would be an object within the system.
- <action> the <result> <by|for|of|to> <object>
- For example:
Estimate the closing price of stock
Generate a unique identifier for a transaction
Change the text displayed on a kiosk
Merge the data for duplicate transactions
More on FDD on Wikipedia and via Mike’s “News from Peak”
Still Hungry?
- Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips
- User Stories Applied: For Agile Software Development. Mike Cohn
- How to Create Value-Driven User Stories
- What Are Some Good Techniques for Writing User Stories?
- What Big User Stories Could be Telling You
- Techniques for Breaking Down Technically Complex User Stories
- The 3 C’s of a user story
- Patterns for Splitting User Stories
- How to Split a Story – Graphic
