Innovate by writing user stories with the right process

User Stories: a step-by-step guide to writing user stories to drive innovation, beyond the usual template, with a concrete example.

Adam Faik
5 min readAug 20, 2022

--

Photo by Joanna Kosinska on Unsplash

A user story is like the cell of an innovating organization: it’s a specification of a unitary element of an ambitious, innovative product.

As an innovation leader, you want your team to write the best user stories. However, some product owners write user stories as a rigid requirement document, thus limiting their team’s creativity. Others stick to one sentence, thus creating confusion. Even at such a fine scale, following the proper process enables you to create value through the product, meet the users’ expectations, and thus innovate effectively.

I wrote +200 user stories when I was a product owner. I’ll walk you through the key concepts you might want your product owners to apply to drive innovation. This graph summarizes the main ideas as it shows the evolution of the level of detail of a user story over time:

Level of detail of a user story over time

Step #1: Start with an Opportunity and Ideas

I managed an online service that allowed citizens to complete administrative procedures. I saw an opportunity to increase the number of acquired users by simplifying the user journey.

I then wrote down my ideas:

  • Citizens no longer need to upload certain supporting documents
  • Citizens have fewer steps to take in the user journey
  • Citizens are supported step by step throughout their user journey

Writing user stories helps to:

  • Describe and communicate ideas to stakeholders in a plain language
  • Adopt the point of view of the user, which has a magic effect of triggering empathy
  • Emphasize the objective to achieve or the problem to solve
  • Prioritize ideas based on assumptions about their impact

Step #2: Test Ideas

I discussed my ideas with the team. I defined and conducted experiments with target users to identify the concept that has the most impact on meeting the initial objective.

Don’t fall in love with ideas, but with the problem to be solved for users.

I then kept this user story:

As a citizen,I want my identity to be confirmed automatically when logging in,so that I no longer have to upload a scan of my ID card.

There are several user story templates, but all are based on the same principles:

  • Specify the user concerned
  • Indicate the motivation or objective of the user
  • Don’t describe too much the “how” so that the team has enough freedom to determine creative solutions

Step #3: Define Acceptance Criteria

I discussed with the team to challenge this user story:

  • Who can benefit from this simplification?
  • What if the identity cannot be confirmed automatically?
  • How to indicate that the identity is secure to the back-office operators?

The answers to these questions are the acceptance criteria for the user story.

Writing acceptance criteria helps to:

  • Give more details on how the user story works
  • Describe the conditions for considering the user story development done
  • Describe how the team will test the code
  • Automate tests using tools such as JBehave, RSpec, or Cucumber

I then wrote 3–7 acceptance criteria using Gherkin’s syntax suitable for test automation.

For example, the acceptance criteria corresponding to the question “Who can benefit from this simplification?”

Scenario #4: the citizen has not updated this ID informationGiven my ID information is not up to date on my profile
When I access the online service to complete a procedure
Then I am asked to update my ID information

Step #4: Prepare the User Story for the Sprint Planning

I used a Definition of Ready (DoR), a checklist to consider a user story ready to be integrated into a sprint.

A DoR may include:

  • A title: a short sentence that summarizes the content of the user story
  • A description: the user story itself
  • A list of acceptance criteria: presented in the form of a Given/When/Then table for ease of reading
  • Wireframes or sketches: drawn by hand or designed using a tool such as Figma
  • Further information: creation and last update dates, product goal to which this user story is attached, forecasted sprint, progress status, priority, metrics goals, comments, etc.

We discussed the user stories during the sprint planning. Then the team developed and tested them during the sprint.

Step #5: Update the User Story at the End of the Sprint

At the end of the sprint, I often had to update the user story slightly to match what the team had developed. I could then specify the “how,” which is the solution identified with the team.

And this is what the user story would look like at the end of the sprint:

Automatic Identity Confirmation

Created: May 26, 2021; Last updated: June 7, 2021; ID: #156; Sprint: #22; Persona: Laure, future retiree; Status: Delivered; Goal: Increase the number of acquired users; Priority: High.

Success criteria

It’s the metric to meet to consider this work a success.

20% increase in acquisition rate within one month

Problem statement (why?)

Describes the problem we’re trying to solve by doing this work.

Uploading the ID card (mandatory document) is a pain point that pushes users to abandon the user journey (negative impact on the acquisition rate). At the same time, their identity could be confirmed automatically.

Description (what?)

Describes how the feature should work for various user types (user story and acceptance criteria).

User story

As a citizen,I want my identity to be confirmed automatically when logging inso that I no longer have to upload a scan of my ID card.

Acceptance criteria:

Describes the conditions for considering the user story development done.

Scenario #4: the citizen has not updated this ID informationGiven my ID information is not up to date on my profile
When I access the online service to complete a procedure
Then I am asked to update my ID information

Requirements (how?)

Describes how the team implemented the feature on the product.

  • Retrieve ID information from the login ID module
  • Log the use of the module on the database and update the date fields.

Takeaways

  • A user story helps communicate with stakeholders in a user-oriented and straightforward language.
  • A user story is not a document or template but an approach to collaboratively co-build the solutions to meet objectives or solve problems. The result of this process varies depending on the team and its Definition of Ready.
  • A user story is not a frozen statement but evolves. First, an idea on a sticky note presents the “why.” Then, it becomes more formal with acceptance criteria and wireframes that express the “how.” The level of detail increases over time.

Going Further

--

--