SCRUM y Nexus Frameworks - 1 Equipo con múltiples proyectos

Trabajo esencialmente para 3 empresas. Se formará un equipo de desarrollo compuesto por miembros de las 3 compañías diferentes para construir 1 producto relacionado (con varias versiones). La parte compleja es que, debido a que nuestro equipo está formado por miembros de diferentes empresas, en algún momento otros miembros del equipo de desarrollo estarán realizando tareas para diferentes proyectos. Utilizamos Jira para realizar un seguimiento de los problemas en los que necesitamos trabajar. ¿Sería mejor mantener 1 producto y sprint backlog para el 1 equipo de desarrollo y mantener todos los elementos para todos los proyectos en esos backlogs? ¿Significaría esto también que solo debería haber 1 propietario del producto para todos los proyectos que estarían interactuando con varias partes interesadas, gerentes de productos, alta gerencia, etc. de diferentes proyectos?

El punto que estoy tratando de plantear en esta configuración (1 backlog de producto y 1 PO) es que si un desarrollador ya está comprometido con un sprint del proyecto, entonces nadie debería poder asignar nuevas tareas para este desarrollador, excepto el propietario del producto. . Solo el propietario del producto debe interactuar con el asignador de las nuevas tareas (provenientes de partes interesadas o clientes de diferentes proyectos) para mantener el compromiso del sprint, ¿no?

¿Podría explicar qué tan grande es el equipo del producto y qué tan dependientes son las versiones entre sí? Siempre puedes tener un backlog pero, en función de otros factores, decides si es un tablero/sprint/PO o varios.
El equipo de desarrollo está formado por solo 3 a 5 miembros y un miembro del equipo puede realizar varios proyectos o ningún proyecto durante varios días en un ciclo de 2 semanas. La mayoría de nosotros trabajamos en la misma oficina con la excepción de 1 miembro del equipo que trabaja a tiempo parcial y trabaja de forma remota. Las versiones del producto principal dependerán en gran medida entre sí, mientras que otros proyectos son para productos diferentes. Me imagino que si tenemos diferentes trabajos pendientes para cada producto de 1 equipo de desarrollo, entonces el Sprint del producto principal contendría sprints parciales para algunos miembros y sería más difícil garantizar sus compromisos para el principal.

Respuestas (1)

En mi opinión, la idea de una cartera de productos/PO tiene sentido con ese tamaño de equipo. Además, para tratar de minimizar el efecto de nuevas tareas de otros proyectos, sería la idea de dedicar un par de días fijos para trabajo externo y tener eso en cuenta en el sprint. Por ejemplo, el sprint es de 10 días de trabajo, pero cuando realiza la planificación, solo tiene en cuenta ocho días porque los otros dos días serán de trabajo externo y puede agregar un ticket para una tarea no planificada para ver cómo el trabajo externo afecta el sprint para ser capaz de comunicarlo a las partes interesadas si es necesario.