@Chris Hubbs This isn't a direct answer to your question, but why are you moving the issue type? In general, a process that requires you to Move issues from one type to another is an indication of a faulty process.
Having re-read your note a few times, I think that your first sentence should have be written:
We've setup workflows for Reports and Bugs that are different.
If that is correct, then what I understand is that a "Report" is some incident that may or may not require a developer to resolve. Until you have performed your root cause and know that the solution requires development, you don't want to schedule it into a Sprint. Once you do recognize it as a Bug, you move the Report to Bug and put it into the Sprint. If this is incorrect, then ignore the next paragraph and let me know where I misunderstood.
I would reconfigure your Bug process to allow all of the incidents to be Bug reports and get rid of the "Report" issue type. A Bug may not require any developer intervention. It may be resolved as "User Error" or "Feature, not Bug" or any number of other reasons that it didn't require scheduling into a Sprint. For those Bugs that are truly bugs and need developer resolution, they remain in the Backlog until the team pulls them into the appropriate Sprint. Then the team works them, just as they do today, until they are closed.
This has the advantage of a) treating all reports as potential bugs without having to worry about whether they are or not until you are ready; b) means you don't need a separate workflow; c) makes your metrics easier to follow.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.