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; } } }

Worflow for long issues

Hanna Rybina

Hello!

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

Accepted answers

Dave Mathijs

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.

All comments

Dave Mathijs

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.

Hanna Rybina

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

Hanna Rybina

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

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.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

agile

workflow

development