Hacker News Reader

Comment by cjcenizal | Hacker News Reader

> People start to chastise those who open JIRA bug tickets as "too many!"

I know what you mean. I've seen teams treat a backlog's growth as being a root problem. They responded by closing issues with the explanation "We probably won't ever get around to this" or by creating scripts that will auto-close any issue after a set period of time.

I'm still on the fence about whether this is productive or not. I guess it depends on the team's context. A growing backlog indicates strong demand for features and/or many defects being found in the product, at a rate which outpaces the team's ability to respond. My instinct is to make changes to any part of that system but the backlog itself, since it is real data with real value. My strong opinion weakly held is if you manipulate this data, you're just putting blinders on.

View on HN

The best argument I’ve heard in favor of culling like this is that if it wasn’t worth doing two years ago, and wasn’t worth doing one year ago either, it’s probably never going to be worth doing. In this view, legitimately good ideas that never quite make the cut are dangerous because they eternally distract & waste time for no value.

As a methodical person it’s hard to digest, but I’m starting to find it holds water.

Except that it might have always been worth doing, but the team is underfunded. ie, the ROI on doing it was positive/high

Yep. I've found that the ticket or tech debt isn't important until it becomes on fire and must be fixed ASAP. It doesn't matter that the possibility for the bug to happen has existed for 2 years, the organization doesn't find the investment worth it until it's burning down the house.

which seems like such a blatant failure of leadership. If I had 1000 ways that I could invest $1000 at a 20% return this year and like 5% recurring[1], why not hire 2-3 engineers get them done and keep the extra $200k plus have a better future?

The most compelling argument was opportunity cost against features (eg the time spent on feature work would return 100% per year or whatever seems enticing) ... That seemed to me to only suggest we should do _both_ (get more capital in the market if required)

[1]: some amount of recurring makes sense so long as things like customer retention, brand value, maintenance costs are factored in

I feel like the dynamic still holds true. If the team was underfunded two years ago, and still underfunded one year ago, they will probably still be underfunded with regard to tackling the problem now. The ROI argument seems similarly dubious since it might hold true for things with high upfront costs but otherwise if the perceived ROI had been high then a team short on resources would have already prioritized it.

That only works if the programmers buy the managers' narrative -- and that's not a given. Usually it's the opposite.

Managers very often only optimize for them to look better in front of their superiors, to the detriment of the underlying team's efficiency, and very often to the detriment of the product itself.

People pulling the blanket towards them is not a new thing.

One of my teams is going through this currently. Our Scrum Master keeps on wanting to erase our backlog as she thinks it makes us look bad to management.

Reply on news.ycombinator.com