¿La comunidad Agile tiene procesos recomendados para un único equipo Scrum que gestiona las tareas que provienen de varios trabajos pendientes?
Mi plan actual es que se lleve a cabo la siguiente acción (pero estoy feliz de que la comunidad SE revise el proceso)
No puedo imaginar una forma más justa de reunir funciones iguales con casos comerciales fluctuantes de Sprint a Sprint.
Afortunadamente, todos los requisitos se basan en el mismo entorno de desarrollo centrado en la funcionalidad de SAP, por lo que el equipo de desarrollo (y las pruebas) no varían mucho entre las historias/funciones de los usuarios. Lo que pide Marketing está dentro de la esfera de lo que pide Servicio al Cliente; solo un usuario final diferente.
Todo lo que cambia es qué parte interesada obtiene el valor al final del Sprint, qué departamento obtiene el activo agregado a su balance final y quién recibe la factura del Equipo Scrum.
Feliz de aceptar cualquier pensamiento, libro blanco u orientación de la Comunidad.
Además, realmente he tratado de formular esta pregunta para SE, así que escriba una línea si el formato es útil, incluidas las explicaciones, etc.
¿La comunidad Agile tiene procesos recomendados para un único equipo Scrum que gestiona las tareas que provienen de varios trabajos pendientes?
Claro: no lo hagas.
Múltiples equipos pueden trabajar desde un solo Product Backlog, pero nunca al revés. Un solo equipo que trabaja a partir de múltiples Product Backlogs no es Scrum, no es ágil y es muy poco probable que funcione a cualquier escala.
Primero, determine si tiene un solo proyecto unificado o muchos proyectos separados (aunque posiblemente relacionados). Una vez que determine ese dato crítico, puede rediseñar sus procesos de gestión de proyectos en consecuencia.
Dentro del marco de Scrum, siempre hay una relación uno a uno entre:
Si bien hay formas de escalar Scrum en varios equipos y proyectos, como Scrum-of-Scrums o SAFe , su implementación de Scrum se ha descarrilado si está canalizando más de un Product Backlog directamente a un solo Equipo de desarrollo de Scrum.
La situación que está describiendo, donde hay muchas partes interesadas con diferentes agendas, en realidad es bastante común. Suponiendo que tiene un solo proyecto con un objetivo razonablemente unificado, la forma correcta de lidiar con esto dentro del marco de Scrum es tratar cada uno de estos intereses comerciales como partes interesadas y permitir que el propietario del producto administre una cartera de productos unificada de cualquier manera. parece más apropiado para equilibrar los intereses de las partes interesadas.
El propietario del producto puede usar técnicas como la puntuación del tema o la ponderación relativa para ayudar a las partes interesadas a equilibrar sus intereses, pero el propietario del producto singular en última instancia, crea un Backlog del producto único y secuenciado para que trabaje el equipo Scrum. Esto es absolutamente fundamental para el marco y no es negociable si quiere llamar a lo que está haciendo "Scrum".
Otro concepto fundamental de Scrum, y de los marcos ágiles en general, es que la multitarea es mala porque crea una sobrecarga de cambio de tareas y reduce el rendimiento y la eficacia. Un proyecto se define generalmente como:
una empresa individual o colaborativa que está cuidadosamente planificada y diseñada para lograr un objetivo particular.
Si todas las unidades de negocio no están trabajando hacia el mismo objetivo unificado, entonces no tiene un proyecto unificado; tienes varios proyectos . Múltiples proyectos requieren que secuencia sus proyectos a través de un equipo, o distribuya los proyectos entre múltiples equipos. De cualquier manera, debe organizar sus equipos de proyecto y el marco de gestión de proyectos para alinearse con la realidad de que no tiene un proyecto único y cohesivo; fingiendo que lo haces no pondrás lápiz labial en el cerdo .
En una de mis asignaciones anteriores, como Scrum Master, trabajé con un grupo de Product Managers similar al que usted describe. Además, los gerentes de productos tenían muchas otras prioridades, por lo que fue difícil obtener aclaraciones de requisitos o pruebas de aceptación del cliente (CAT) de ellos de manera oportuna. Cada uno de los cuatro Gerentes de Producto presionó para obtener más tiempo del equipo de desarrollo para sus características, similar a lo que usted describe. Sin embargo, mi situación era mejor que la tuya en dos aspectos:
El cabildeo ocurrió en una reunión de preparación de hojas de ruta o trabajo pendiente sin la presencia del equipo de desarrollo completo.
Afortunadamente, uno de los Gerentes de Producto era senior y podía tomar la decisión final cuando se volvía polémico.
Después de hacer eso durante más de un año, nos volvimos más inteligentes y designamos un Product Owner dedicado a tiempo completo (para 3 equipos Scrum). El propietario del producto trabajó fuera de línea con los diferentes propietarios del producto y transmitió las prioridades unificadas resultantes a los equipos de desarrollo. El propietario del producto también se sentó en la reunión de planificación de Sprint y estuvo disponible para el equipo de desarrollo para aclarar los requisitos en la mesa y realizar pruebas CAT con poca antelación. La mejora en la productividad y la moral del equipo fue espectacular.
Basado en esta experiencia, en mi opinión, su solución considerada no funcionará. Como mínimo, considere implementar 1 y 2 anteriores. Mejor aún, nombre un Product Owner dedicado a tiempo completo.
aventura2099