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,
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.
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.
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 :)
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot