Tickets, Please?

There are many things in the tech world that are difficult, like complex database architecture, in statistical modelling behind geometric deep learning and even writing robust end to end tests. Communicating your work clearly to your team shouldn’t be one of them.

What is a ‘ticket’?

In the context of Agile working practices, it is essentially a succinct summary of an individual piece of work that is going to be undertaken. Often these are added, prioritised and tracked on a management system. The most commonly used one in industry is Jira, but there are others such as Trello, Upwave, GitHub, Azure Dev Ops, GitLab etc.

The goal of ticketing work is so that large pieces of project work can be broken down into smaller chunks that take a small amount of time that can be distributed amongst team members. The specific ways of working depend on the agile framework the team is working from, you may have heard of scrum or kanban? Whatever the ins and outs of ways of working, the ticketing system is central to them. So for now we can focus on that in isolation.

It's helpful to remember there are two audiences for your ticket, which is often forgotten. Of course, the first audience group is the product team (incl developers, any anyone else working on the team) - to allow for visibility of the work and give a shared understanding of what needs picking up and what "success" looks like. The second audience, that can often be forgotten, is the stakeholders who asked for the work in the first place. It is helpful to have these tickets for transparency of what is being worked on and for progress tracking on their side. This is helpful to help them to understand the work that goes into their asks and manage expectations too.

What should I include when writing a ‘ticket’?

Here’s where there are different schools of thinking, in my view there isn’t one right way of writing a ticket but there are crucial things that should always be part of any ticket, however your team chooses to work and however your team chooses to structure this. Some of these things are guided in the different management systems, but others are more free.

Description of task: what is the piece of work you will be completing if you take on this ticket? A few lines that means that someone else in the team would know what you’re doing.

This is sometimes writing in the As a, I want, So that. For instance: As a Data Scientist, I want calculate the correlation coefficient of variables X and Y, So that I can understand the relationship of my data to decide a model to apply to them.

Some tickets might be clear just with the above format, where the user journey is represented. For others, it might be handy to have extra text to give more details. You might also want to link in some documentation which could provide further context or clarity that doesn’t need to be in the ticket but is helpful for the person picking up the work.

Acceptance criteria: at what point is this piece of work considered complete? What needs to be done to say, yes this is ticked off the list.

Here, I personally like clear bullet points of the different things needed to view the ticket as completed. However, people have different preferences (as with everything).

One structure people like to follow is Given, When, Then. For instance, to follow on from the above example. Given the provided data, When I run the correlation function, Then I will get a value for the correlation coefficient.

Personally I don’t like this way of doing things because I find that, despite it being catchy to say/remember, the grammar doesn’t work out so nicely when you use it. But again, personal preference. That’s for you and your team to decide what works for you!

That’s it. Just two things that you should always include in a ticket - in my opinion. If you know them already, it might be helpful to add in any dependencies or blockers to the ticket. Jira, to give an example, has the ability to track these things - you can link issues and track the relationship e.g. blocked by or dependent on etc.

What happens to my ‘ticket’?

The intricacies are dependent on your team ways of working. But, in general terms processes are similar, even if assigned tasks or methods are slightly different. Some tickets might have subtasks added as a way to share out the ticket between different people/help with planning how to approach a ticket.

In most agile methodologies, your product owner will prioritise the backlog of tickets that the team has written. Then you will go through and review the tickets as a team. You’ll check that each ticket is clear and meets the “definition of ready” your team has agreed i.e. has your ticket been written so your team can pick this piece of work up. There might be some wording tweaks or changes to acceptance criteria, but once the ticket is ready to be picked up the last thing to do is “size it”.

Sizing ‘Tickets’

We size tickets to help team members estimate how complex a task seems to be (which doesn’t necessarily correlate to the time the ticket will take to complete!) In some ways of working, this helps to see how much work teams can get done over set periods (i.e. you can calculate a team’s velocity over a sprint)

There are lots of different ways to size tickets, but the two common ones (both of which I’ve worked with) are: tshirt sizing and Fibonacci.

Tshirt sizing takes the standard clothing sizes of XS, S, M, L, XL etc. Individual teams will decide a) how many sizes to use and b) the criteria that makes up each size.

Fibonacci is sometimes seen as more granular sizing of tickets. The premise of this is that you follow the Fibonacci sequence, so the bigger the number represents an increase in ticket size: 1, 2, 3, 5, 8, 13, 21….etc. Teams will decide the largest number they are willing to take on - if tickets are too big they will need to be broken down.

Tickets are the building blocks that make up a team’s work, without clearly defined blocks it’s difficult to work efficiently and effectively as a team, catching gaps and avoiding duplication of work. No matter your level or role, writing clear tickets can really help your team work together.