What is the procedure when moving from Simplified to Jira Workflow

[Richard olsson]

Hi,

We're using Jira On demand, JIRA v6.2-OD-03.

I’m preparing a merge from todays simplified workflow to a specific Jira workflow.
We’re using both Scrum and Kanban boards in several different teams. And we’re using Story points.

I’ve seen some info here, https://confluence.atlassian.com/display/JIRA061/Configuring+Workflow

But still a little bit worried about the process. Will everything go smooth or what manually job

is needed afterwards when the new Jira workflow is activated?

I’ve listed some issues that worry me, that I would like to get clarified.
Please, let me know if I’m missing some important issues that I need to be prepared for…

· Simplified has the checkbox to automatically set the Resolution=Done.
What about this with Jira Workflow? Don’t want to define a strict post method because sometimes
would the status be changed to something else than default Done/Fixed. And don’t want a “Resolution Window”
to be opened per default because if Resolution doesn’t want to be set at all it will still de set to something default and
issue will be considered to be finished (strike through) in the board.
So, it seems at it want be as flexible as with the Simplified “Done” resolution checkbox, or what am I missing?

· Will everything in Jira be updated when it comes to the converting of old statuses to new? Such as Jira issues statuses,
existing saved searches, Agile statuses placed in the columns in existing Simplified scrum and Kanban boards?

· Today we have three different Agile statuses for “Ready for Test”. Can they be easily converted during the Workflow merge?
Or is it better to merge them into one single status prior to Workflow merge?

· How is the existing boards and ongoing sprints affected? What do we have to do after merge so team can keep going?

· Guess it will be a problem for us. But if it would be possible what’s the difference if all open sprints are closed before Workflow merge?

· Agile status converting. We have a lot (too much) of Agile statuses today. But if we want to keep a (Agile defined) status
when converting to Jira (workflow) status – Can this be handled in the merge process? Or do we need to specify a
transient status first, and later rename this status to the one we wish to use?

· Moving existing status Closed to a new status called Released. Is that a problem during the status merge process?

· Will old closed sprints be affected somehow?

· Velocity – story points statistics affected somehow?

· Any specific backup routines to consider prior to Workflow swap?

· BTW, the link above - is that the best guide to get going wih Workflow creating?

Anything else that should be condidered?

[Peter Van de Voorde]

Hi Richard,

You'll need to add the new statusses to the corresponding columns on your scrum boards, otherwise it will not work. This will not be done automatically.

This also applies for any filters that you are currently using, you'll have to manually update these filters. (Replace the old statusses with the new ones).

Changing a workflow will not impact your sprints because sprints simply contain a group of issues and don't have anything to do with workflows.

The shared fields message should not be an issue for you, but just to make sure test it first and backup your data before changing the workflow.

Best regards,

Peter

[Richard olsson]

Hi Peter,

Thanks a lot for the response. Sure, test is a very good idea. :-)

So, existing boards and open active sprints will be updated accoring to the status mapping I'll do?
The statuses that resides in the columns today will just be replaced by the new?

And wha tabout this: "beside that, all shared fields will be copied, non-shared ones will be lost".
I'm just changing workflow, keeping the same project. Is this something I need to address?

Thanks

[Peter Van de Voorde]

Hi Richard,

First off : changing workflows can look like a daunting task especially if you have a lot of statusses that need to be migrated, but it's really not that complicated and very well handled by JIRA.

Some tips :

• clearly map each current state in your workflow on a new state in the new workflow (you can do this on a piece of paper for example) so you don't make mistakes during the transition (you can map several old states onto 1 new state if you want)
• make sure that your new workflow contains all the transistions you need for your scrum boards (so that all transitions you are currently doing will still be possible)
• do a backup of your data using the export tool, just to make sure nothing gets lost, if the migration goes wrong you can just revert the workflow of your project and import the issues from the backup.
• try it first on a demo project (create one just for this purpose and populate it with some fake issues)

Good luck

Best regards,

Peter

[Richard olsson]

I found this: "Once you apply the new workflow you'll be asked to tell Jira how to move the issues. You will be asked to choose for each status in the old workflow status a new status in the new workflow, than all the issues will be moved to the new workflow to each new status. beside that, all shared fields will be copied, non-shared ones will be lost."

So, if I don't want anything to change about the fields in existing issues I need to make sure that fields exist in the new Workflow? But how is that - that's not the properties in the Workflow editor..??