This is the second in our series on Agile for Executives. You can find the first post in this series here and the third post here.
Sometimes you don’t know what you want. You aim for a specific user outcome, but don’t know how to get there. To help encapsulate uncertain solutions, agile offers user stories.
What is a User Story?
Within the agile world, user stories describe concise, narrowly defined, unrefined approximations of a use case for any given functionality. Oftentimes, they serve as a placeholder with enough context for a further conversation between an engineer and the stakeholder.
These stories usually follow an “As a [user type], I want [goal], so that [outcome]” format. This takes the pressure of designing a solution off of the requester and instead gives the engineers flexibility with how to solve the problem.
Following this format ensures that stories are clear and follow a user-centric approach. By clarifying the role at the beginning, the implementation can design with them in mind and test appropriately.
Further, by expressing the end goal of the enhancement, a story clearly states the expectation of the user. When getting clear on expectations, clarity is caring.
Lastly, the story links the story goal to a bigger outcome. You will recall from the previous article that outcomes focus on problems solved and use cases, and provide parameters for user success. Categorizing a user story under an outcome allows the Product Owner and stakeholder team to prioritize one story against another as they identify which stories align with the product goals and objectives.
These stories rarely make it through the pipeline with this little information. Most often they’re a starting point for discussion and create room for creativity. Normally, the process of refining stories into actionable content will take place through a refinement process that looks different depending on the work itself.
Refining a story from the initial one-liner to a spec’d out enhancement means clarifying the intent of the request, creating acceptance criteria, addressing ambiguities and assumptions, and aligning with the team about the best contextual approach.
Why Employ User Stories?
Why be so picky with words? Why limit how I ask? Why not ask for super specific things? Let’s look at two approaches to the same request and highlight the different results.
Ticket: Build a “submit new address” field and put it at the bottom of the list of settings on the profile page styled in the provided design.
This request follows the model of an explicit request, provides some structure, and presumably a polished design. While initially giving enough detail to get started quickly, it actually leads to suboptimal outcomes in the application.
Rather than a description of what someone wants to do, it provides a prescription without any context. This limits any conversation around how this fits into the user flow and cuts off alternative solutions. While this will generally get you the request exactly as you asked it, the request locks you in on a model when several other options are available. It also lacks, context, so the engineer doesn’t know which use case this addresses. Is this when the user moves? When they are sending a gift? Is this just to change their profile information?
To contrast, let’s take a look at a user story version of the same request and explore the flexibility in it.
Ticket: As an external user, I want to be able to edit my address, so that I can receive shipments wherever I am.
This same request comes in as a user story. It provides a user, action, and end goal, setting the context for the change from the outset. It does not provide a location for the change, a title or structure of the end result, or attached designs.
Instead, it explains the core concept and the rationale within the context of the user. From this story, you can understand that the user wants to change specifically their shipping address within the context of order fulfillment.
From here, the team can open conversations around where to place this new functionality, whether to overwrite a single location or retain multiple addresses, and if this should exist as a pop-up on several screens rather than an option in the profile. The initial request provides no room for these conversations by prescribing a solution.
The story also explains why the stakeholder submitted this: ”…to receive shipments wherever I am.” Understanding the desired outcome gives context to the engineers as to why this request even came in. It also gives the Product Owner something to work with. As they work on prioritizing this ticket, they can research how many users actually want to ship to multiple locations, how frequently they move, and if this is a common request or a fringe case.
Understanding your users and their use cases allows you to better prioritize the work that you do as it relates to their outcomes.
Stories Build Outcomes
User stories play a crucial role in building user outcomes by capturing the user’s needs, goals, and desired benefits.
Stories are slices of bigger outcomes. Visualize this by tying your individual user story to the bigger narrative of why people use your product: What outcome benefits from this user story? How does the specific action the user needs fit into the larger goal of the user experience? Linking your feature ask to a prioritized outcome allows your Product Owner and the stakeholder team to work on the most important stories first.
By reformatting your requests into user stories, you enable the product team to provide the best solution to the users. Slowing down and posturing requests without solutions results in a flexible and empathetic user experience and cultivates empathy throughout the organization as well.
User stories put the user first and focus on their best outcome. The result is a better workflow for your team, a better product for your users, and better business results for your organization.
Agile can be the foundation for your success. Learn how we can put it to work for you by getting in touch today.
