Where I am today I often get tickets that are too vague to start on.
I think about it a bit, spend ten minutes talking to the person who wrote the ticket, turn the ticket into a good ticket, and proceed.
The effort to do that is maybe 5% of the work to complete the ticket so I can't complain.
Even though we do sprints what we are doing is really kanban where the main focus is finishing what we start and not having excess WIP. If a ticket takes a sprint and a half to finish, there is always something from the backlog to add to the sprint.
There are many ways to use a ticket system. One of the times I was happiest was when I was able to quickly break down my work into 10-20 minute subtasks and make super-accurate estimates. That was dependent on having a framework in which the tasks were predictable and also quickly punching tasks into a spreadsheet. If the work involved a lot of struggling with the runtime, build system, algorithms, database, etc. that kind of predictability is impossible.
There is always some disconnect between "what we say we do" and "what we really do" in a ticket system. Those agreements and disagreements can drive people crazy (fine-grained tasks help me focus but will drive many people up the wall) but it's also possible to reach an accommodation where work gets done without a lot of space.
(e.g. it drove me nuts to write a daily standup summary of yesterday and today in the morning with the rest of my team. in the morning I'd find it hard to remember exactly what i did yesterday and what I was planning to do last afternoon and it would slow me down getting to work. Now I write my summary when I leave with the headlines "what i did" and "what i plan to do" that recognizes that those things don't always agree. Those notes help me get started in the morning and nobody complains I am 180° out of phase.)
