How to write user stories in Agile development
In the Agile development world, user stories are king. They describe who will be using a feature, what they will be doing and why they are doing it. Listening to your client or product owner and translating that understanding into requirements (and later user stories) is the foundation of any successful project. Without this, alignment and expectations crumble. So, how can you write them more effectively?
How to write user stories
User stories are typically written like this:
As a [user role] I want to [perform some function] so that [some value is realized]
And this works really well as a starting point of discussion when reviewing product backlog items. In determining how to write user stories, the development team must know three dimensions of the requirement:
- Who will be using the feature
- What the feature is
- A notional idea of why the feature is important
Knowing these dimensions helps guide the team to make the right decisions when there is ambiguity and helps guide the discussion of the story’s acceptance criteria (the how). Other forms of requirement development (you know, those requirements that start with “The SYSTEM shall…”) can often leave these dimensions out.
DO: Break apart user stories by value.
Whittling down the size of user stories can be a challenging feat for even the most practiced product owners. The metric to determine if a user story is too large? It can’t be completed within a sprint and/or if they encompass more than one feature.
There are a variety of strategies to trim down user stories into manageable pieces. But, identifying components of functionality that have standalone value (Ex. a given field within an interface) and writing a user story around it has been the most effective in my experience.
For example, say your team is developing a product that will allow users to select a product and ask for a quote. To accomplish this, the development team must create a given field. Break apart the development work to build the field and the UI fine-tuning for the field. Why? Spending additional time on aesthetics would have made the development too large to complete in one sprint.
Why does it work?
It allows the team to focus on the specific user need driving the story.
DON’T: Break stories apart between frontend and backend components.
This is a habit teams often default to. The simple fact is: From the user’s perspective, functionality isn’t done until the frontend and backend are both completed. Teams that do this “break the rules” of Agile software development, because they aren’t delivering the feature in-sprint. They’re only delivering half of it.
The second problem with this approach is: Without developing the frontend, work that might result in a backend bug cannot be detected. It’s more effective to complete the feature with functional backend and a frontend experience that is “done enough.” Then, add extra aesthetics work if desired as another user story down the road.
Why doesn’t it work?
By closing out the related backend user story, the backend development will have made a costly assumption there will be no negative interactions with frontend code. Because the frontend and backend weren’t developed and tested in tandem negative interactions are henceforth unknown. Deferring this unestimated technical debt to another sprint puts the current feature in jeopardy of sloppy development, but can also impact other functionality in scope for future sprints. Avoid this dangerous snowball effect of deferring work.
DO: Create a user story for each function on the screen.
In planning how to write user stories, break all features and capabilities out on their own. Take a form for example. Filling it out is one user story. Validating the form is another. This way, you can deliver the form without validation and get a working product into the customer’s hands more quickly. Later, you can add validation, while they are testing the working functionality. If there are complicated validations, requirements, dependencies within features, these are also broken into their own stories.
Why it works
Separately user stores can be implemented, tested, prioritized or reprioritized giving the development team and client flexibility. By comparison in bloated user stories, nuances are lost and the team overwhelmed.
If scope changes or roadblocks emerge, having a screen (for example) broken into separate user stories allows your client or product owner to reprioritize and stay on-budget.
DON’T: Change the acceptance criteria mid-sprint.
Think of acceptance criteria as the goal posts. During the sprint, your development team is trying to kick that critical field goal. They were expecting a 30-yard kick. Adjusting acceptance criteria is the development equivalent of moving those posts an additional 15–20 feet. All of a sudden the margin for the success of the kick goes way down. Resist the urge and maintain the criteria agreed upon before the sprint on which time estimates are predicated.
DO: Make sure sprint planning isn’t the first time your team has talked about the requirements of functionality being estimated.
Rather when planning how to write user stories, implement a backlog grooming meeting to ask questions and understand the requirements of the functionality before sprint planning. This gives the team the opportunity to communicate with the project leadership. Businesses analysts and product owners don’t often know the intricate technical details your developers and quality assurance team understand that may impact the ability to deliver given functionality in a given timeframe.
Hold the backlog grooming meeting every other week opposite sprint planning. Though most have an inherent aversion to meetings, be disciplined during this time and sprint planning will be a much smoother process as the heavy cognitive load analyzing each user story, asking questions and starting to consider estimates has already been completed.
Why it works
By starting the conversation as user stories rise to the top of the backlog, the team has already begun to vet and ask questions that (if unanswered) could cloud estimate and stall development later. Establishing this process setups the team up with enough information to validate the estimates they give.
DO: Capture the “Mobile Moment” in your user stories.
The concept of the “Mobile Moment” can also influence how user stories are written. The Mobile Moment conveys the idea that there are two additional dimensions that you need to account for in documenting features and writing stories for mobile apps: time and space. That is, when are your users using the app and where are they using it?
The Mobile Moment concept struck me as quite powerful: knowing where and when users are interacting with your app can help you craft more powerful, intuitive features. Take users interacting with a coffee shop app, for example. Considering time and space, users’ desired interactions will change whether they are at home, at the coffee shop, standing outside or at the register.
So the question then is: How do we account for the two additional dimensions represented by the Mobile Moment? The tried-and-true template doesn’t have any placeholders for where or when. Just who, what, and why. The easiest way is just to modify the template, adding the where and the when:
As a [user role], [in a certain mobile moment], I want to [perform some function] so that [some value is realized]
Let’s imagine that you are working on requirements for an urban touring app, and you want your users to be able to see information about different locations on a tour. You might write a story like this:
As [a tourist], I want to [pull up Wikipedia articles about each stop on my urban tour] so that [I can learn more about each location].
The product development team would discuss that story, and they may end up developing a feature in the app in which the user can pull up a map of the tour, choose their current location on the tour, and then tap a button to learn more about that location. While this works, it isn’t ideal. The tourist has to go through several steps to get to the information she wants.
How could capturing the mobile moment in the story help?
Let’s re-write the story to include the mobile moment:
As [a tourist] [on an urban tour at a stop on the tour] [I want to pull up a Wikipedia article] about the current stop so that [I can learn more about it].
The product development team would discuss this story and decide that the mobile device can detect that the tourist is on a tour, and where on the tour the tourist is, so they may develop a feature that launches the Wikipedia entry for the current location when they launch the app. They have captured that tourist’s mobile moment, providing her exactly what she wanted, when she wanted it.
DO: Write write user stories that coherently capture who, what and why.
When incorporating the Mobile Moment, this can be challenging. It often takes a while to format the sentence in a way that both makes sense and captures the intent. Secondly, not every story has a mobile moment. In fact, some apps, such as games, will have very few Mobile Moments. To overcome this, place the Mobile Moment in the body of the user story, near the acceptance criteria:
As a tourist I want to pull up Wikipedia articles about each stop on my urban tour so that I can learn more about each location.
Mobile Moment: While on an urban tour, at a tour site
This method keeps the Mobile Moment in the developers’ minds as they are reviewing the story and helps drive the discussion, but doesn’t get in the way of the user story itself. It may not be as effective as including the moment in the story template, but it also doesn’t get in the way if the story doesn’t have an obvious Mobile Moment.
The big picture thinking behind software shapes the potential user value. A planful process makes it a reality. Make sure both are in alignment with the right user stories.