How to separate task completion on dev side and QA verification processes?

Hello,

I am a project manager working for a mobile app startup company, organizing our dev tasks in JIRA sprints.

I am wondering how can I separate DEV side and QA verification processes for sprints measurement purposes.

Today we have a workflow that looks something like this: new bug / task -> DEV fix (ready for QA) -> QA approved (done). 

This causes a situation in which I compile a sprint with several issues, which are counted as completed only when QA approved (naturally). I would like to change that though, so it will be possible to count issues completed by dev in each sprint (currently they are being pushed to the next sprint until completed by QA).

However, I don't want to consider the DEV fix status as done since it isn't.

Can you recommend a solution?

Thanks very much,

Noa

1 answer

This widget could not be displayed.

Create an overall issue which has a separate sub-tasks for design, coding, QA, documentation, system test, deployment or whatever your breakdown needs to be.   Each sub task can have its own issue-type/workflow. 

 In this way each group can have their own workflow and these workflows are parallelized.    Each sub-issue can be resolved and the overall issue only when resolved when all the sub-issues are resolved.

You will need to move the parent issue into the sprint and the subtasks will show up in the sprint.

https://confluence.atlassian.com/display/JIRA/Creating+a+Sub-Task#CreatingaSub-Task-workingWorkingwithsub-tasks

https://answers.atlassian.com/questions/85897

Since you are using JIRA Cloud you will probably need to create your subtasks manually or you might be able to use the REST API to create your subtasks.  I am not up to date on the bundled plugins or the Atlassian connect plugins.

 

Thank you for the quick reply Norman. However, (and if I understand Andrew's problem in the link attached it is quite similar), I want to be able to do this (complete the flow of dev fixing and QA verification) over several sprints. Meaning, I want to be able to complete the dev part in one sprint, and the QA verification in the next. I want to be able to count the dev effort as part of one sprint, and the QA's effort separately. How can I do this without having to create separate tasks / subtasks for fixing and verification? Thanks again! Noa

Using Atlassian tools you cannot do it without creating issues/tasks. If you want to do things across sprints then you need to create issues (not subtasks) for each sprint. These issues would be linked to a parent issue. dev sprint 1 dev sprint 2 qa sprint 2 dev sprint 3 qa sprint 3 test sprint 3 parent issue with links to the above issues. The parent issue would be there to relate the individual issues together and for you to accumulate the work log. Most likely you will need to write a REST API script to update the parent script

One of the guiding principles of Agile to complete the work in a sprint. So the next task should be different from the previous task, so having separate issues/tasks seems to be reasonable fit verses trying to push the same issue along meeting multiple goals representing the sprints..

I do understand the Agile principal here, however it does not seem to make sense, creating multiple tasks for the same subject - dev part and qa part. This results in a load of issues in the system, also making it clumsy to complete an issue's life cycle of new -> in dev -> ready for QA -> completed.

I believe this is one of those cases where the tool dictates the solution (not a good thing at all) and shows one of the weaknesses of JIRA.

how do I create a QA Issue - 'Sub-Task for issues discovered by QA' - in my board there is only a general sub-task

Unfortunately google brought here me as a result of my search because we suffer of the same issue.

I appreciate that the JIRA would like to enforce the agile principles however as a tool this should be a configuration option to enforce something that one think is good to follow and there are people, developers who do not need fancy manifestos we need solutions to our problems and sometimes.

I would say it is a pretty valid usecase that the development team works in sprints, the testing team works in sprints, the quality works in spints.

Once they all processed the series of issues necessary for a release the software can be released, until then the branches of code,tests,quality records can be updated one after each other and the teams have nothing to do with each other, they are distinct dimensions of the product development (e.g. a testing team can reject a bugfix and the issue can be replanned for development in another sprint).

I always wonder why people complicate tools with introducing hardcoded solutions instead of configurability and push this responsibility to the end user with a sample/default setting. It is actually less work to realize and yet all the tools are telling us how to work instead of supporting versatility :)

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted 10 hours ago in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

32 views 1 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you