Ask HN: Slippery Slope of Deprioritization? | Hacker News Reader

Ask HN: Slippery Slope of Deprioritization?

4 pointsironmagma6 comments

I've noticed a pattern in some teams where a ticket will first have a reaction of "this seems lower priority" and then the next meeting it will be "should we maybe push this to next sprint?" and then next sprint it will be "I am not really sure we should do this at all." and it gets moved to the backlog.

This happens with such regularity that I feel like it needs a name at least. When it starts to happen, I can predict where the ticket will end up with some amount of accuracy. But has anyone found a way to engage with this phenomenon?

The reason I feel it's an issue is that all good work has some amount of uncertainty to it. By that virtue you can deprioritize almost anything this way.

View on HN

Yes this practice is endemic at big tech. You have salaried employees who are only incentivized to do the bare minimum with minimal resources. It's why I think big tech can never out innovate any small company. Smaller companies are fighting for their survival and these excuses as "this seems low priority" will be easily over-ruled if leadership thinks otherwise.

I'm not sure this is a problem - if there is no business nor technical driver making it have a higher priority, then sitting in the backlog is probably exactly the right place for it.

If you are worried that stories that do have more importance are falling victim to this pattern, it is probably a communication or collaboration problem with the team.

It is definitely a collaboration problem; someone created the ticket with the intention of the team doing it at some point. My question is how to deal with it beyond just ignoring the problem.

Sounds like you may not have a shared understanding of why tickets are created. On the teams I've worked, a ticket is simply an idea - maybe we'll do it, maybe we won't. We toss the ticket up to discuss it, which results in sometimes doing it, sometimes backlogging it, and sometimes just closing it because it is a duplicate of another ticket, is handled via another ticket, or is simply something that will never be done.

Yeah, I find that conception a bit silly. Ideas are ideas. If you go to the trouble of making a ticket, it means you think it’s good enough of an idea to pitch to the team. If most of the tickets are closed, that’s not okay. It means the team isn’t very good at creating tickets, or whoever is in charge isn’t allowing the team to do most of the valuable work.

During the time between sprint meetings you have the chance to gather information. If there has not been any new evidence that the ticket was important, then over time it makes sense to gradually deprioritize it

Reply on news.ycombinator.com