What is the best way to segregate the efforts of dev and QA people on a particular module?

[kallepallibharat krishna]

We have a bunch of applications maintained and we get a 'change request' from the users for which a story is created in the Jira project. Based on the requirement dev and QA related tasks are created as subtask inside that story. In the end we're getting aggregated effort of dev and QA on that particular 'change request' using Tempo. 

Is there any better way to handle this 'change request' in Jira software?

[John Funk · Accepted solution]

Hi @kallepallibharat krishna  - Welcome to the Atlassian Community!

Why would you create sub-tasks for those instead of having those as separate steps in your workflow? 

[kallepallibharat krishna]

Hi @John Funk 

It is the common procedure we adapted to track the efforts of dev and QA involved on that issue.

[John Funk]

To be honest, that's not a great way to implement that. Those are steps in the flow of creating something, and not separate items, which generates more issues and overhead on hour system. Plus, it is no a very Agile thing to do. 

[kallepallibharat krishna]

@John Funk  could you please enlighten me regarding that 'more issue and  overhead on hour system' part?? also guide me how to work on this 'change request'when it is added to a sprint??

[John Funk]

It's just simple in that the more issues you have in your system, the more impact there will be eventually on performance. If you are creating sub-tasks for what are essentially just steps in a workflow, then you are adding overhead to your system. 

So you would update your workflow if those are not separate steps already in the standard software development process used by your organization. Then as the card moves through the workflow, it is assigned to the appropriate person working on it. First to the developer and then to the QA Analyst when the developer is done. This is a status change in the workflow (next column basically) instead of a separate ticket. 

[Rob]

I have a question about this. 

We have 2 separate teams (and boards). We have Development, and we have a team that forms requirements and provides UAT testing.

We have a need to measure our LOE across a specific update/enhancement. We also need to show our work, per phase, as we get to a release. 

In this case, it seems my only option is to create separate, related Work Items for each phase. This solves the issue for LOE measurements, differing assigned team members and being able to report on phases completed for multiple releases.

My issue is in determining how to tie them all back to an "umbrella" release. 

[Ste Wright · Accepted solution]

Hi @kallepallibharat krishna 

Sub-tasks are one option, I see teams use these irregularly.

I'd consider though whether...

• You could handle this using additional statuses in your Workflow - eg. In Progress and In Testing. Then the dev could hand it off to the QA?
• Whether Tests should be a separate issue type - which is how it works for some of the testing Apps?

If you are going to use sub-tasks, I'd consider using Automation to generate them each time to avoid unnecessary manual labour.

Ste

[kallepallibharat krishna]

@Ste Wright 

I have this doubt, how to run this 'change request' in a sprint? 

As we're creating 'change request' as a story, how to handle the dev and QA related stories for the sprint pertaining to that 'change request' as the 'change request' is story issue type we thought of adding the dev and qa related stories to the 'change request' as sub-tasks and assign story points accordingly. I guess this is the not right way of handling issues in Jira.

Please give me some guidance regarding this.

[Ste Wright]

Hi @kallepallibharat krishna 

Why do you need to split them into Dev and QA? Aren't those both just stages in the development process for the same change request?

The team could then size this together, and hand-off the request between the team members as required.

Ste