How to handle a LOT of tickets for a LOT of different "products"

[GHacker]

I am looking for advice. Here is what I am doing now, but it is a mess.

We have 30 Virtual Images. Call them i01 through i30.
We are constantly getting tickets to update images.

So, i01 v1 would get a change and become i01 v2. Then we would update i01 v2 to i01 v3...

…at the same time we might also be updating other images. They might be at i05 v6 going to v7 and i12 v3 going to v4 (for example). Typically we are updating several images per week.

We are constantly getting tickets in from users requesting changes on various images.

I have a board with all the tickets with Component “Image Change Request”

Since we always have a bunch of tickets in the backlog, I triage the new tickets with a “generic” release version such as:

i01

i02

i03

…

i29

i30

The tickets stay in the backlog with this generic version so we can easily see what tickets are for image 01 and image 02, etc.

Then we get a “critical” ticket that has to go into an image, such as i05, then we move that ticket to the sprint and look down in the backlog for all the generic release “i05” tickets to see what we can also throw into the image before rolling to the next version. Maybe we then move up 3 more "i05" tickets to the sprint.

Once we decide to actually work a ticket, we change the release version from a generic version to a specific version such as changing from “i05” to “i05 v4” and move the ticket up to the sprint.

This works ok, but I have 30 "generic" release versions: i01 through i30 and they are not small names like “i”. They are long 20 to 40 character names.  So, when you look at the 30 generic names along with maybe 10 actively open releases, there are 40 release version names to look at and it is dizzying.

I could make a board/print for each image, but then I have 30 boards and 10 active sprints. Again, it is just messy.

Any thoughts?

Example real release versions (generic):

AAA_CAMEL_BUILD_WIN7_32

AAA_CAMEL_DEVELOPMENT_WIN7_32

AAA_GOAT_BUILD_WIN7_32

AAA_GOAT_DEVELOPMENT_WIN7_32

AAA_MOUSE_DEVELOPMENT_WIN10_64

AAA_MOUSE_DEVELOPMENT_WIN7_64

BBB_DEER_BUILD_WIN10_64

BBB_DEER_DEVELOPMENT_WIN10_64

BBB_MONKEY_BUILD_WIN7_32

BBB_MONKEY_DEVELOPMENT_WIN7_32

BBB_MONKEY_DEVELOPMENT_WIN7_64

CCC_CAMEL_BUILD_WIN7_32

CCC_CAMEL_DEVELOPMENT_WIN7_32

CCC_CAT_BUILD_WIN7_64

CCC_CAT_DEVELOPMENT_WIN7_64

CCC_DEER_BUILD_WIN10_64

CCC_DEER_DEVELOPMENT_WIN10_64

CCC_DOG_BUILD_WIN7_64

CCC_DOG_DEVELOPMENT_WIN7_64

CCC_SHEEP_BUILD_WIN7_32

CCC_SHEEP_DEVELOPMENT_WIN7_32

DDD_FISH_BUILD_WIN10_64

DDD_FISH_DEVELOPMENT_WIN10_64

DDD_MONKEY_BUILD_WIN7_64

DDD_MONKEY_DEVELOPMENT_WIN7_64

EEE_FISH_BUILD_WIN7_64

EEE_FISH_DEVELOPMENT_WIN10_64

EEE_FISH_DEVELOPMENT_WIN7_64

FFF_CAMEL_BUILD_WIN7_32

FFF_CAMEL_DEVELOPMENT_WIN7_32

Then add in the specific version we are working on in the sprint (Note the version number tacked on the end of the generic image name.  “v0_01” = v1.01

AAA_MOUSE_DEVELOPMENT_WIN7_64_v0_01

CCC_SHEEP_BUILD_WIN7_32_v0_05

CCC_SHEEP_DEVELOPMENT_WIN7_32_v0_03

BBB_MONKEY_DEVELOPMENT_WIN7_64_v0_08

DDD_FISH_DEVELOPMENT_WIN10_64_v1_02

FFF_CAMEL_DEVELOPMENT_WIN7_32_v0_04

So, when looking at the release version, the two above release versions are combined to be:

AAA_CAMEL_BUILD_WIN7_32

AAA_CAMEL_DEVELOPMENT_WIN7_32

AAA_GOAT_BUILD_WIN7_32

AAA_GOAT_DEVELOPMENT_WIN7_32

AAA_MOUSE_DEVELOPMENT_WIN10_64

AAA_MOUSE_DEVELOPMENT_WIN7_64

AAA_MOUSE_DEVELOPMENT_WIN7_64_v0_01

BBB_DEER_BUILD_WIN10_64

BBB_DEER_DEVELOPMENT_WIN10_64

BBB_MONKEY_BUILD_WIN7_32

BBB_MONKEY_DEVELOPMENT_WIN7_32

BBB_MONKEY_DEVELOPMENT_WIN7_64

BBB_MONKEY_DEVELOPMENT_WIN7_64_v0_08

CCC_CAMEL_BUILD_WIN7_32

CCC_CAMEL_DEVELOPMENT_WIN7_32

CCC_CAT_BUILD_WIN7_64

CCC_CAT_DEVELOPMENT_WIN7_64

CCC_DEER_BUILD_WIN10_64

CCC_DEER_DEVELOPMENT_WIN10_64

CCC_DOG_BUILD_WIN7_64

CCC_DOG_DEVELOPMENT_WIN7_64

CCC_SHEEP_BUILD_WIN7_32

CCC_SHEEP_BUILD_WIN7_32_v0_05

CCC_SHEEP_DEVELOPMENT_WIN7_32

CCC_SHEEP_DEVELOPMENT_WIN7_32_v0_03

DDD_FISH_BUILD_WIN10_64

DDD_FISH_DEVELOPMENT_WIN10_64

DDD_FISH_DEVELOPMENT_WIN10_64_v1_02

DDD_MONKEY_BUILD_WIN7_64

DDD_MONKEY_DEVELOPMENT_WIN7_64

EEE_FISH_BUILD_WIN7_64

EEE_FISH_DEVELOPMENT_WIN10_64

EEE_FISH_DEVELOPMENT_WIN7_64

FFF_CAMEL_BUILD_WIN7_32

FFF_CAMEL_DEVELOPMENT_WIN7_32

FFF_CAMEL_DEVELOPMENT_WIN7_32_v0_04

[Prem Chudzinski _extensi_]

Hi ,

your setup and workflow is pretty "advanced" :)

Try our plugin

https://marketplace.atlassian.com/plugins/io.extensi.jira.plugin.agileboardfilter/server/overview

You will be able to filter out versions in the backlog version panel to hide all versions that don't have any issues assigned or the other way around. That may help you to move tasks between versions.

Instead of generic versions why don't you consider labels or a custom field?

Afterwards the version list would be small and it will be easier to filter out the backlog (using the Agile Board Filter) by a label and move it to a specific version.

Regarding confusing names

You can create planning filters - have a look at the "Private Quick Filters" screen https://extensi.io/agile-board-filter and name them differently. That way you'll be able to filter your releases and linked issues without any issues.

Cheers

Przemyslaw