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)
- 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.
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
- INVEST
- Independientes
- Negociables
- De Valor
- que se puedan Estimar
- pequeñaS (small)
- que puedan ser Testeables
- Las 3 C’s
- Card (caber en una tarjeta)
- Conversación
- Confirmación
- 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)
- Inicialmente tenía de 5 a 6 días-persona pero mi experiencia ha demostrado que se puede en menos,
Doc, sin duda, cuando se trata de historias de usuario, el tamaño sí importa. Aprovecho para clarificar que esto de los 5 o 6 días máximo por historia es para Sprints de 10 días (o más), porque puede dejar la impresión entonces, quizás para los más novicios en el tema, que no es posible tener sprints de 5 días o menos cuando, de hecho, sí es posible.
ResponderBorrarComo siempre, encuentra uno grandes recomendaciones en tus artículos. ¡Muchas gracias!
Superchévere ese feedback Lucho..Gracias!!! es importante hacer claridad en eso.
BorrarEste blog ha sido eliminado por un administrador de blog.
ResponderBorrarHola, y gracias por la orientación, ha sido de mucha utilidad, solo tengo una duda;
ResponderBorrarSe podría crear una historia de usuario específicamente para el sistema? ejemplo:
Como: Sistema
Quiero: enviar un correo electrónico a los usuarios registrado
Para: Verificar que el email proporcionado sea existente y de su propiedad.
te recomiendo leer este post http://www.lecciones-aprendidas.info/2019/05/modos-de-representacion-de-las-historias-de-usuario.html
ResponderBorrarlas historias de usuario son de formato libre.. puedes usar lo que quieras.. la clave es que sea pequeña y una construccion incremental
aun asi.. podrias escribirlas como lo promogo en este post http://www.lecciones-aprendidas.info/2016/02/historias-de-usuario-de-sistema-una.html
desde el punto de vista del area que va a usar el resultado
Excelente , muy claro y conciso
ResponderBorrar