Can an issue be part of 2 different workflows?

[Paul McCauley]

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

[Joe Pitt]

Not unless you move it to a different type of issue. Have you looked at subtasks to track those steps and then close the parent when they are closed?

[Paul McCauley]

Joe,

Thank for the reply.

If the issue changes type, how does that effect the reporting tools and statistics?

Paul

[Peter DeWitt]

@Paul McCauley, to add to what Joe said, this add-on by Bob Swift can change the issue type automatically for you thus making it seem seamless to the end user.

Update of transition for Jira

https://bobswift.atlassian.net/wiki/display/CW

pd

[Paul McCauley]

Peter,

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

[Peter DeWitt]

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.

pd

[Paul McCauley]

Peter,

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.

Thank you