You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
If the issue in the project contains work of several people:
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 :)
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:
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?
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.