I've worked in places which required every hour worked to be accounted for. This was slightly annoying, but also surprisingly informative sometimes. We usually ended up on accounting the time by the project basis, but I can imagine doing this on the ticket basis, especially if tickets are on the bigger side.
Of course with full time accounting, you want to either have some of "overhead" ones ("self-improvement", "lunch", "mandatory training", "all-hands meeting", "writing down all the tickets"), or you silently inflate logged time of real tasks to account for the overhead.
(I can also imagine some sort of dystopian organization where clueless product managers push the feature tickets, and management requires everyone to only work on the tickets. This sounds pretty nasty, but I don't think it will last for long - either the system will collapse from lack of maintenance, or people will start to pad the tickets. "Yes, it was absolutely necessary to upgrade node.js to the latest version in order to change background color of the login button. There was no other way")
Is this suggesting that all tickets should be fully scoped and planned by Product? If so, no. Devs also need to contribute to planning and should be able to write their own tickets when it’s needed. They have context that is necessary in order for planning to be done properly.
We needed a feature implemented, EMERGENCY PRONTO ERMARGERD. ~15 tickets came down from On High. Half of them were effectively lists of things required for launch, the other half were individual "we must change this page", and one was basically "implement the feature" - and we were asked to scope it.
This was for a system that none of us have had any recent (2 years) experience working in, in a language that most of us weren't familiar in, and dealing with payments. No, I'm sorry, I cannot scope this vague "make thing work" ticket that looks like foam in the sea of requirements, the one that we're actually going to be spending 90% of our time working on, that needs to be investigated and broken down into individual tickets later on.
Depending on project/work setup -- can be helpful for starting developer to get started learning system. Also can provide way those familiar with project to document/evaluate what 'new' developer(s) have learned / understands.
Tell me you’ve only worked in large orgs without telling me you’ve only worked in large orgs.
This idea is preposterous for any small organization.
Albeit tickets are useful for a variety of reasons; when it comes to crunch time, you generally can’t be bothered. Also auditors do a bad job of verifying and validating if your tickets correspond to changes so the ISO excuse only holds so much weight.
Even in large orgs, devs have so many different responsibilities, I just cannot see them be able to do their job if limited to working on tickets only.
This seems like outsourcing sweatshop kind of practice.
Of course with full time accounting, you want to either have some of "overhead" ones ("self-improvement", "lunch", "mandatory training", "all-hands meeting", "writing down all the tickets"), or you silently inflate logged time of real tasks to account for the overhead.
(I can also imagine some sort of dystopian organization where clueless product managers push the feature tickets, and management requires everyone to only work on the tickets. This sounds pretty nasty, but I don't think it will last for long - either the system will collapse from lack of maintenance, or people will start to pad the tickets. "Yes, it was absolutely necessary to upgrade node.js to the latest version in order to change background color of the login button. There was no other way")