Workflow design advise

[Cui Wei Lee]

We are encountering a challenge in designing our development workflow, and I’d like to provide some background on the requirements. We have three product lines. The primary product line's development may involve tickets that affect multiple releases across various hardware models. However, the release and development timelines for these different hardware models may not align, sometimes resulting in months of separation.

Compounding this issue, two departments are employing different project management approaches: Agile and Waterfall. The primary product uses a Waterfall/V-model approach, and it’s important to note that fixes can sometimes be located in different folders or repositories due to legacy issues. Given this context, what workflows would you recommend for scenarios where the same requirement applies to multiple hardware models, particularly when source code commits are in different repositories and release dates differ? The development team has expressed a desire to avoid creating multiple tickets for the same requirement that applies to different fix versions, considering the challenges mentioned. I am also exploring opportunities to automate the workflow based on these conditions.


In contrast, the other two product lines are using an Agile approach and do not face the same issues when a single requirement needs to be applied to different versions. Looking for the community expert advise in JIRA to address our issue in workflows to handle these 2 extreme cases.

[Keith Jones]

My first question is - are you running these different product lines in separate Jira projects? (That typically gives you the greatest flexibility in different workflow/automation scenarios)

Also, does the development team not want multiple tickets for the same requirements, or is it just that they don't want to have to create them? (you can clone tickets through automation).

[Cui Wei Lee]

Hi Keith, yes. It is running in separate JIRA projects.  The respective team requested to automate rather they have to clone manually.

[Aaron Morris]

In my experience, the best way to handle this is with four (4) Jira projects:

• Ticketing/Requests project (x1): This is a centralized project where you manage incoming business and user requests. (Tickets, enhancement requests, requirements, whatever terminology your company uses.)
• Product Development Backlog (x3): One backlog project for each product (or product line, etc.).

Then, link each ticket to the necessary number of backlog items based on its impact. If a ticket impacts only one product, it will only link to one backlog item in a development project. If a ticket impacts three products, it should be linked to three backlog items across three development projects.

Of course, the details of each workflow will vary. The key is that each request should be tracked as a single ticket, but each team should have control over planning and tracking the ticket's implementation in their product.

[Cui Wei Lee]

Hi Aaron,

Thanks for your suggestion. I have a couple of questions:

1. Should a ticket that is tagged or linked to multiple versions remain open until all products are rolled out, or can we close it once a specific version is completed?

2. Should each version applied to each piece of hardware be documented in a separate ticket? 

3. Link - this is referred to linked via "Link Issue" or "Epic - Stories/Feature"?

Noting same requirement might have varying committed repositories? 

[Aaron Morris]

@Cui Wei Lee - You have a lot of flexibility in how you implement the details, but here's some more general advice:

Should a ticket that is tagged or linked to multiple versions remain open until all products are rolled out, or can we close it once a specific version is completed?

Yes, generally, that's a good practice. What is most important is clearly defining "closed ticket." If a closed ticket means the request/requirement is implemented, you should wait until it is implemented in all impacted products before closing it.

Should each version applied to each piece of hardware be documented in a separate ticket? 

I'm sorry, but I'm not sure I understand this question clearly. Are you talking about a scenario where a single product has multiple pieces of hardware that may need to be updated?

If so, the answer depends on how you manage the development of the different pieces of hardware. If each piece of hardware has its own team, you'll (likely) want separate tickets. If it's a single team, it depends on how they want/need to manage things.

Link - this is referred to linked via "Link Issue" or "Epic - Stories/Feature"?

You can use either strategy, but the Link Issue feature will be more flexible and usually more maintainable. The reason is that the Epic/Story relationship implies a certain amount of sizing information, and in practice, you will need to handle requests of various sizes.

For example, if you have a small(ish) request, making the original request an epic and the linked backlog items stories will work. But if you have a large(ish) request, that request should probably be "epic-sized" in each product backlog rather than story-sized. So, you'll probably want the flexibility of "Linked Issues".

Noting same requirement might have varying committed repositories? 

Yes, this is common. You can link as many repositories to a single story/change as you need.