As part of our steps in delivering product features, an important part of the delivery process is documenting the feature/card. Currently we have a documentation status in our process, but would like to separate these statuses/steps from the software engineering and test steps so we can have separate metrics.
Is there a way that an issue ( user story/bug ) can complete one workflow process and automatically be "promoted" or started in another workflow so the issue can move through another set of steps/status in a separate workflow and have different metrics.
Thank you for that suggestion.
It looks like a nice add-on.
I guess I am still trying to understand how changing the type works when we want to be able to look back at the sprint or release to know what was completed.
Are there ways to add "categories" ( Todo, Done ) to the sequence so that the sprint and release processes continue to work, yet the issue can continue to move through the other steps to complete the issue cycle?
Thank you again for your help
Paul, it shouldn't affect the sprint or release unless you remove the issue from the sprint. Changing the issuetype would just be changing the issue from a task to bug. All the fields and data can remain.
What you could consider doing is having an extended workflow where there is a continuation after the first completion step. For example: new -> in progress -> done -> qa -> approved -> complete.
In this scenario, you have two end states (done and complete). I have done this for some of my teams before and it seems to work pretty good especially if different people are responsible for different steps of the workflow.
Another thing we have done when working with teams that have different sprints, is creating a second issue for the second team and linking it to the first. For example, a bug may be in the developer sprint and they work it to completion. When done, they create a qa issue and link it back.
hopefully some of that is helpful.
It is all helpful. I have used some other tools that allowed a process to continue "post" completion and allow us to look at the work in a different way and maintain the metrics.
We are currently using a similar approach with multiple statuses with a "done" issue category. I will continue to look at this method and create multiple boards for the development team, the documentation team and then a consolidated sprint/release board showing all the steps to complete.
We are still trying to figure out how to close the development sprint work without have dependencies on the documentation and use the release as the final collection of work that is ready for market delivery. Would really like to do this without replicating the issues.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs