From time to time we face difficult problems which are hard to reproduce. Creating a planning for solving such an issue is (nearly) undoable.
What we do at the moment is break these up in analyses/reproduction and solving the problem. As long as know nothing we plan a number of hours to investigate and book off these hours by effort and not by result.
This does not feel like a true agile sprint. Do you guys have any suggestion how to improve this situation?
I think ITIL has a nice take on the subject by distinguishing between problems and incidents. You can not fix an incident ... somebody has to investigate and figure out the problem behind that incident. That way to look at things has a certain overhead, but it can help in many different ways as the scope of a project increases.
That is pretty much what you are doing, I guess. I have not read the linked question that gnat posted, but I think that an incident does not belong in a Sprint. It needs to reach problem status first - which means the cause has to be known and a solution for the problem must have been proposed.
In some cases the Impediment Backlog might be the right place, though ... if impediments are to blame (not a lack of clarity) which the product owner (? I think ?) can tackle (or have somebody tackle).
In agile, there is the term Spike where you spend time (usually fixed in my experience) investigating an issue in order to be able to make an estimate for a story. In your case, if you are doing Scrum and trying to get estimates for the tasks on a bug, you might need to run a Spike (as you are doing) so that you can estimate the work remaining.
These Spikes can also be used for prioritization. If the Spike discovers that the issue is unlikely to occur, or only occurs in very specific hardware scenarios, or only on the second Tuesday of a month ending in 'Y', you may decide to lower the priority in the backlog for this bug.
That being said, for bugs I wouldn't usually do this. I tend to just grab 'x' bugs into the sprint and have the team work on them in priority order alongside the normal group of stories that are being worked on. If during that work we discover information that might affect priority, then we act on it then.
