Estimation of the "unknown"
What to do with tickets that are ready, but take a long time to checkout?
For some time now I noticed this problem, but we didn't find a solution to it that actually worked. So this is why I come to this forum and ask other people if they have maybe ideas.
So the problem:
The tickets are mostly related to defects or check log files. When a defect or error occur, or we need to check log files we can't know how much log files we will need to check into or how deep we need to go. So the problem could be very small, but finding out is something we can't know. Even if a problem looks very similar, the root-cause could be completely different.
We tried to take this into account when planning the next sprint, and keep some time "free" for defects and bugs. We started with a very positive mindset on it, but after a while we got demotivated because the velocity was to much jumping and the sprint didn't feel like a real sprint.
We tried kanban, and this was a better approach for the team, only we want to work in iterations of 2 weeks. But the issue still stays the same, the defects and bugs or log tickets are very difficult to plan.
So did you encounter this problem, and how are your teams handle this? It could be related to all tickets.
Do you get enough tickets every Sprint for the differences to average out? If so, you might have a reasonably consistent throughput of ticketed work which you could use for planning purposes.
I'm also wondering why your team is accountable for fixing defects. It doesn't sound like they have been doing the development work, since they lack contextual understanding. Is there another team whose Developers are failing to observe a robust Definition of Done here, and to be accountable for quality?
What to do with tickets that are ready, but take a long time to checkout?
Are these actually "ready" if you don't understand the scope of the work? Would you consider a feature request or enhancement to be "ready" if you don't understand the work? It sounds like you are not doing enough refinement on defects to break them down into work that can be accomplished during a single Sprint.
This is a problem that is common when people try to treat work requests differently. The Scrum Guide says nothing about defects, stories, feature requests, etc. It says
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
The work to fix a defect is "needed to improve the product" just as the work to implement an enhancement or new feature. So why do you treat them differently? Quit classifying things based upon how it was discovered, reported, added to the Product Backlog. Treat them all the same. Go through the same level of discovery, refinement for all of the items. Order them in the Product Backlog based upon the value that is provided by satisfying the item. Not all defects need to be fixed right away. In some cases, defects might not need to be fixed at all.
Instead of "tickets", I'd talk about Product Backlog Items, which represent a unit of work that can be taken on by the Scrum Team to improve the product.
If someone reports a defect, then it's normal for there to be some investigation to understand that defect. This is not that different than when you are implementing a new feature and need to spend time thinking through everything from who will use that feature and how they will interact with it to the technical changes that need to happen.
Product Backlog Refinement is the process by which a Product Backlog Item is understood by the team and, if necessary, broken down into smaller items. It's also how the team goes about doing things like adding details, identifying any dependencies, ordering the work, and perhaps estimating the work (if the team estimates work).
Time each Sprint is usually set aside for refinement activities. Since it's typically hard to predict how long refinement will take, it's usually discussed in time and this time is removed from the team's capacity to do other work. If you consistently set aside a fixed length of time for refinement in each Sprint, you may have better results.
I wouldn't necessarily be too concerned with varying velocity between Sprints. I'd be more concerned with the team's ability to craft a Sprint Goal, selected refined and ready Product Backlog Items to support that Sprint Goal, and make sure that their Sprint Goal is achievable within the Sprint on a consistent basis. Regularly and consistently establishing and achieving the Sprint Goal is far more valuable than consistent velocity.
My thought is that the Product Owner should prioritise the backlog items. Defects, bugs, enhancements, features, are all just backlog items. If the product owner is always prioritising new features, and deprioritising bag fixes, then they will end up with a product full of bugs. Maybe they need to understand this better, or maybe that is OK with them for now, and they want to leave the fixes for later. Maybe they just don't understand what logs are, and why they are important?
I just thought, maybe this is something to raise in the next Sprint Retrospective and see what the team want to do.