Clarificando historias

Lo peor ocurre cuando el equipo demuestra orgulloso una nueva funcionalidad en la demo de Sprint y el Dueño de Producto frunce el ceño y dice “vale, muy bonito, pero ¡eso no es lo que yo pedí!”.

¿Cómo te aseguras de que el concepto que tiene el Dueño de Producto sobre una historia coincida con el concepto del equipo? ¿O de que cada miembro del equipo tenga el mismo concepto sobre la historia? Bueno, no se puede. Pero hay algunas técnicas simples para identificar los malentendidos más flagrantes. La técnica más simple es simplemente asegurarse de que todos los campos están rellenos para cada historia (o más específicamente, para cada historia con suficiente importancia como para ser considerada en este Sprint).

Ejemplo 1:

El equipo y el Dueño de Producto están contentos con el plan de Sprint y están listos para terminar con la reunión. El Scrum Master dice “esperad un segundo, esta historia llamada “añadir usuario”, no tiene estimación. Hagamos una estimación.” Tras un par de rondas de planning poker el equipo acuerda 20 puntos de historia, haciendo que el Dueño de Producto se levante preso de un ataque de rabia, “¡¿Como?!”. Tras unos minutos de discusión acalorada, resulta que el equipo entendió mal el alcance de “añadir usuario” y pensaban que significaba “un bonito interfaz Web para añadir, eliminar, buscar usuarios”, cuando el Dueño de Producto quería decir “añadir usuarios a mano haciendo sentencias SQL contra la base de datos”. Estiman de nuevo y acaban con 5 puntos de historia.

Ejemplo 2:

El equipo y el Dueño de Producto está contentos con el plan de Sprint y están listos para acabar la reunión. El Scrum Master dice “esperad un segundo, esta historia que se llama “añadir usuario”, ¿cómo debería demostrarse?”. Se producen algunos murmullos y tras un minuto alguien dice “bueno, primero nos autenticamos en la Web y luego…” y el Dueño de Producto interrumpe “¿autenticarse en la Web? No, no, no, esta funcionalidad no debería de ninguna forma ser parte del sitio Web, debería ser sólo un script muy sencillo para los administradores técnicos”.

La descripción de “como probarlo” de cada historia puede (y debe) ser muy breve. De otra forma no terminarás con la planificación de Sprint a tiempo. Es básicamente una descripción básica a alto nivel, en castellano simple, de cómo ejecutar el escenario de pruebas más común manualmente. “Haz esto, entonces haz lo otro y verifica aquello”. He descubierto que estas descripciones simples a menudo descubren malentendidos importantes sobre el alcance de una historia. Menos mal que las descubrimos pronto, ¿verdad?