I run into this all the time.
Receiving a list of 40 different tiny tickets that could be “just a quick fix” or cause much larger, cascading problems after implementation can be infuriating, especially if the majority of your focus is elsewhere.
I am not sure if there is a right solution, but after reading Shape Up I wonder if this ticket came up from a bug in the code, or a bug in our process.
Most of them for me are a bug in our process.
“I would have written to a log that the user closed the app if I understood why that was important the first time around”. Sometimes what is obvious to someone doing the design/shaping of the work isn’t obvious to the person implementing it. The edges are blurry until the person doing the implementation understands the job to be done.
I do my best to ask my client (or whoever is handing down the ticket) about 100 times “Why are we doing this? When has it been a problem last?” until my confidence and understanding of the work becomes clear enough that I feel comfortable doing implementation. Some clients find it refreshing, others annoying. When I get lazy, I pay the price when a million of these little tickets pour in.
Sometimes it is just a bug in the code. “I forgot to implement the focus-order correctly, probably should have been caught during testing, but I should fix that for accessibility issues” (or whatever).
These little things I do my best to prioritize these and batch them up (probably during the cool down period).
If it causes more problems to solve than it is worth, I may just leave it as a bug in the code. If it isn’t losing customer data, preventing people from accomplishing their job to be done, or making something completely inaccessible, it may just have to stay broken for a while until such a time comes to fix it properly.
Again, I am no expert, but I found that spending more time in the discovery/design side of things keeps the list of small tiny tickets more manageable, and provides plenty of time during your cycle to properly test things.