Asignar Historias a Personas suena muy mal, es muy Lado Oscuro

Yo sé, me quiero creer, que para los que lleváis tiempo en esto de la Agilidad, hacéis algo con Scrum, etc., esto es una obviedad (quiero creer), pero lo que pasa es que constantemente entra en el mundo Ágil gente nueva, yo entro en contacto con muchos de los nuevos y me toca volver a explicar cosas súper básicas como que… ordenar un Prodcut Backlog pensando en la persona concreta a la que se le asignará una historia es… muy Lado Oscuro.

Que un Product Owner asigne historias suena muy mal

Eso lo primero, un Product Owner es responsable del Product Backlog, si lo ordena en función de a quién le caerá la cada historia cuando comience el Sprint… se está metiendo en una responsabilidad que no le toca y está mermando la auto-organización.

Es el equipo el que debe decidir la mejor distribución, reparto, trabajo colaborativo para terminar los objetivos del Sprint. 

Al principio, de los principios, esto puede ser complicado, pero recuerda que la auto-organización es un viaje de madurez. Te dejo algún post más, antiguo, de hace 7 años, sobre auto-organización.

Y lo que no puedes hacer es imposibilitar de raíz que la auto-organización crezca.

Si ordenas un Product Backlog pensando en personas, no lo ordenas por valor, no lo ordenas de la mejor manera para el negocio

Lo que más importa a nivel de valor, a nivel de negocio, aquello más importante a añadir ya, en el siguiente Sprint, al incremento, no tiene porque coincidir con un ordenamiento del Product Backlog pensando en personas. Y esa no es una buena estrategia, nada. 

Ordena un Product Backlog por valor, que es lo que hay que hacer y deja que el equipo lo resuelva de la mejor manera.

Es probable que tengas un Product Backlog de tareas, en vez de de historias

Tiene pinta de que, si tienes un Product Backlog ordenado en función de asignaciones a personas, ese Backlog tenga tareas que, una a una, se asignan a personas.

Y lo que debería tener un Product Backlog son Historias, que son un qué (en vez de un cómo, que es lo que son las tareas), de las que el equipo saca varias tareas (los cómo), que ellos se distribuyen. 

Esto, de nuevo, merma la auto-organización y…

Mermas que la multi-funcionalidad madure

Un equipo ágil es, debe ser, multifuncional, debe él solo dejar el incremento en pre o producción y, además, debe ser T-Skill.

Lo de T-Skill dice que para ser multifuncipnal no es necesario que todo miembro del equipo sepa hacer de todo… pero si que cada miembro del equipo sepa hacer algo más que aquello en lo que está especializado.  

Si ya de partida, Product Owner, te pones tú a crear historias que son tareas, y a asignarlas… no vas a potenciar que maduren las T-Skills.

 
 
 
 
 
Ver esta publicación en Instagram
 
 
 
 
 
 
 
 
 

El equipo #agil multifuncional

Una publicación compartida de Javier Garzás (@javiergarzas) el

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

1 comentario en “Asignar Historias a Personas suena muy mal, es muy Lado Oscuro”

  1. Esto lo he sufrido en mis propias carnes. Un product owner (tenía ese rol pero ni idea de agilidad) preguntando al equipo de desarrollo al principio del sprint quién iba a hacer determinada historia de usuario, e incluso queriendo asignarlas TODAS. Era una pura cuestión de desconfianza en el equipo, quería saber quién iba a hacer qué para después poder señalar con el dedo si no entraba todo a tiempo.

    También lo he visto por otro motivo, creo que más habitual, de intentar que la historia que requiere más complejidad lo haga el miembro del equipo más senior

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *