Scrum: ¿Qué sucede si el propietario del producto tiene tareas?

Acabo de comenzar a trabajar con un equipo que ha recogido algunos aspectos de Scrum (timeboxing de dos semanas) pero no otros (el equipo actualmente no está de acuerdo con todas las estimaciones o con la cantidad de puntos en un sprint, pero cambiaré esto pronto.) El propietario del producto también es un recurso técnico (científico) con algunos antecedentes de desarrollo.

¿Es apropiado tener las tareas del propietario del producto (que en su mayoría implican investigación) mezcladas con las tareas del equipo (algunas de las cuales son investigación y desarrollo).

Los expertos en Scrum son muy firmes al afirmar que el propietario del producto y el Scrum Master deben ser dos personas diferentes. Sin embargo, no existe una regla que excluya al Equipo de Desarrollo. Nota en la Guía Scrum :

Tamaño del equipo de desarrollo

El tamaño óptimo del equipo de desarrollo es lo suficientemente pequeño como para ser ágil y lo suficientemente grande como para completar un trabajo significativo. Menos de tres miembros del Equipo de Desarrollo disminuyen la interacción y resultan en ganancias de productividad más pequeñas. Los equipos de desarrollo más pequeños pueden encontrar limitaciones de habilidad durante el Sprint, lo que hace que el equipo de desarrollo no pueda entregar un incremento potencialmente liberable. Tener más de nueve miembros requiere demasiada coordinación. Los grandes equipos de desarrollo generan demasiada complejidad para que un proceso empírico lo gestione. Las funciones de Propietario del producto y Scrum Master no se incluyen en este recuento a menos que también estén ejecutando el trabajo de la Pila de Sprint.

El corolario de esa última línea sería que, si el Propietario del producto está ejecutando el trabajo del Backlog de Sprint, se lo cuenta como miembro del Equipo de desarrollo.

Dicho esto, haz lo que funcione para que tu trabajo esté bien hecho.

El propietario del producto es responsable de maximizar el valor del producto y el retorno de la inversión. Puede parecer simple, pero generalmente es un papel a tiempo completo y muy exigente, posiblemente el más difícil en Scrum. Implica una gran cantidad de trabajo estratégico de alto nivel, así como tareas de nivel inferior, desde analizar oportunidades de mercado y consultar a las partes interesadas y usuarios del producto para tomar las decisiones correctas, hasta mantener la hoja de ruta del producto y la cartera de pedidos siempre pulida, asistir a la planificación y revisar actividades, ponerse a disposición del equipo para responder sus preguntas, etc.

Si el PO está a cargo de otras tareas además de eso, solo las vería como marginales en la mayoría de los casos. Entonces, mi respuesta sería sí, crear tareas para el PO si realmente tiene que hacerlo y si contribuyen directamente a producir el incremento de software del sprint, pero no veo que eso suceda a menudo en su proyecto Scrum promedio.

Scrum es ante todo acerca de la comunicación y el trabajo relevante y oportuno. Cualquier cosa para promover ese objetivo está bien si eso es lo que permite que su equipo sea el más productivo.

Sin embargo, es difícil hacerlo bien. Ahora estoy en esa posición y me resulta difícil dedicar una cantidad adecuada de tiempo como propietario del producto sin dejar tiempo para el desarrollo. Sin embargo, el acuerdo funciona bien para este equipo específico en este momento. Revisaremos la decisión para mí de hacer doble trabajo cuando nuestro rendimiento disminuya, pero hasta entonces seguiremos trabajando de esta manera.

Entonces, inténtalo. Haga retrospectivas para que pueda mejorar continuamente su proceso. No permita que apegarse previamente a alguna metodología interfiera con la productividad de su equipo.