We're using JIRA for hardware development and have run into some issues related to the separation between the development and validation cycle. Let me explain:
We have an issue type "Development Task" that has a workflow like this:
Assigned > In Progress > Implemented > Build > Verified > Closed
Typically we create a bunch of tickets (we assign these as fix version 1), implement the changes in a design, send the design off to the manufacturer and get samples back. Once we get the samples back we have two types of work that need to be done:
(1) All of the tickets that we implemented prior to getting hardware -- do some sort of verification/validation (it is part of the workflow)
(2) Add new development tickets to implement more features (we assign these as fix version 2)
In order for us to build our next iteration (fix version 2)
We expect that for (1) -- all tickets are validated and moved to "Closed"
We expect that for (2) -- all tickets are in "Implemented"
In my ideal world, I can look at a filter of tickets (Fix Version = 2 and Status = !Closed) and that would show 0 results, which would be my Decision Gate that allows us to proceed to building the next round of hardware.
If I want to see the exhaustive list of tickets that need to be finished up, I need to make a filter that captures: (Fix Version = 1 and Status = !Closed) OR (Fix Version = 2 and Status = ![Closed, Verified, Build, Implemented])
If I want to use the burndown chart feature, I can move all of those tickets into a sprint and set an end date, however there doesn't seem to be a right state to assign "Resolution" such that it always represents the correct tickets
Remove the validation tail from the "Development Task" and instead create new tickets. That way, the only filter you need is (Fix Version = 2 and Status = !Closed). This also fixes the burndown chart issue because resolution is assigned at the end.
Are there any other alternatives? Are we looking at this all wrong? I'd rather not have the engineers create new validation tickets if we don't have to, they have expressed that it is nice to have the full development background in the ticket when they go to do verification/validation.