Dealing with distant future work items

Question

If a Story in the backlog is something you’d like to work on one day, but that day is definitely not in the next 12 months — does it make sense to leave that story open and sitting in the backlog, or just close it?

100 items is roughly the amount I can keep in my head at any one point. If someone asks about a ticket in casual conversation ("Hey why haven't you completed [insert favorite feature] yet?"), I should be able to vaguely remember if we have that story on the backlog or not. If I can't it's a sign that the backlog is unmanageable.

A story in a backlog which is 100,000 stories long might as well not exist at all since you'll never be able to remember it or find it again. This mental limitation causes me to limit backlog work to only things we're planning to work on in the next three to six months or so. There should be less than 100 items on the backlog in total. Ideally less than 50.

Sounds great, but what do I do with the hundreds of tickets which can't fit on the backlog?

The Freezer

The freezer is the place where work which isn't in the backlog lives. Tickets which end up here usually have some value (aka. are generally good ideas) but aren't on our short-term plan. They may or may not be pulled out of the freezer and moved to the backlog at a later date, depending on our long-term goals.

Freezer items are frozen rather than closed because they're useful for pointing to when they get reported a number of times. They're also good for refreshing your memory when it comes time to do the work item (if ever).

Items which sit in the freezer for a very long time (one year plus) are highly likely to be closed due to staleness. Any information contained in the ticket is likely to be obsolete and would only cause confusion if acted on.

I find I have to be pretty ruthless in terms of closing tickets instead of freezing them. When a customer comes to me with a feature idea they really like but is not likely to ever happen, it's tempting to put it in the freezer as a peace offering. Ultimately this just sets the wrong expectations and is worse for everyone in the long run. It's better to be decisive, explain politely to the customer why their favorite feature won't be implemented and close the ticket.

The fact that there are two places where a ticket can end up implies a decision point. Who decides whether an incoming ticket goes to the Backlog or the Freezer and how do they make that decision? To handle this, we have the Triage Queue.

The Triage Queue

Typically, we create new tickets at a rate which exceeds the rate at which we close them. If they all go into the backlog then it quickly becomes unmanageable. If they all go to the Freezer then we might ignore work which is actually urgent. So what can we do?

We use a triage system. Incoming tickets are added to a triage queue instead of the backlog. Once a week, the dev manager and one or two of the senior engineers will run through the Triage queue for 30 minutes and take an action for each one.

The action taken is usually one of the following options:

1. Close it with a comment explaining why. This happens when the work asked for doesn't make sense. The comment helps educate the reporter and prevents them feeling like we just arbitrarily closed their ticket.
2. Move it to the backlog. This usually happens when the work has some of the attributes required above or if it's a production bug (in this case it might even come into the active sprint or be dealt with by the on-call person immediately).
3. Ask the reporter for more details.
4. Move it to the freezer.

So far we find this system works pretty well for our team. Right now we have 39 items in the Triage Queue, 183 items in the freezer and 70 items in the backlog. The freezer could definitely do with some pruning right now but it's not bothering anyone at its current size. 30 mins of triaging a week has our Triage Queue size steady or declining.