How do you track work on bugs with no solution?

[Alice]

Re-posting this as a question since I'm not sure if it's a question or more of a discussion point. Any help with this is appreciated.

We use JIRA bug tracking for a software system that's owned by another software company. We perform configuration and customization enhancements, but base functionality of the software is owned by the software company. Sometimes our end users report bugs for which neither we nor the software company have a solution. In these cases, we'll sometimes work on the bugs for a little while intermittently during our sprint work (which isn't ideal, but it happens) or even assign the bugs to the sprint during which we're working on them, with the hopes that we'll be able to find a solution to the issue and add the solution into the next release. It ends up messing with sprint scope, because we don't know if we'll be able to find a solution in the given time-frame and sometimes have to move the bug out of the sprint. These are the kinds of issues where people often randomly find a solution while working on something else and discover there was an issue with a piece of code or something similar.

Do other software developers have this issue? If so, how do you track the work you do on figuring out these seemingly unsolvable issues? Do you track the work within an existing sprint and continue moving the issue to the next sprint if you don't solve it? Or do you let it sit in the backlog and keep revisiting it until someone miraculously finds a solution?

[Jack Brickey]

Hi Alice, indeed I think this is more of a discussion as different folks will approach this differently.

Here’s an idea you might want to consider. If you get into these really difficult bug scenarios then consider pulling the effort outside of the sprint. Grab one of your top troubleshooting software developers and challenge them with finding a solution. Give them some freedom to work on it either full-time or in the background. Keeping it outside of the sprint will not pollute your sprint and allow your developer to not feel the pressure of getting it done in your sprint timeframe. Having said that, I generally like to keep the bug work in the sprint if the team addressing the bugs is the same as those doing new feature work. So I probably would have the bug in a sprint initially and if it seems to be one of those challenging scenarios then pull it aside.