Are you an engineering stakeholder? Try this out: go find a ticket you wrote, and reject it as an exercise. Maybe it’s one that’s been open for a while, or one that just doesn’t seem as important as back when you created it.
No really. Jump over to your issue tracker, I’ll wait.
It’s an interesting experience, right? There’s almost always some ticket that can simply be closed without changing the trajectory of the project all that much.
Here’s one I closed just a moment ago, following my own advice:
What’s curious about this ticket is that it was created during a brainstorming session as a Sort of Good Idea™, and then dropped into Trello without much detail. Since everyone was present when it was discussed, the ticket was slowly triaged up into an action item without ever really formalizing requirements.
There are a few things that make this a candidate for deletion:
- The ticket above was addressing an anticipated issue, not something any user had experienced
- It was, at the time, not driven by user feedback (indeed, the feature hadn’t even launched yet)
- We had no concrete implementation path, in large part because of the above
So it went into the rejected pile. We didn’t save it. We didn’t put it into a backlog. The idea wasn’t recorded.
We just threw it out.
This is pretty freeing. We’ve found that removing all this unnecessary cognitive load tends to have a non-trivial impact on engineering as a whole. Engineering attention is finite, arguably more finite than other types of attention, due to the inherently high cost of distraction. Pawing through a huge pile of tickets to find the next reasonable thing to work on (which is well-specced, matches priorities, etc…) is not exactly a super fun experience as an engineer, especially when many of these are just “product debt:” ideas born in another time, which aren’t necessarily relevant anymore.
Note that this differs from typical backlog grooming. Here, we’re looking for participation of stakeholders who have the ability to completely remove work items that were previously requested. Rejecting your own ticket as a stakeholder tends to be cleaner than ‘grooming’, which still requires the engineering team as a whole to track the issue and continually re-evaluate its priority in the overall stack of available work.
Managing tickets via backlog grooming is a net increase in overhead for the team, whereas simply removing them is a net decrease.
- Any tickets that are over a month old and haven’t been started yet
- Any tickets where 2 or more implementation questions have remained unanswered for over a week
- Any non-‘new feature’ tickets that don’t explicitly come from concrete user feedback
Sometimes the best thing a product manager or other stakeholder can do for engineering is concede that once-bright idea just doesn’t make sense to implement anymore, and simply drop it from the queue.
Have more tips for reducing engineering overhead? You can catch me on Twitter
Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.