Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Worflow for long issues


If the issue in the project contains work of several people: 

1) developer

2) QA engineer

And this issue by workflow can pass from Development (by developer) and then to Test (by QA) and THEN can also come back from Test to Redevelopment (If test is failed).

All these movements from one assignee to the other (or/and from one status o the other) can lead to issues' lateness in the end of the sprint (sprint = 1 week)

So in the end all the sub-processes that are included in the issue can be longer than 1 week (or maximum 1 week - i.e. development). 

How I can manage this kind of long issues? I need to separate them into sub-tasks (in this case i cannot put them into sprint and i also loose comments/info in 1 unique issue that moves from ddevelopment to test and so on).

Or I need to make this kind of issues epics? 

Or it's okay thay they move from one sprint to the other? Or i need to make a sprint longer? 

I have a little bit of confusion :)

1 answer

1 accepted

2 votes
Answer accepted
Dave Mathijs Community Leader Dec 09, 2022

Hi @Hanna Rybina welcome to the Atlassian Community!

In your case, I would make the sprint 2-3 weeks.

For another use case of one of our clients, I've created separate issue types for this 'long' flow.

One Epic is split into:

  • Issue type Business Analysis
  • Issue type Functional Analysis
  • Issue type Development
  • Issue type QA/INT/UA testing
  • Issue type ...
  • ...

Each of the issue types will have their proper 'short' workflow, resulting in issues less re-assignments and shorter throughput.

Post functions and automation rules keep the flow between the different issues types ongoing.

This is just one example of the possibilities.

Thank you for the answer! 

But which kind of post-functions and automations are you talking about exactly?

You mean that for instance:

- when my Business analysis issue is closed, i need to make automatic trigger that will open a Development issue? 

What can you suggest? 

As for me, my variant above is not so user-friendly

And also according to your idea: how can we manage issues for redevelopment? For example If QA testing process has been finished with fail and an issue needs some addings (work of a developer in the next sprint)

I need to create one more developments issue or better reopen the previous one?  

Dave Mathijs Community Leader Dec 09, 2022

The post functions (depending on third party apps you might have) can trigger the next issue in line. This indeed can also be achieved with automation rules of course.

A re-run of the development issue and/or test issues is preferable in my opinion.

It all depends on HOW your developers and testers would like to work.

As I said earlier, you might already solve a lot of constraints you currently encounter by changing the sprint duration from 1 week to 2-3 weeks.

Thank you very much! You've helped me a lot :)

Like Dave Mathijs likes this

Suggest an answer

Log in or Sign up to answer
Site Admin

Atlassian Community Events