Al migrar masivo a otro proyecto desaparece iniciar sprint en el nuevo proyecto

[Anahí Luque]

Hola! Estoy tratando de migrar incidencias a un nuevo proyecto y tengo varios inconvenientes, si me pueden ayudar por favor:
 1. Al trasladar las incidencias que están en un sprint creado del proyecto antiguo al nuevo, automáticamente en el nuevo proyecto desaparece el botón "iniciar sprint". La primer imagen muestra el proyecto nuevo antes que se migre una incidencia de otro proyecto y la segunda muestra como desaparece el boton azul de "iniciar sprint" y se agrega el sprint con el nombre del antiguo proyecto, en este caso de llama "EM Sprint 1 CCUM" y tampoco me permite editar el nombre del sprint. Leí por allí que puede ser por el nombre del sprint que está duplicado en ambos proyectos pero No sé qué debo hacer específicamente. A alguien le ha pasado lo mismo?


2. También tengo dudas sobre como migrar las incidencias abiertas sin que pierdan sus épicas, ya que en la primera migración lo primero que hice fue migrar cada épica y llevó todas las incidencias asociadas a cada épica pero también me trasladó las incidencias cerradas y al final el proyecto nuevo me quedó igual que el antiguo. Entiendo que al migrar las incidencias individuales masivamente las traslada al nuevo proyecto pero no asocia su épica.

Agradezco mucho su ayuda sobre como solucionar esto, ya que van 2 proeyctos migrados y me pasa lo mismo. (Ya leí varios artículos de Jira y no encuentro la solución).

Saludos!

Anahí

[Trudy Claspill · Accepted solution]

Hola @Anahí Luque 

Bienvenido a la comunidad Atlassian.

Me ocuparé primero del punto 1.

Dijiste que los problemas que migraste ya están en un sprint antes de transferirlos del proyecto anterior al nuevo.

Cuando transfieres esos problemas al nuevo proyecto, eso no cambia ningún Sprint al que hayan sido o estén asignados actualmente. Los problemas siguen relacionados con esos sprints.

Se mostrará un sprint en un tablero si se cumple alguna de estas condiciones:

1. El sprint se creó en ese tablero.

2. El filtro del tablero abarca temas que están en el sprint.

Cuando movió los problemas del proyecto anterior al nuevo proyecto, el problema quedó dentro del alcance del filtro del tablero del nuevo proyecto. Por lo tanto, cualquier sprint al que se asignaron esos problemas comenzó a cumplir la condición n.° 2 anterior y comenzó a mostrarse en el tablero del nuevo proyecto.

Este no es otro sprint con el mismo nombre. Es el mismo sprint, mostrado en dos tableros. Cualquier cambio que realice en ese sprint (es decir, nombre del sprint, fechas del sprint, inicio/finalización del sprint) se reflejará en ambos tableros porque es el mismo sprint.

En respuesta al hecho de que falta el botón Iniciar Sprint para esos sprints, tengo esta pregunta para ti. ¿En el tablero del proyecto anterior tenías el botón Iniciar Sprint? Para ver el botón Iniciar Sprint debes tener el permiso Administrar Sprints en todos los proyectos para los cuales hay problemas en ese sprint. Si hay problemas en ese sprint que se encuentran en proyectos donde no tienes el permiso Administrar Sprint, entonces no verás el botón Iniciar Sprint para ese sprint específico, sin importar en qué tablero se muestre.

Si no desea que los problemas transferidos permanezcan en el sprint del proyecto anterior, en el tablero del nuevo proyecto simplemente elimine esos problemas de ese sprint y colóquelos en otro sprint o en el trabajo pendiente. Si no tiene permiso para hacerlo (falta de permisos en el proyecto anterior), necesitará la ayuda de alguien que tenga los permisos necesarios.

Una vez que todos los problemas del nuevo proyecto se eliminen de ese sprint, ese sprint (del tablero del proyecto anterior) ya no se mostrará en el tablero del nuevo proyecto.

Ahora intentaré abordar el punto 2.

Primero necesito hacerte una pregunta. ¿El proyecto antiguo y el nuevo son proyectos administrados por el equipo o proyectos administrados por la empresa?

Con los proyectos administrados por equipos, se requiere que Epic y sus problemas secundarios estén en el mismo proyecto. Si traslada problemas secundarios de un proyecto administrado por equipo o a un proyecto administrado por equipo, perderán su relación con su Epic principal. Tendrás que agregarlos manualmente a un Epic en el proyecto de destino.

Los proyectos administrados por la empresa no requieren que Epic y sus problemas secundarios estén en el mismo proyecto. Si está trasladando incidencias de un proyecto administrado por la empresa a un proyecto administrado por la empresa, permanecerán conectados a su Epic principal en el proyecto original. No verá Epic en el tablero del nuevo proyecto porque el filtro para el tablero del nuevo proyecto solo recibe problemas del nuevo proyecto.

Entiendo que no desea trasladar todos los incidentes cerrados del proyecto anterior al nuevo. ¿Cuál es su objetivo al vincular los problemas que está transfiriendo a Epics? ¿Quieres que permanezcan vinculados a su Epic principal original o quieres vincularlos a un Epic en el nuevo proyecto? Si quieres que estén vinculados a una Epic en el nuevo proyecto, ¿quieres que esa Epic sea una copia de la Epic original?

---

Hello @Anahí Luque 

Welcome to the Atlassian community.

I will address #1 first.

You said that the issues you migrated are already in a sprint before you transfer them from the old project to the new project.

When you transfer those issues to the new project, that does not change any Sprints to which they have been or are currently assigned. The issues remain associated to those sprints.

A sprint will display in a board if either of these conditions is met:

1. The sprint was created in that board.

2. The board filter encompasses issues that are in the sprint.

When you moved the issues from the old project to the new project, the issue then fell within the scope of the new project's board filter. Therefore, any sprint to which those issues were assigned started meeting condition #2 above, and started getting displayed in the the new project's board.

This is not another sprint with the same name. It is the same sprint, displayed in two boards. Any changes you make to that sprint (i.e. sprint name, sprint dates, starting/completing the sprint) would be reflected in both boards because it is the same sprint.

Addressing the fact that the Start Sprint button is missing for those sprint, I have this question for you. In the old project's board did you have the Start Sprint button? In order to see the Start Sprint button you must have the Manage Sprints permission in all the projects for which there are issues in that sprint. If there are issues in that sprint that are in projects where you don't have the Manage Sprint permission, then you will not see the Start Sprint button for that specific sprint no matter which board it is displayed in.

If you don't want the transferred issues to remain in the old project's sprint, then in the new project's board simply remove those issues from that sprint and drop them in another sprint or the backlog. If you don't have permission to do that (lack permissions in the old project) you will need help from somebody who does have the necessary permissions.

Once all issues in the new project are removed from that sprint, then that sprint (from the old project's board) will no longer display in the new project's board.

Now I will try to address #2.

First I need to ask you a question. Are the old project and the new project Team Managed projects or a Company Managed projects? 

With Team Managed projects the Epic and its child issues are required to be in the same project. If you are moving child issues from a Team Managed project or to a Team Managed project, they will lose their relationship to their parent Epic. You will have to manually add them to an Epic in the destination project.

Company Managed projects the Epic and its child issues are not required to be in the same project. If you are moving issues from a Company Managed project to a Company Managed project, then they will remain connected to their parent Epic in the original project. You won't see that Epic in the new project's board because the filter for the new project's board is getting issues only from the new project.

I understand that you don't want to bring all the closed incidents from the old project to the new project. What is your goal for linking the issues you are transferring to Epics? Do you want them to remain linked to their original parent Epic, or do you want to link them to an Epic in the new project? If you want them linked to an Epic in the the new project, do you want that epic to be a copy of the original Epic?

When mass migrating to another project, starting sprint in the new project disappears

Hello! I am trying to migrate issues to a new project and I have several problems, if you can help me please:

1. When transferring the issues that are in a created sprint from the old project to the new one, the "start sprint" button automatically disappears in the new project. The first image shows the new project before an issue from another project is migrated and the second shows how the blue "start sprint" button disappears and the sprint is added with the name of the old project, in this case it is called "EM Sprint 1 CCUM" and it also doesn't allow me to edit the sprint name. I read somewhere that it may be because of the name of the sprint that is duplicated in both projects but I don't know what I should do specifically. Someone has been the same?

2. I also have doubts about how to migrate the open incidents without losing their epics, since in the first migration the first thing I did was migrate each epic and it took all the incidents associated with each epic but it also moved the closed incidents and at the end The new project turned out the same as the old one. I understand that when migrating individual incidents en masse, it transfers them to the new project but does not associate their epic.

I really appreciate your help on how to solve this, since there are 2 migrated projects and the same thing happens to me. (I've already read several Jira articles and can't find the solution).

Greetings!

Anahi

[Anahí Luque]

Hola @Trudy Claspill muchas gracias por tu respuesta.

Respecto al punto 1 me quedó muy claro y pude resolver. Gracias.

En cuanto al punto 2:

- Si ambos proyectos son administrados por la empresa.

- El objetivo de vincular las incidencias a las Epicas es no perder el orden establecido, ya que el nuevo proyecto es una continuación del anterior pero con algunos cambios.

- Quiero que las incidencias de asocien a una nueva épica del proyecto nuevo pero sin perder el nombre del proyecto original, por lo tanto que sea una copia de la épica original pero que no traiga las incidencias cerradas o finalizadas del proyecto original.

Desde ya agradezco su gentil explicación.

Saludos

Anahí

[Trudy Claspill]

Hola @Anahí Luque 

Con la funcionalidad nativa no puedes obtener lo que deseas para el punto 2 con un solo uso de la función Clonar.

Como descubrió, si copia Epic del proyecto anterior al nuevo proyecto y elige copiar los problemas secundarios, obtendrá todos los problemas secundarios. Luego, deberá eliminar manualmente los problemas cerrados copiados del nuevo proyecto.

Si copias una edición secundaria, no tienes la opción de decirle a Jira que también copie su edición principal, Epic.

Podría considerar crear una regla de automatización que copie Epic y solo sus problemas secundarios abiertos de un proyecto a otro.

Esta publicación analiza cómo utilizar la automatización para clonar un Epic y sus problemas secundarios.

https://community.atlassian.com/t5/Jira-Software-questions/Clone-EPIC-amp-Stories-to-New-Epic-and-link-New-Stories-via/qaq-p/2257134

Un cambio que debería realizar es agregar una condición dentro de la rama para clonar los problemas secundarios solo si su estado no era cerrado.

Además, la publicación habla sobre cómo configurar el campo Epic Link en los problemas secundarios recién creados. Con los cambios que se realizaron recientemente para reemplazar el campo Enlace épico con el campo Principal, deberá configurar el campo Principal.

---

Hello @Anahí Luque 

With native functionality you cannot get what you want for #2 in a single use of the Clone feature.

As you found if you copy the Epic from the old project to the new project and elect to copy the child issues, then you get all of the child issues. You would need to then manual delete the copied closed issues from the new project.

If you copy a child issue, you do not have the option to tell Jira to copy its parent Epic also.

You could consider creating an Automation rule that would copy the Epic and only its open child issues from one project to another.

This post discusses how to use automation to clone an Epic and its child issues.

https://community.atlassian.com/t5/Jira-Software-questions/Clone-EPIC-amp-Stories-to-New-Epic-and-link-New-Stories-via/qaq-p/2257134

One change you would need to make is to add a Condition inside the Branch to clone the child issues only if its status was not closed.

Also the post talks about setting the Epic Link field in the newly created child issues. With the changes happening recently to replace the Epic Link field with the Parent field, you would need to instead set the Parent field.

Hello @Trudy Claspill, thank you very much for your response.

Regarding point 1, it was very clear to me and I was able to resolve it. Thank you.

Regarding point 2:

- If both projects are managed by the company.

- The objective of linking the incidents to the Epics is not to lose the established order, since the new project is a continuation of the previous one but with some changes.

- I want the incidents to be associated with a new epic of the new project but without losing the name of the original project, therefore it should be a copy of the original epic but not bring the closed or finalized incidents of the original project.

I thank you in advance for your kind explanation.

Greetings

Anahi

[Anahí Luque]

Entendido, muchas gracias por tu respuesta @Trudy Claspill 

[Trudy Claspill]

De nada, @Anahí Luque