Defining Great User Stories

User Stories are a central part of agile development. Their introduction brought the User into focus and helped with a mindset change: always start from what the user needs, understand him, and his problems and focus on the outcomes of any given feature implementation.

User stories also allowed the switch from writing requirements to discussing them. Still, if you ask a random person about what a User Story is, you will usually get something around a Jira ticket or a physical card describing a software feature. According to Ron Jeffries, founder of XP software development methodology, a User Story has three essential aspects: Card, Conversation and Confirmation. The Card is the first draft in defining the User Story. The Conversation is the exchange happening with the development team, usually in Refinement meetings that will generate further details inside the US body. The third part is the Confirmation: „How do we know when we are done?” which usually is represented by „Acceptance Criteria”.

Let’s go through them in more detail!

Card

The most common template for writing an User Story is:

As a <user> I want <function> so that<value>.

where the tags stand for:

<user>: who is the persona or a role using your application? It can be either the user or purchaser of the application.

<function>: what do you want to achieve with this story? It should be expressed in a business language, defining a direct benefit for the user and written from his point of view. Always put yourself in their shoes when writing User Stories.

<value>: what does the user want to achieve with that? What is his end-goal? Knowing the goal constitutes an essential basis for the discussion on how to implement the US, both from a user experience and a technical point of view. It is important for you as PO to correctly define/encompass the value created within an US, in order to correctly focus on the outcome — impact, and not output — delivery. Doing it right enables the Development team to creatively participate in the problem-solving ideation process creatively.

Another popular way to define a User Story is the “jobs to be done” format:

When <situation>, I want to <motivation>, so I can <expected outcome>.

where the tags stand for:

<situation>: what is the context in which I am framing my problem? This is the place to add contextual information describing the boundaries and preconditions of the scenario(s) you are trying to solve.

<motivation>: what do I want to happen when I am in the above situation? As with the previous format, make sure that you address the wanted behavior and not the solution.

<expected outcome>: why do I want that? This is very similar to the <value> part in the previous format.

This format works best for:

· More mature products

· B2B products where the personas definition brings little value, roles are few so the <user> part in the standard US format does not really bring valuable information regarding the context

· The feature applies to multiple roles (e.g. changing the password for an account)

· When you want to focus more on the Why and less on the Who

Conversation

Conversation generates further details on to the previously defined Card.

What should you focus on? Independent on the format you choose to use, a good user/job story definition follows some guidelines in order to get the maximum definition “score”. Most widely used set of quality checks are gathered under the acronym INVEST, which stands for:

Independent: the story should not depend on stories not yet delivered either by your team or by a different one.

What could happen is that stories do not get delivered in time, or additional effort is needed for refactoring. To minimize risk, develop dependent stories in different sprints. But what if that is not feasible because of stringent time constraints? Negotiate in advance technical contracts between the dependent parties (go as much in detail as possible: format, fields, types, manually generated sample data if possible).

Negotiable: the story should not contain too much information before presenting it to your development team.

The downside is that you will get exactly what you asked for, but not necessarily what you or your customer needed.

A recommendation is focusing on the What (output, result) and on the Why (outcome, value), but do not go in the “How.” Avoid providing technical solutions or mock-ups, but feel free the discuss your ideas together with your team.

Remember that initially, the US was supposed to fit in only one post-its card. The purpose of the Conversation is to search for solutions, discuss constraints, and limit cases actively. Every information that you add extra on your “card” is a new boundary that you add to your development team’s creativity.

Valuable: the story should provide value to the user (the keyword being user here)

The goal is to minimize waste (deliverable that do not contribute to your objectives). There are several options here depending on the underlying issue: try to do the slicing vertically (so that each part has business value) and not horizontally (based on technical areas), include refactoring as part of existing user stories, underline the business value by focusing on the outcome (for example: “As a user, I want the website’s performance to be improved without affecting its behavior, so I can use it anytime with 100% availability”).

Estimable: development team should be able to provide an estimate for the user story

The major risk here is this being a symptom of the US not being clear. A second risk is not having predictability on your deliveries. Again, there are several roads you could take here: split it in several stories if it is too large, do a Spike before the actual story if it is not sufficiently clear, split the story into tasks and estimate them if the story is simply too complex.

If you want to align the team, use the so-called Planning Poker (Scrum Poker) estimation technique. It will help the team members estimate without influencing each other and it will speed up the estimation process. There are several free tools available for that.

Small: a user story must fit in one sprint, by reaching the Definition of Done that you have defined for your product (usually this includes code review, testing and/or documentation).

If you are not working Scrum, then you should still focus on delivering and getting the feedback from the customer as soon as possible (the sweet spot is between 3–4 days and 1–2 weeks).

A possible fix here would be to split vertically as much as possible (but usually not less than 1–2 days of work). You may use Epics for grouping several US in one big feature, so the bigger picture is not lost in the splitting.

Testable: you should have clearly defined scenarios for considering your story done.

The goal is to align the expectations between the PO, the Development Team and the customer by fulfilling the acceptance criteria. Handling this issue is referred to the 3rd part of the user story: Confirmation.

Confirmation

After all it is said and done, how does the Delivery Team know when they have completed the story? This should be defined in the Acceptance Criteria for your US.

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by the customer. They define clear boundaries for the user story on several levels: functional, non-functional (non-functional conditions, like design elements) or performance(eg response time).

In other words, they provide the answer to the two important questions: “Did we build the right product?” and “Did we build the product right?”.

Two commonly formats used for acceptance criteria are:

• Rules-oriented (checklist rules) or
• Scenario-oriented:

Given [preconditions] when [trigger action] then [expected result]

How to use Acceptance Criteria the right way:

• All US should have an Acceptance Criteria defined before the actual work is started
• Focus on the expected behavior (the What) and not on the solution approach (the How)
• Each criterion must have a clear Pass/Fail result
• Each criterion should be (independently) testable
• Acceptance Criteria should not overlap with the Definition of Done (e.g., Have code review done)

Above and beyond

If you have mastered all the above, what should you focus next to reach beyond?

To create a great user experience, focus on prioritization techniques as Kano Model, MoSCow method, Cost of delay, etc. and employ other product management approaches besides user stories. While User Stories are great for capturing product functionality, they are not the best technique for describing user journeys or visual design. Therefore, other techniques may be added to your toolkit: story maps, workflow diagrams, storyboards, sketches, mock-ups, among others.

Conclusion

Writing user stories is quite easy. Writing great user stories can become a little tricky.

In the end, remember the essence: User Stories are, beyond product specifications, a collaboration tool.

Their simplicity is intentional and reminds us that we are people developing software for other people and no technical layer of requirements should make us lose sight of this.