Backlog Item Types: From User Stories to Research Spikes

Within a product and a team’s backlog, various types of backlog items exist, each serving a distinct purpose and necessitating specific formatting to achieve the intended backlog item goal. In the following sections, we’ll explore the primary backlog item types and their recommended formats.

User Story

A User Story represents a functional aspect or capability of a software system that provides value to its users and is requested by a business stakeholder. User Stories often constitute the primary reasons users choose to use or purchase a software product. Most User Stories involve the visible elements of a system with which users interact to achieve their objectives. Examples of User Stories include functionalities like uploading files, searching for content, or making payments via exposed API.

However, some User Stories may not be visible to end-users but are essential as per the requirements of business stakeholders. These can include security-related requirements. User Stories typically entail code changes within the product and are predominantly authored by stakeholders such as product management, operations, security, and other relevant parties.

The recommended format for a User Story consists of at least two parts: “As a, I want, so that” and Given/When/Then.

As a, I want, so that

The “As a, I want, so that” format for User Stories is a widely adopted technique in Agile software development for capturing requirements from the end-user’s perspective. It serves as a straightforward yet potent way to communicate what the user seeks to accomplish with the system being developed and why it holds importance for them.

This format comprises three components:

1. As a: This part defines the persona or role of the user who requires the feature or functionality under development. The persona represents a typical user with specific goals or needs that the system should facilitate.
2. I want: This part specifies the feature or functionality the user requires to achieve their goal. It should be written in a specific, measurable, achievable, relevant, and time-bound (SMART) manner.
3. So that: This part outlines the rationale or benefit the user derives from having the feature or functionality, explaining the value it provides.

For instance, consider a feature enabling users to filter and sort products on an e-commerce website:

As a shopper, I want to filter and sort the list of products by price, rating, and availability, So that I can easily find products that match my budget, preferences, and needs.

This example’s “As a” segment describes the user’s role (shopper), the “I want” part outlines the necessary feature (filter and sort products by price, rating, and availability), and the “So that” part elucidates the benefits (easy identification of suitable products).

Employing the “As a, I want, so that” format for User Stories helps teams remain focused on user needs and objectives, prioritize features based on user value, and ensure the developed system aligns with user expectations.

Given/When/Then

In the Gherkin format, Given/When/Then (GWT) is a structured way to describe software behavior in plain, human-readable language. It’s commonly used in behavior-driven development (BDD) and helps ensure that requirements are clear and testable. This format comprises three components:

1. Given: This segment describes the initial state of the system or the precondition that must be satisfied for the User Story to be valid. It contextualizes the rest of the User Story and defines the starting point for the feature under development.
2. When: This part details the action or event triggering the behavior described in the User Story. It represents the user’s interaction with the system and often outlines a specific use case or scenario.
3. Then: This section outlines the expected outcome or result of the action or event described in the “When” part of the User Story. It encapsulates the behavior or functionality that must be implemented to fulfill the user’s requirements.

For instance, consider a User Story for a feature allowing users to reset their passwords:

As a user, I want to reset my password, So that I can regain access to my account.

Given I am logged out of my account,
When I click the “Forgot Password” button,
Then I should receive an email with a link to reset my password.

In this example, the “Given” part establishes the initial system state (user is logged out), the “When” part describes the user’s action (clicking the “Forgot Password” button), and the “Then” part defines the expected outcome (receiving an email with a password reset link).

Given/When/Then, typically outlines the main, expected flow of a software feature or behavior, which is often referred to as the “happy path.” It serves as a clear and concise way to describe the fundamental behavior that should be demonstrated in a sprint review as part of the acceptance criteria for a user story.

While Given/When/Then outlines the essential behavior, actual test cases and test scenarios are derived from these steps. These test cases cover not only the expected, happy path but also various edge cases, error conditions, and alternative flows to thoroughly validate the software’s behavior.

Task

A Jira Task typically represents an internal R&D activity. It serves as a supportive element of a software system, facilitating the development and delivery of User Stories. A Task should result in at least one of the following: increased throughput, accelerated delivery, or improved quality of User Stories. These Tasks are often hidden from end-users and remain unobservable to them. Common examples of Tasks include refactoring and updates to frameworks or libraries.

Tasks are predominantly created by internal R&D teams or architects. Unlike User Stories, Tasks do not need to follow the Given/When/Then format or undergo progression testing by QA personnel. Instead, they are typically covered by regression testing.

It is recommended that the Task format will follow the “as a, I want, so that” structure. In the context of Tasks, the user may be an artificial user or an internal user, such as a developer or QA engineer. Employing this format for Tasks serves multiple purposes:

1. Clarification: It defines the required Task in a single sentence.
2. Enabler for future content: It establishes the correlation between executing the Task and the enhancement of future User Stories, be it in terms of quantity, speed, or quality.
3. Challenge: It helps assess whether a Task is driven by a business stakeholder, and therefore should be converted into a User Story.

Bug

A software bug, also referred to as a software defect or glitch, represents an error, flaw, or unexpected behavior in a computer program or software application. These bugs can appear in various forms and can range in severity from minor issues with minimal impact to critical defects causing system crashes or security vulnerabilities.

For effective bug tracking and resolution in software development, a well-structured bug report is essential. A recommended bug report format typically encompasses the following elements:

• Steps to reproduce: A comprehensive description of the problem, including detailed steps to reproduce it. Precise instructions are crucial for others to replicate the issue.
• Expected Behavior: A description of the anticipated outcome when performing the steps that led to the bug.
• Actual Behavior: An explanation of what actually happens, highlighting the gap between the expected and actual results.
• Environment/Context: Specifications of the environment in which the bug was observed.

Research Spike

A research spike constitutes an investigation or research undertaken to gain a deeper understanding of a problem, technology, or concept before its integration into a software product. Research spikes are particularly valuable when dealing with uncertainties or ambiguities in a product, enabling the development team to make well-informed decisions.

The recommended format for a research spike involves creating a list of questions that the research spike aims to answer. Once all questions have been addressed, the research spike is considered complete. These spikes can originate from stakeholders, often centered on use-case-oriented research, or from the R&D side, typically focused on technology-oriented research. In Jira, it is advisable to categorize stakeholder-driven research spikes as Jira Stories and R&D-driven spikes as Jira Tasks.

Conclusion

In conclusion, understanding and effectively utilizing various backlog item types is pivotal to the success of agile software development projects. User Stories, Tasks, Bugs, and Research Spikes each serve unique purposes, enabling teams to capture, prioritize, and deliver requirements while ensuring transparency and efficient communication.

User Stories, with their “As a, I want, so that” or Given/When/Then formats, articulate end-user needs and guide the development process. Tasks support the implementation of User Stories, streamlining development, and maintaining software quality. Bug reports, with their structured formats, are essential for tracking and resolving issues, and enhancing product stability. Research Spikes provide the necessary clarity to make informed decisions, mitigating uncertainty.

By mastering these backlog item types and their respective formats, agile teams are better equipped to collaborate, deliver value to users, and ultimately achieve project success.