Agile eXamined: Alternatives to User Stories

A To-Do List is the backbone of each program/effort/project. It doesn’t matter if you use Scrum, Kanban, or traditional project management. You will have a To-Do List of what needs to be done. For this blog post, we will refer to this To-Do list as the Product Backlog.

A Product Backlog is comprised of individual work items, often called Product Backlog Items (PBIs). We write PBIs so that the team understands what to do and why. PBI’s are intended to be a placeholder for a conversation, not a comprehensive requirement description. Understanding “why” increases the chance that the team will achieve the work item’s intent. It is more important for PBI’s to capture Who-What-Why, and using any of these formats is a tool to help with that.

Many Agile teams use specific formats for their PBIs to ensure they convey this information. The most common format is the User Story, but other formats can be more effective.

User Stories

The basic format for a User Story is:

          As a <WHO> I want or need <WHAT> so that <WHY>.

‘Who’ is the end-user. ‘What’ defines the requested need/action, and the ‘why’ is the desired impact of using the ‘what’.

Strengths of User Stories

User Stories are built around empathy for the end-users. By starting with the end-user and building the ‘what’ and ‘why’ around that focus, User Stories keep the customer front and center.

Weaknesses of User Stories

Not every PBI will focus on a human being. The work of resolving a bug or upgrading an API interface may be difficult to craft as a User Story. System Stories describe this type of work more effectively.

System Stories

The System Story format brings focus to a specific process. A System Story has the same elements as a User Story but describes a particular action to achieve the desired outcome.

The basic format:

          <Action verb> <SUBJECT> So that <WHAT> or <GOAL> is achieved, for <WHO>. 

For example, if you have a team that maintains an API, they may need to improve its response time. They discover the solution is to improve the DNS resolution time. A User Story for this scenario might be written as: “As a user, I would like an API with an improved DNS setup so that I get my information quicker.”

Instead, consider the following System Story: “Use DNSPerf to select the best DNS providers so that an improved DNS setup for our API is achieved for our users.”

Strengths of System Stories

System Stories bring focus to the fact that sometimes our “end-users” are other systems or compliance needs. System stories are perfect for non-functional requirements.

Weaknesses of System Stories

System Stories can include too many implementation details, reducing the creativity of the team. It is good practice to couple them with a research spike to allow the team to discover the best implementation approach before writing the System Story’s details.

Job Stories

The Job Story format focuses on the “job-to-be-done.” For example, as Theodore Levit said, “Nobody goes to the hardware store because they want a quarter-inch drill bit, they buy a quarter-inch drill bit because they need a quarter-inch hole.”

The basic format:

          When <SITUATION>, I want to <MOTIVATION> so that I can <EXPECTED OUTCOME>.

For example: When logging into a system, I want to be able to reset my password so that I can log in if I forgot my password.

Strengths of Job Stories

Job Stories allow teams to create PBIs for products or services used by a wide variety of personas.

Weaknesses of Job Stories

Job Stories’ main weakness is that they remove the focus from individual users and decrease empathy for specific personas.

Gherkin Format

Gherkin Format is a variation on the Job Story format. It is an effective way to describe expected behavior and craft business-driven development (BDD) tests. Some test automation tools (like cucumber) use this format.

The basic format:

Feature: <Title of the Scenario>
Given <Preconditions or Initial Context>
When <Event or Trigger>
Then <Expected output>

Example:

Feature: User Authentication Background
Given the user is already registered and has login information
Given the user is on the login page

Scenario:
When the user inputs the correct login
And the user inputs the correct password
And the user clicks the login button
Then the user is authenticated
And the user is redirected to their personal homepage

Advantages of Gherkin Format

• Gherkin script is simple and clearly understood by all
• Developers can use it as a base for their tests
• Stories can become system documentation
• The Gherkin command set is easy to learn
• Acceptance tests can be linked directly to automated tests
• The format supports reuse across multiple test automation suites

Disadvantages of Gherkin Format

• It requires a high level of engagement and collaboration from stakeholders
• It may not work well in all scenarios
• Poorly written tests can increase the maintenance burden

Summary

PBI templates can be great tools. Don’t limit yourself to just the standard  User Story format. Experiment with alternatives and adapt these concepts to your needs. Remember, a well-written PBI is no substitute for effective collaboration and conversation.