Epopeyas vs Proyectos vs otra cosa

Acabamos de empezar a usar JIRA y lo estoy configurando ahora.

Tenemos un producto enorme y un equipo externo que desarrolla y apoya el producto.

Nuestro producto involucra muchos proyectos. El equipo de desarrollo trabajará en varios proyectos diferentes en un sprint determinado.

¿Cómo podemos configurar el flujo de trabajo para esto en JIRA?

¿Deberíamos tener todos nuestros proyectos combinados como un solo proyecto en JIRA?

¿Cómo podemos combinar historias de diferentes proyectos en un solo sprint?

¿Quizás nuestros proyectos deberían ser realmente épicos? ¿O algo mas?

UPD

Lo siento por el retraso. "Proyecto" para nosotros es una parte de nuestro gran sitio web. Por ejemplo, "Búsqueda 2.0" o "Integración con XYZ". El proyecto tiene plazos. "Proyecto" se puede hacer. No tiene alcance y equipo desde el principio.

¿Puedes darnos más detalles sobre cómo son estos "proyectos"? ¿Quiere decir proyecto en el sentido de una "actividad para lograr un objetivo" o quiere decir proyecto como en "solución de código"?
Siguiendo lo preguntado por rb, ¿se espera que los proyectos estén en constante evolución o no estarán relacionados entre sí?
lo siento por el retraso. ver actualización

Respuestas (2)

Si desea que varios 'proyectos' estén en el mismo Sprint de Scrum-board, puede lograrlo al tener un tablero con el filtro JQL configurado para leer de múltiples proyectos JIRA (es decir, 'project = MultiTestOne OR project = MultiTestTwo ORDER BY Rango ASC'). Los tableros y los proyectos se configuran 1 a 1 de forma predeterminada cuando crea un proyecto, pero no hay nada que le impida modificar el JQL más adelante.

En cuanto a Epics: sin más información sobre qué quiere decir exactamente con 'proyecto', no puedo dar una opinión sobre si tendrían sentido o no a través de Epics. Sin embargo, si funciona y todos en su equipo están de acuerdo, entonces no veo por qué no. En el fondo, todas las epopeyas en JIRA son simplemente una forma de agrupar problemas.

Sin más información, no puedo decidir por usted cuál de las dos (o quizás una tercera) opciones es la mejor para su situación. Debe hablar con el equipo para ver qué tiene más sentido.

Como nota al margen, usted dijo que

El equipo de desarrollo trabajará en varios proyectos diferentes en un sprint determinado.

¿Cuál es la razón para esto? ¿Están los proyectos muy relacionados? ¿Son tan pequeños que hacer un solo proyecto por sprint es inviable? Si el equipo de desarrollo está trabajando en una multitud de tareas no relacionadas durante un sprint, es posible que desee considerar un enfoque diferente a Scrum, como Kanban.

¿Por qué el equipo de desarrollo trabaja con muchos proyectos? Porque son grandes y externos para nosotros. Preparamos historias de diferentes proyectos para nuestro gran equipo de desarrollo. Tal vez no sea el enfoque más efectivo. Pero es así.

Use JQL para mostrar proyectos en un solo tablero, luego puede planificar sprints con problemas de múltiples proyectos,

pero como el equipo/los roles son los mismos (supongo que parece que los proyectos son ramas de un producto grande), use el mismo flujo de trabajo para todos los proyectos (no es esencial pero es más fácil informar)

Además, sus proyectos no necesitan ser solo épicos en este escenario, y si los proyectos más pequeños se convierten en productos grandes, la molestia será suficiente para suicidarse.

también echa un vistazo https://answers.atlassian.com/questions/64932/combining-multiple-projects-into-1-sprint

Mantenga la calma y JQL.