Often Business Analysts cover a Product Owner’s role as well and are responsible for managing the backlog – creating tickets, refining and ordering them.

In my practice I used mainly the following three types of tickets: User Stories, Bugs and Spikes. There could be tasks as well, however I won’t cover “Tasks” now, as those are pretty straightforward, usually technical and  written by the engineers themselves. 

Tickets in the backlog should be easily understood by the whole team, should outline the requirements and the desired result. They should be clear and testable. 

User Stories  

User Stories communicate value and the user perspective to the team. Their purpose is to state the “what” and spark a conversation in finding out the “how”. My advice would be to keep stories short, simple, informative for everyone and descriptive enough to enable development.

Example components of a user story: 

  • Description in the format 

As [a user = reader/editor/marketing team member/…], 

I want /need to [ “what” the user needs] 

so that I can [the goal, why user needs it]   

  • Requirements
  • Context/Background
  • Acceptance criteria (A/C) : Usually conditionals to validate that what is done is what is required  (“when, then” format). A/C tells when the user story is working as intended and what success looks like from a user perspective. 

Example: 

When I select the checkout, then my stored payment methods are displayed to me.

Spikes

Spike is a research ticket – the engineering team should explore what are the possible approaches to implement the chosen solution. If you go with the spike, state clearly what is the goal and the expected outcomes of the spike. Agree with your team what is the best way to communicate the findings of the spike – would they be added to the ticket or in a separate doc, when and how will they be discussed with the whole team. Remember, the purpose of the spike is to reduce uncertainty and provide more information on a topic the team is not familiar with so that they can build a feature. 

Bugs 

Bugs describe an unexpected malfunction of the software. It can relate to a feature not properly developed or a side effect of development (regression). 

Example components of a bug are: 

  • Expected behaviour
  • Current behaviour
  • Affected environment
  • Scenario and steps to reproduce

Product backlog tickets are usually not written in one go. As a team working in an agile environment we’ve had many ceremonies such as “backlog refinement” or “grooming sessions”, where tickets were being reviewed with the whole team – developers, designers, business analysts, product manager. In these discussions the role of the business analyst is to present the tickets to the team, provide clarity when needed by answering their questions and can end with a homework for the BA – to discover more information. Tickets might be sliced into smaller ones or new ones can be added.