nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Suggestions please - Transitioning of tickets

Vanessa Becker_vh489c

Hi Admins!

I need your assistance in terms of guidance / suggestions.

So we have a Scrum team that consists off our devs, testers, SM etc.

When our testers tests the tickets and it Passes - it is moved to our Done column / to the done status.

But now.. what sometimes happens if a ticket does not need to be tested (for example the client asked for information which the developer then attaches to the ticket), the developer then closes it and forgets to inform the client of the reports that is attached / or they forget to advise the client that the reports are ready.

I don't really want to add rules on the transition side of things as our testers needs to be able to transition a ticket to done.

Any suggestions on how to manage the transitioning process so that a developer cannot transition a ticket to done ?

Thanks

Comments

Markus Siegwart

Hi Vanessa,

You can set a 'User Is In Group' condition that restricts the transition to the group of testers.

Kalin U

Hi, Vanessa.

Markus is right. You'll need transition conditions:

1. Decide if "testers" and "devs" are in user groups or in project roles.

2. Add a condition to the transitions to and from "Done" (in case they made a mistake, so that they can "undo" the transition).

Step 1.png

Depending on your definition of roles (project roles or user groups), you select the condition: Step 2.png

3. Apply one, all or any conditions for the transition.

Step 3.png

Keep in mind that if the workflow is shared, you need to have the same project roles or user groups in the other projects too.

Matthias Gaiser _K15t_

Hi @Vanessa Becker ,

as an alternative to the solutions @Kalin U and @Markus Siegwart mentioned, you could also tackle that problem from another angle:

For all tickets which don't need to be tested, you can introduce another issue type - and let this issue type follow another workflow. In that workflow you don't need the extra step with the testers and your developers don't need to think about it. If a ticket of this type is moved to done, your clients then know the attached reports/information is final.

Not sure if this really fits to your use case, but I thought I'll mention it to you and you can decide what to do with it 😀.

Cheers,
Matthias.

Vaishali Patil

We have a similar situation but as our customers are not users in our Jira, we have a field to denote this is a customer ticket. We use the API to post update on our customer portal

Joseph Chung Yin

@Vanessa Becker -

Using the transition condition is correct. When you locked down to prevent developer from moving the issues to "Done", then he/she (the developers) will not see the transition button when viewing the issues + he/she will not be able to drag/drop the issues to the DONE column.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

Medhat Ahmed

Hi Vanessa

you can add condition on the workflow so the developer will not be able transition issues to done please let me know if that resolves your query or not.

Best Regards,

Medhat

Curt Holley

In terms of technical Jira solutions, I believe you have a good range of options suggested already. But I'd like to add into the mix, the notion that this is fundamentally I people problem.

As you mention, Developers closing tickets and forgetting to actually complete the task....in other words "Meet definition of done".

So, I would be tackling the human behavior as much if not more than providing a technical complexity that may not resolve the issue...which is people not completing the task and providing customer satisfaction.

Johnny FromCanada

As with most things, the tools are not what will save you. What does the Team think is the root issue? What does the Team suggest would be a potential change to experiment with?

Welcome!

It looks like you're new here. Sign in or register to get started.