[smackay]

The problem here is not the tool but the process that comes with it. From the managers in the bigger company's perspective integrating your team into the larger structure makes a lot of sense. What they are probably missing though is the impact that doing things their way is probably going to negatively impact your team.

Opposing the tool is not really going to get you anywhere. From the outside it will just look like you are resisting the integration with the bigger company and all the baggage that is going to come with not being "a team player".

For entertainment purposes only: fight fire with fire. Make a case for improving developer productivity by implementing a ticket quality score and use it as a metric. After all, the better the ticket the faster you can start work on the problem, rather than having to go chase down all the issues and requirements. Management will be rather annoyed at you flagging all their one sentence tickets as inadequate. As I said this is for entertainment purposes only. It's fun to make a point, but push quickly becomes shove.

[artwr]

I am always reminded of this story around throughput metrics for Software Engineering: https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

Your suggestion is delightful, and in a former company, one of our PMs, at a time when we were overwhelmed with requests, tried to tame the tied by requiring requesters fill out this simple template along the folloing lines (but I am paraphrasing): - What is the impact on you/your team from this feature/bug not being addressed? - What is the priority of this in comparison to other asks you have from the team? - What is the impact to the business?

Even though the team did not like the bureaucratic approach, the number of requests went down dramatically.