[bluefirebrand]

I think this is not referring to customer feedback backlog, but more internally generated ideas, reported bugs that are reported against features that have been completely reworked, things like that.

I tend to agree with the article, every startup I've worked at has had a large backlog of tickets in JIRA that were completely irrelevant to the current product. That stuff could be pruned pretty easily but never is.

[telchior]

I ticket with this in mind. Often I'll write a ticket and either categorize or write it to make clear the the idea/feedback/bug needs some time to ferment and prove its value. A lot of times these never get looked at again or (particularly with minor / difficult bugs) glanced at before being trashed forever. Things just look different with the passing of time.

OTOH some of my practices at a very small team would probably be incredibly harmful in a big team, I wouldn't take his advice without considering how it's applicable.

[asyncscrum]

OP here, yes with a big team with established processes and a backlog that hundreds might be in love with, proceed with caution. And honestly, this is only to protect other people's sentimental value with the content. The lost time spent on backlogs with reviewing, reporting out, re-evaluating, migrating, reading between the lines, and other grooming, far out ways the handful of times you leverage it. This is an extension of the 'build trap' I feel, where we're convinced that we need to coddle the things that we might build.

In my experience, the things that get built that actually have impact are always recent realizations, not things that have been sitting in a backlog for a year.