User stories: You’re (probably) doing it wrong.
Scrum, and most agile methodologies, are built on a fundamental construct: The user story, which specifies the smallest unit of development that provides value to the end user. Often expressed in the form “As a <<user>>, I want <<feature>, so that <<benefit to user>>”, the user story is a simple concept, but one that continues to confound even experienced agile practitioners.
The truth is that the ability to write great user stories — ones that are small, provide clear and distinct value to the end user, and can cleanly map to implementation tasks for ease of estimation — is a skill that is developed and continually refined through practice. It helps to have a product with a clear vision of how it will benefit the user and an organizational structure that encourages agile best practices.
Do your user stories measure up? Put yourself to the test with the following checklist to see if you’re a user story all-star — or if you’ve been doing it wrong the whole time.
My user stories are always from the perspective of the end user
If your user story starts with “As a developer…”, or you’ve organized your teams by the type of code being produced (e.g., front/back end), you’re already off to a rocky start. User stories create value for the end user of the proposed functionality, period. “Stories” that do not meet these criteria include:
- “Stories” that refactor code but don’t actually produce any immediate benefit to the user
- “Stories” that produce code for other internal development teams, e.g., the creation of an API endpoint.
- “Stories” that are strictly research and do not actually involve producing functionality.
It’s tempting to write these types of stories: Sometimes the work to be done doesn’t fit neatly into a true user story, or the technical complexity is extremely high and the story may not be able to be completed in a single sprint. But resist the urge! You can usually address these in a more effective manner by creatively decomposing your story or performing any necessary refactoring incrementally over time.
For instance, instead of a story that says “As a user, I would like a quote on car insurance…” decompose it into several stories that segments your user base, e.g., ‘As a single driver with a single vehicle and no accident history, I would like a quote on car insurance…”. In extreme cases, reduce the scope of the story even further by identifying a single (potentially fictional) user: “As Sam Smith, a 42-year-old living in Phoenix, AZ, with a 2007 Honda Civic EX, no accident history, and a bachelor’s degree…”. Getting creative in your user story decomposition allows you to maintain your focus on the end user without biting off more than the team can chew.
My user stories define the minimum amount of effort necessary to provide value to the end user
I have yet to meet a (good) developer that has said “I prefer to do the absolute minimum necessary.” But, perhaps counterintuitively, this is exactly what you want with your user stories. If a story could be broken out into two or more stories which each provide independent value to the user, it should be split. By keeping individual stories small you can deliver value to your users faster and more reliably by ensuring that more code can be incrementally delivered at end-of-sprint.
As an example, think of a typical login screen for an application: It usually consists of a username field and a password field; there may be validation to ensure that the username and/or password follows certain patterns; there may be a checkbox allowing the user to stay logged in or save their username; there may be a way for the user to reset their password; there may be a way for the user to log in using another authentication method. It’s tempting to lump some or all of this functionality under a single user story, but keep it as granular as possible to prevent a situation where a release isn’t possible due to half-finished code.
Using the above example, keep the login field validations separate from the login itself, since most users will type their e-mail address in the correct format anyway. Take this principle to the extreme by segmenting individual validations into separate stories, and prioritize them in order of likelihood to affect the user.
This example further demonstrates the need to have a clear understanding of the distinction between three key agile concepts: user stories, acceptance criteria, and development tasks.
A user story defines the minimum amount of effort necessary to create value for the user; acceptance criteria, by contrast, define the minimum conditions — from the perspective of the user— that must be met for the user to actually realize the value described in that user story. In other words, if ANY acceptance criterion fails, the user gets no value from the code developed. If this is not the case, and the user could get benefit from only a subset of the acceptance criteria being met, it is a sure sign that your story is too big and should be broken apart.
Development tasks, on the other hand, are just that: Tasks that need to be accomplished as part of the successful implementation of a given user story. Tasks, unlike user stories and acceptance criteria, are from the perspective of the developer, and do not provide independent value to the end user. The creation of an API endpoint is a classic example of a development task: An endpoint alone usually does not create value for the end user; only when combined with front-end code that allows the user to interact with the endpoint can the user actually benefit from the code created.
My user stories actually tell a story
I see a lot of user stories that go something like this: “As a user, I want to reset my password”.
Aside from the fact that the story is missing the why clause — which can help provide crucial context to the developer tasked with its implementation — the story is so generic and bland that it’s almost certainly too broad. Does the software have multiple ways to login (e.g., username/password, OAuth, biometric, etc.)? Are there multiple reasons why a user might need a password reset (e.g., forgotten password, locked account, etc.)? Are there different types of users with different physical capabilities (e.g., color-blindness)?
Without answers to any of these questions, the story can be widely interpreted. When this situation occurs, it’s not all that surprising that miscommunications occur and expectations are missed. Instead, improve your story by getting specific about who your user is, what their particular situation is, and what they hope to achieve, both immediately and in the longer-term.
It’s easy to dismiss an exacting analysis of user stories as an exercise in arguing semantics. As long as the development team understands what needs to be done, after all, why should it matter if a user story follows “the rules”?
The answer, of course, is it’s a slippery slope down to user stories that are confusing, incomplete, and don’t actually provide value to the end user. What starts out as a little laziness in crafting user stories can quickly snowball into entire pieces of software that have to be shelved because they aren’t user-ready or fail to deliver the intended benefit.
Instead, lavish your user stories with the time and attention they deserve — and then revel in the great software that they will help create.
