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.