How to Reduce Backlog Tickets: 78 Closed, 101 Opened in One Day

Park screen of Ppijuk Land. 30 guests walk around between the carousel, a snack shop, and rides, and a balance in the 990,000 won range shows at the top

On October 31 I closed 78 tickets in one day, but 101 new ones opened, and the remaining count went from 335 yesterday to 334. A good share of the new tickets were opened on their own by the crash collector and automatic checks. The number you close is not the amount of work you did, so to see whether the backlog is shrinking you have to count how many opened and why.

October 31: 221 Merges and the Backlog Did Not Move

Here is the numbers line from that day's diary. 294 sessions, 221 merges, 101 new tickets, 78 resolved, 334 tickets remaining. The day before, 335 remained.

It was a busy day. I packed the Ppijuk Land launch prep into one day: the design doc, the store name, the Android app shell, bringing the missing cells in the element ledger down to 0 from 36, and translations into ten languages. And still the backlog did not shrink by even one.

Ppijuk Land park screen showing the carousel, a snack shop, and rides, with 30 guests in the park and a five-star top rating — This is Ppijuk Land, the game I packed that launch prep around. The screen is a pre-release test build.

What Someone Told Me That Morning

That morning someone pointed out that "you tend to create tickets and put things off." And 101 new tickets went up that same day. The numbers answered the remark pretty well.

I closed 78, so I did do work. But with 101 opened, the count should have grown by 23, and instead the remaining number dropped by one. The diary has no line that explains the gap. I could not confirm where or how many were closed on the side.

Many of the New Tickets Were Not Opened by Me

The diary names two causes. One is the crash collector, which opens a ticket automatically for each error. The other is the automatic checks, which open tickets labeled with a rule name. These two made up a big share of the new tickets.

When a person writes "I need to do this" in a ticket, closing it finishes one piece of work. A ticket opened by a machine opens again if the same error comes back. However fast you close, if tickets open faster, the backlog stays where it was.

Ppijuk Land making minigame screen. A dotted line for piping dough is drawn on a cutting board, and the boss character says to head out once half the capacity is filled — A test build screen from that day. Every new screen adds one more place to check.

Where I Was Wrong: I Counted Closed Tickets as Work Done

At the end of the day, "I closed this many today" is the first thing you see. 78 reads like a pretty big day.

But the size of the backlog is set not by how many you closed but by the gap between closed and newly opened. If you do not count the opened ones too, the harder you work, the more you believe the work is shrinking.

Looking only at closed: 78, a decent day.
Adding opened: 101, the backlog grew.
Adding why they opened: tickets I wrote and tickets a machine opened are mixed together, so one number cannot count them.

The Fix Was One Line of Numbers

What I did that day was simple. I added the new ticket count, the resolved count, and the remaining count to the numbers line at the top of the diary (#4504). From the next day on, I could no longer feel safe looking only at the closed count.

It is not a big fix. Cutting down the tickets that machines open was not something I got to that day. I could only choose where to cut once the numbers were visible, so I made them visible first.

Ppijuk Land daily settlement screen. A table shows 14,758 won earned today, 65 won spent, and a net profit of 14,693 won — The in-game settlement subtracts what you spent from what you earned and shows the net profit on one line. The to-do list needed one line like that too.

FAQ

Why does my backlog not shrink even though I keep closing tickets?

Because new ones open at about the same rate you close. If you write the closed, newly opened, and remaining counts on one line each day, you can see right away whether it is shrinking or growing.

How do I handle auto generated tickets?

First count what share of the new tickets were opened automatically. If it is a kind where the same error opens again and again, a rule that merges that kind into one ticket will shrink the backlog more than spending time closing each one.

What should I measure a day's progress by?

The change in the remaining count is better than the closed count. But on a day with many new tickets the remaining count can stay flat too, so I recommend putting the newly opened count next to it.