Hardware Development & JIRA -- How to optimize the workflow / fix version field to take advantage of burndown charts

Question

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)

1. We expect that for (1) -- all tickets are validated and moved to "Closed"

2. 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.

The problems:

1. 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])

2. 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

Potential Solution:

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.

Answer 1

Use two projects instead of one:

• Design Project

  • This is the existing project

• Sample Project

  • This is the new project

    • When issues are closed in the existing project, issues are created here

In my ideal world, I can look at a filter of tickets (Fix Version = 2 and Status = !Closed) and that would show 0 results

Use a separate board to generate this report:

When you create a Board, it will ask if you want to create a board based off of a pre-existing project or projects, select this option, and select all of the projects that you want to have represented in the Board.

Create a filter containing the different projects you wish to be included in your board and share it if desired. Then go into the configuration menu of your existing board. Select the filter you've just created as the main filter utilized by the board.

In summary, create two projects and as many boards as necessary. Each board will encapsulate the filters required for the report which will facilitate the decision making process.

References

• JIRA Agile FAQ: How do I get a board to point to multiple projects

• Apache Cordova - ASF JIRA

Answer 2

I think you are using versions in a way which is not what Jira meant to be. In software development, you have a piece of software which evolves through different versions, each version consists in a group of changes (issues), all of this is a project. To allign with this, you should use one project for each new hardware you have, so you can follow in which version each one of them is at any moment. You'll find out this approach makes easier to use burn down charts and any query in general