Es en serio, las historias usuario tienen que ser pequeñas

Hola a todos

Quisiera compartirles hoy una situación que con seguridad les habrá pasado a algunos de ustedes.

Dentro de las primeras recomendaciones que como Agile Coach que se le comparten a un equipo de software que comienza a trabajar con Scrum es que “las historias de usuario tienen que ser pequeñas”, es decir:

• Toman máximo 2 a 3 días en lograr el DONE (4)  (o sea que todas las tareas de ingeniería sumadas toman ese tiempo: análisis + diseño + implementación + prueba par + corrección + despliegue + pruebas + corrección + volver a desplegar, entre otros)
• Tienen aproximadamente 6 a 8 criterios de aceptación cada una (ver post)
• El sprint backlog cuenta con entre 6 a 10 historias de usuario de similar tamaño (ver post), obvio no siempre se cumple esta condición pero debemos procurar de que sea así,
• Que sea tan pequeña que quepa en una tarjeta (media hoja de cuaderno, ojalá menos)

Lamentablemente en ocasiones estas recomendaciones son tomadas a la ligera por el cliente o por los nuevos Scrum Masters, por los Product Owrners y por el equipo desarrollador, teniendo como consecuencia la aceptación de Historias de Usuario que más bien son Épicas, generando:

• Sprint backlogs de 1 historia que sobre vive muchos sprints
• Sprint backlogs de 2 a 3 historias y a duras penas lograron cerrar una
• Entre otros casos

Algunos Pensamientos

Asociado a este antipatrón quisiera compartirles hoy varios pensamientos:

• Si un sprint es de 10 días –por ejemplo - implica que si una historia de usuario toma 8 o más días-persona para lograr el DONE ocasionando que muy probablemente esa historia no se termine y deba ser completada el próximo sprint si el Product Owner la prioriza.
• Si una historia toma más de dos o más sprints en lograr el DONE puede tener como causasNo hubo un correcto refinamiento del backlog y la historia no cumplido el requerimiento de ser pequeña (1)
• Se aceptó una historia de usuario que no tenía sus dependencias resueltas y que otro equipo o alguien externo al equipo de desarrollo le juro y perjuro al Product Owner que las dependencias estarían resueltas durante el sprint, no cumpliendo así la Definition of Ready (verpost) – dependencias que pocas veces se resuelven 
• La historia de usuario realmente es una historia épica (DURA DE MATAR) que sobrevive muchos sprints teniendo como causa la carencia de refinamiento y de partición de historias (ver recomendaciones para partición de historias)
• Los criterios de aceptación están tan amplios que “le cabe un tren de lado” (así decimos en mi tierra – Colombia – ), de nuevo careciendo la historia de usuario de refinamiento y de la correcta partición (ver recomendaciones para particiónde historias)
• Al momento de escribir historias de usuario estas no cumplen dos de los criterios de INVEST (1) – Estimables y Small –, pues realmente no son estimables, (algo que he observado es que las estimaciones se vuelven inexactas más allá de los 10 días-persona) agregando gran incertidumbre a la estimación hecha (ya sea por planning poker u otro método)

Consecuencias

Cuando estas recomendaciones no se siguen ocasionaran:

• Muy probablemente no haya Review (o demo), pues no hay nada que mostrar, se le pregunta al equipo y dicen “hemos hecho mucho, nos hemos esforzado mucho y nada que terminamos”, por lo tanto no hay incremento, por ende no hay generación temprana de valor, lo que nos lleva a que Scrum “no funciona” porque no se cumplió lo que se prometió con el framework.
• Si no hay demo, el Product Owner y Stakeholders sienten que el equipo no avanza
• El equipo encuentra cada vez más y más tareas técnicas que no había identificado y parece esto no tener fin
• Se genera deuda técnica funcional (pues muchas veces dicen entreguemos así y nos queda pendiente, esto, esto, esto y esto.. y ya veremos cuando lo hacemos)
•  En la retrospectivas creen que el equipo está mintiendo, y se comienza a generar desconfianza en el ecosistema ágil que queremos crear.

 Es en serio,

las historias usuario tienen que ser pequeñas

las historias usuario tienen que ser pequeñas

las historias usuario tienen que ser pequeñas

Sino fallará tu implementación de Scrum.

Cerrando

Recuerda:

• Seguir las 3 C´s (2) y el criterio INVEST(1) siempre, 
• Realizar refinamiento de historias en la mitad del sprint de manera que lleguen en ready al planning (ver post de refinamiento)
• Hacer una buena partición (slicing) de las historias de usuario (recuerda la guía)
• Y Si tu Product Owner se aparece en el planning con una historia que toma más de 6 días-persona como Scrum Master o Team Member deberías (según el contexto)
• no aceptarla, o
• hacerle partición y negociación en el planning para lograr generar un entregable en el sprint

Hasta acá este compartir

Saludos ágiles

Jorge Abad

Notas, referencias, comentarios y aclaraciones

1. INVEST
• Independientes
• Negociables
• De Valor
• que se puedan Estimar
• pequeñaS (small)
• que puedan ser Testeables
2. Las 3 C’s
• Card (caber en una tarjeta)
• Conversación
• Confirmación
3. Te recomiendo estos dos excelentes post en esa misma línea:
• Por Lucho Salazar - El Tamaño si importa (clic aquí)
• Por Javier Garzas - ¿Por qué las Historias de Usuario deben ser lo más pequeñas posible? (ver post)
4. Inicialmente  tenía de 5 a 6 días-persona pero mi experiencia ha demostrado que se puede en menos,