The Anatomy of an Agile Backlog

At Def Method, we use Agile methodologies when working with client teams. The core tenets of Agile philosophy are central to how we operate - rapid software development iteration cycles and clear communication across the team makes for great products. Clear communication in agile stems from encouraging conversations around requirements rather than submitting lengthy, detailed specifications that no one will read. Below we’ve outlined the different types of communication pieces that are commonly used in Agile software development as part of the backlog.

Each iteration cycle, we meet with the team to discuss the prioritized items in the backlog and make sure that we have a shared understanding of the scope and purpose of the item. We consider these backlog items as placeholders for conversations and essential vehicles in driving clear communication.

User Stories

What is a User Story?

A user story is a short, simple description of a feature told from the perspective of the target user who desires the new capability. It describes what the user wants and why. It excludes any technical references. User stories constitute the meat of most backlogs.

A user story is scoped to a self-contained unit of work agreed upon by the developers and stakeholders. We usually follow the INVEST guidelines for writing stories.

Typically, user stories take this form:

AS A ____________ (←Person Requiring Action)

I WANT TO _________ (←Requested Action)

SO THAT ___________ (←Business Justification / Benefit)

Example:

AS A consumer

I WANT to create a customized shopping list

AND I want to be able to access this when I log into my online shopping account

SO THAT my shopping experience is improved

Another common format for writing user stories is the Jobs To Be Done (JTBD) methodology where the template is in the format:

WHEN _________ ( ← Situation the user is in)

I WANT TO_________(← Motivation)

SO THAT _______( ← Expected outcome)

The team should decide on which approach to story writing will be most effective for the product they are working to build. If the situation is critical to the story, a Jobs to be Done story may be best.

The Story should be followed by detailed acceptance criteria written in GHERKIN or another method that clearly defines the scope of the story including the way that the software is expected to operate once it’s delivered.

User stories structured in natural language help clarify and clearly communicate the value of the work to be completed to both the engineering team and non-technical team members. The needs and wants of the end-user become the focus of the solution, not the solution itself. Sometimes, there are simpler ways to meet the needs and wants of the users. By focusing on the outcome (the value) rather than the output (the specific solution), we allow the team to have productive conversations about how best to deliver that value.

Stories can often be organized into Epics to help communicate progress in thematic areas to stakeholders, or to manage tracks of work and avoid collisions.

Bug tickets

“Bugs” in software development is the term used to refer to a glitch in the system where the program didn’t behave in the way it was intended to. Bugs are discovered during QA and testing of the app but can also be reported by end users of the app when they encounter an error or eccentric behaviour in the software. To report a bug, a bug ticket is created.

A bug ticket should have a clear and accurate title that provides some context about the issue caused by the bug. “Error occurred” is a bad example of a bug title. A better example is “File Manager Crashes when user login error occurs”.

The description of a bug includes what was expected to occur and what occurred instead. It should also include precise steps to reproduce the bug so that the developers can re-create the scenario to identify what may be causing the glitch, and to verify that they are able to fix the glitch. Providing any additional information about the environment (such as the browser, computer etc.), associated data (what was entered), and screenshots are useful in identifying and fixing bugs.

Spike

A “spike” in engineering lingo is work that’s undertaken to learn about or explore possible solutions. The spike is meant to deliver more information about how much work is required to solve the problem. On completion the spike will often result in the creation of a User Story (or set of stories) or Task around the development work based on the learning from the Spike.

A spike ticket will normally include a description of the problem we want to solve and specify what the desired outcome from the spike is - whether it’s the level of effort, a recommendation of a library to use, or other goals.

Spike tickets rarely involve coding. A good template for a Spike is:

Before we <dependencies>

We should <research item>

So that <outcome of research>

At completion of Spike we: <outcome of the spike>

Often research oriented spike tickets are timeboxed to prevent engineers from getting too caught up in the research and spending too much time on the ticket.

Task or Chore

Depending on what project tracking tool you are using you may come across a ticket of type “Task” or a “Chore”. A Task or Chore refers to a piece of work that does not directly have any user or business benefit associated with it, but helps the engineering team to work more effectively. Common examples of Tasks are: setting up infrastructure, building the product’s architecture and refactoring work.

Tasks are often technical in nature and have no specific user test criteria that the client representative can test. They can be written as:

We should <complete some task>

Before we <any dependencies>

So that <outcome of the task>

We will know we are done when <conditions that need to be true for this to be considered complete>

Note: We recommend timeboxing certain chores to prevent them from becoming rabbit holes.

Your backlog is a product

At Def Method, we apply some product thinking to our backlog management by considering who is using it and what they need to get from it. The above outlines the common ticket types that constitute most agile backlogs, but how and when to use them should be informed by the primary “users” of the backlog: our engineers. It should also account for any secondary users of the backlog such as designers, stakeholders or the product manager. We work to understand the goals of each “user” of the backlog and hold regular retrospectives to understand when those goals are not being met. This helps us iterate towards a backlog management approach that supports our team and enhances communication across the board.

Learn More

Subscribe to our monthly newsletter to get notified about future articles.