User Stories
In my workshops and during my agile coaching sessions,I have found that many new “agillists” struggle with the creation of user stories, particularly in the beginning of their journey. It seems to be difficult to figure out what constitutes a “good” story. A lot of people will try to start out with the familiar agile format of; “as a user, I want to do this, for that reason,” but quickly find themselves running into issues of finding the right story size, complexity, scope, and various other factors. Fortunately, experience has provided a good framework for managing these issues.
Mike Cohn specifies six fundamental attributes of a good user story in his book User Stories Applied. These are;
(1) independent,
(2) negotiable,
(3) valuable to users or customers/purchasers,
(4) estimable,
(5) small,
(6) testable.
Independent, For the sake of planning and prioritisation, stories should not be dependent on one another. Therefore, individual stories should be as atomic as possible to allow maximum flexibility of scheduling and development. However, situations often arise where stories have inherent dependencies, such as payment processing, where the first story will incur the overhead of building the supporting infrastructure, which will then reduce the size/complexity of the remaining stories that take advantage of it. The problem, of course, being that this will force the team to attempt to attack the prioritisation of dependent stories while the stories are still being defined, so that the individual stories could be properly estimated.
One solution to this is to roll all the dependent stories into a single story. This is applicable if the resulting story is still relatively small. However, if collapsing the stories results in something large and complex, another strategy is to temporarily treat the infrastructure development as a separate story for estimating purposes, and annotate, during story prioritisation, that this story should be rolled into the first story that requires the infrastructure to be built. The resulting combined story should then be re-estimated, and overall priority adjusted accordingly.
Negotiable. By definition, user stories are placeholders for discussion and progressive elaboration. Thus, stories should be defined, at any given time, only to the level needed to suit the purposes of estimating and prioritisation with respect to the applicable planning horizon. For release planning, this is at the relatively high level needed to provide a “good enough” estimate as to size and complexity. Later, during iteration planning, more detail will be added, as needed, to provide a “good enough” estimate of tasks (and duration) needed to plan the iteration. And, during daily planning, even more detail may be added in the form of diagrams and other artefacts that a developer may need to actually develop it. However, at every step, the attribute of negotiability is maintained, as acquired domain knowledge, overall construction, and user feedback work to refine desired functionality. Note, also, that this may trigger splitting of a story and/or re-estimating.
Value to users or customers/purchasers. In his definition of this attribute, Mike Cohn makes the distinction between those who use the software, and those who purchase the software. For example, users don’t generally care which platform a software package runs on, as long as it runs on theirs. However, a purchaser may have a requirement that the software support specific versions of Internet Explorer (or Firefox, etc.), or some other standardised platform. These would be captured as stories for estimation and prioritisation, along with stories for specific functionality requested by the users.
What about developers, you may ask? Isn’t it possible that they have stories – often related to specific architectures and technical errata – that should be defined and placed on the backlog?
The answer to this is usually no. While these may be of benefit to the programmers, they don’t necessarily demonstrate measurable benefit to the users and/or purchasers of the product. Therefore, when these stories arise, they should be worded with respect to the value they provide to the users/purchasers, such as “business rules should be processed in ten seconds or less” as opposed to “the system should use an n-tier architecture to improve performance.” This allows the stories to be worded in a way such that they can be prioritised in relation to the other, user/purchaser stories on the backlog, and allows the developers to define solutions to specific problems, instead of general solutions that may be harder to quantify (and justify) with respect to business value.
Estimable. Obviously, this is an important attribute, since estimating story size is a central part of the planning and prioritisation process. However, Mike Cohn points to three fundamental issues that may impede story estimation: Lack of domain knowledge, lack of technical knowledge, and story size.
If the development team is having a difficult time estimating a story because it doesn’t fully understand the feature, then this as a signal that the user(s) who asked for the story need to provide more information so the team can make an informed estimate. If the story can’t be estimated because of unfamiliar (or non-existent) technology, then the answer is to either acquire people who understand the technology, train team members on the technology, or conduct a small research project (or prototype) to gain enough understanding so as to provide a reasonable estimate. If a story is too large, then it should be split in accordance with the guidelines provided next.
Small. The next attribute of a good story is size; specifically, smaller is generally better. This is not to say that a story can’t be too small, because it can. But, to a point, smaller is usually better because smaller stories tend to be easier to estimate, and with less variability than larger stories.
When it comes to story size, Mike Cohn identifies two basic determinations: compound stories, such as epics, that contain additional sub-stories, and complex stories that do not easily lend themselves to splitting into smaller stories. Splitting of compound stories is generally relatively easy: you just split the story into its constituent parts (minding dependencies, as previously noted). Complex stories, however, can be difficult to split because they may contain sub-stories that are tightly interrelated, or some other issue that makes splitting difficult.
One common way of splitting complex stories is called “slicing the cake.” By this method, the story is sliced by identifying the minimum amount of acceptable functionality that cuts across all layers of the underlying technology or process, then splitting everything else out into a separate story as “additional functionality.” This way, the users can be provided with something that works, albeit in a reduced configuration, with the option to add the rest of the functionality as priority determines. Another way of splitting complex stories is to create a separate story called a “proof of concept.” This is generally useful when working with new or little understood technology, and allows a prototype to be produced that provides an example of a working solution. Once the proof of concept has been completed, knowledge gained can be used to provide a better estimate for the original story.
Testable. The final attribute of a good story is that it is testable. Non-testable stories usually manifest themselves as vague requirements, such as “the user must have an enjoyable experience,” or something equally non-quantifiable. Stories such as this should be discarded, or rewritten in quantifiable terms. For example, “the user must have an enjoyable experience” can be rewritten as “the application must score at 80% or above on the provided user survey.” This provides a distinct, testable metric which allows the story to be quantified and prioritised.
So, there it is! I now have provided you with the silver bullet and the main six attributes that provide an excellent framework for creating user stories in such a way, to make them easy to estimate, plan, and achieve and the bases of a proper product backlog and a successful agile project delivery.
You probably will think now, wait a minute. This framework is nice and so, but how do I actually create a user story? Let’s go through the user story creation process step by step.
Step 1. Users Come First
As its name suggests, a user story describes how a customer or user employs the product; it is told from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific functionality, such as, searching for a product or making a booking. The following picture illustrates the relationship between the user, the story, and the product functionality (symbolised by the circle).
If you don’t know who the users and customers are and why they would want to use the product, then you should not write any user stories. Carry out the necessary user research first, for example, by observing and interviewing users. Otherwise, you take the risk of writing speculative stories that are based on beliefs and ideas, not on data and empirical evidence.
Step 2. Use Personas to Discover the Right Stories
A great technique to capture your insights about the users and customers is working with personas. Personas are fictional characters that are based on first-hand knowledge of the target group. Personas are usually created via a template and consist of a name and a picture; relevant characteristics, behaviours, and attitudes. An important feature of this persona template is the addition of a goal. This goal is the benefit the persona wants to achieve, or the problem the persona wants to see solved by using the product.
There is however more to it: The persona goals will help you discover the right stories: You have to ask yourself which functionality the product should provide to meet the goals of the personas.
Step 3. Create Stories Collaboratively
User stories are intended as a lightweight technique that allows you to move fast. They are not a specification, but a collaboration tool. User Stories should never just be handed off to a development team. Instead, they should be embedded in a conversation: The product owner and the team should discuss the stories together. This allows you to capture only the minimum amount of information, reduce overhead, and accelerate delivery.
You can take this approach further and write stories collaboratively as part of your product backlog grooming process. This leverages the creativity and the knowledge of the team and results in better user stories.
If you can’t involve the development team in the user story work, then you could consider using another, more formal technique to capture the product functionality, such as, use cases.
Step 4. Keep your Stories Simple and Concise
Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out the rest. The template below puts the user or customer modelled as a persona into the story and makes its benefit explicit. It is based on by Rachel Davies’ popular template, but I have replaced user role with persona name to connect the story with the relevant persona.
As <persona>,
I want <what?>
so that (because) <why?>.
During my work as product owner I have found that using this template is helpful, but it will not always fit the requirements of a user story. I would urge you to use this template when it is helpful, but don’t feel obliged to always apply it. Experiment yourself with different ways to write your stories to understand what works best for you and your team.
Step 5. Start with Epics
An epic is a big, overarching story. It is typically broken into several user stories over time—leveraging the user feedback on early prototypes and product increments. You can think of it as a headline and a placeholder for more detailed stories. In a software delivery project you can see the features of the product as epics.
Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for describing new products and features: It allows you to capture the rough scope, and it buys you time to learn more about how to best address the needs of the users.
It also reduces the time and effort required to integrate new insights. If you have many detailed stories in the product backlog, then it’s often tricky and time-consuming to relate feedback to the appropriate items and it carries the risk of introducing inconsistencies.
If we look at an earlier used example “Scrum Air” one of the epics could be “Find flight options, where several user stories are linked to.
Step 6. Refine the Stories until Ready
Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. All development team members should have a shared understanding of the story’s meaning; the story should not be too big and comfortably fit into a sprint; and there has to be an effective way to determine if the story is done.
Step 7. Add Acceptance Criteria
As you break epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the narrative (It is the statement after “So that I” or “Because”): They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story, they make it testable, and they ensures that the story can be demoed or released to the users and other stakeholders. From my experience, I like to use three to five acceptance criteria for detailed stories.
Step 8 Don’t Solely Rely on User Stories
Creating a great user experience (UX) requires more than user stories. User stories are helpful to capture product functionality, but they are not well suited to describe the user journeys and the visual design. Therefore complement user stories with other techniques, such as, story maps, workflow diagrams, storyboards, sketches, and mock-up’s.
Additionally, user stories are not good capturing technical requirements. If you need to communicate what an architectural element like a component or service should do, then write technical stories.
Finally, writing user stories is worthwhile when you develop software that’s likely to be reused. But if you want to quickly create a throwaway prototype or mock up to validate an idea, then writing stories may not be necessary. Remember: User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible, not to add any unneeded overhead.
So now you know everything there is to know and nothing prevents you further from writing great user stories.