We really need to groom that backlog of tickets. It’s getting out of control.

I’m sure this statement is well-meaning. After all, proposing that we get better organized is rarely met with disagreement. And sure, it seems like having a bunch of half filled in tickets is something that ought to be corrected. But having a bunch of half-complete tickets with missing information is exactly what the backlog should be, and it shouldn’t bother anyone.

But first, let’s agree in broad strokes about how work is assigned and completed.

When an engineer is working on something, it should have a ticket that corresponds to the work. The ticket should have some basic information like:

  • What are the functional requirements?
  • Who requested this?
  • When do we think it will be ready?

The workflow will end up being:

  • Meeting on Monday, ticket is assigned. The requirements get clarified during the meeting. Ticket is updated.
  • The engineer is working through it on Tuesday and has a few questions that need clarification. Updates the ticket accordingly if requirements change. If a decision is made, it is noted on the ticket.
  • Task is finished on Thursday. Code changes are merged and tagged to the ticket. The ticket is moved to “Done,” and the work is considered finished.

While this sounds obvious, the sequence is key. Requirements are only finalized at the time the ticket is assigned.

Some managers, in an attempt to “stay organized”, do things like requiring all tickets in the backlog to be fully described in detail with acceptance criteria. This, unsurprisingly, leads to engineers not wanting to write any tickets and just keeping it in their heads, only to forget later. Also equally bad is having a two-hour meeting to go over tickets in the backlog and try to get them ‘complete.’ This won’t work because the answer to most requirements on these tickets will be “don’t know.” And someone may have created a ticket for an idea that doesn’t really work anymore, or has aged out of usefulness, or isn’t deemed imporant enough to ever start working on. Some tickets languish in backlogs for years, being talked about nearly every two weeks in the backlog grooming meeting but with no action. Delete them. All of this wastes time that would be better spent on working on the currently assigned tickets.

Teams that do this most effectively settle into a few rules for tickets.

  • Make new tickets for the backlog anytime you think of something you might want to do. Fill in whatever information you have in your head. The goal is to have a stub for some work that may need to be done sometime in the future.

  • The time for getting tickets into a ready state is ‘when we plan to do them’ or as close to that time as possible. This is when you can have discussions with stakeholders to get the final requirements.

  • Tickets in the backlog can be created, updated, or deleted anytime. The backlog is better thought of as the ‘ideas’ board. Or if you want to get even more direct, “Things we are not working on now.”

Add new tickets with reckless abandon. Then delete with reckless abandon, or ignore entirely, and stick to the work you know you need to do.