Cómo Estimar la Capacidad (Velocidad) de tu Equipo Scrum en el Primer Sprint

Sobre el Product Backlog, Sprint Backlog y los ítems de Backlog

 

Hola a todos

La guía de Oficial de Scrum (la actual, la publicada en 2017 en https://scrumguides.org/  ), tiene una serie de definiciones sobre el Product Backlog, el Sprint Backlog y los Ítems de Backlog que comparto literalmente a continuación:

El Product Backlog es:

• una lista ordenada de todo lo que se conoce que es necesario en el producto
• esta compuesto por ítems de backlog
• un artefacto vivo
• enumera todas 
• las características
• funcionalidades
• requisitos
• mejoras
• y correciones que constituyen cambios a realizarse sobre el producto para entregas futuras
• varios equipos (varios Equipos Scrum trabajan juntos en el mismo producto)
• se utiliza una única Lista de Producto para describir el trabajo a realizar

Un Ítem de Backlog:

• Tiene como atributos
• descripción
• orden
• estimación
• y el valor
• muchas veces incluyen descripciones de las pruebas  que demostrarán la completitud de tales elementos cuando estén “Terminados
• varios equipos (varios Equipos Scrum trabajan juntos en el mismo producto)
• podría emplearse un atributo de la Lista de Producto para agrupar los elemento

Sprint Backlog contiene:

• objetivo del sprint: es una meta establecida para el Sprint
• el conjunto de elementos de la Lista de Producto seleccionados para el Sprint
• incluye al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior para asegurar el mejoramiento continuo

Hasta acá este corto compartir

Saludos Ágiles

Jorge Abad

La Guía de Scrum 2017 - En Mapa Mental

Hola a todos

La Guía de Scrum, la oficial, la publicada en https://scrumguides.org/, y en su versión en español para suramérica en 2017 https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf  traducida por mi estimado amigo Lucho Salazar, es un trabajo de sus creadores Jeff Sutherland y Ken Schawber de más de 20 años sobre ella.

Es bastante rica en conceptos, prácticas y sugerencias, fuera de ser muy, pero muy resumida.

Muchas veces al hacer una lectura de la misma, no somos conscientes de la cantidad de información allí depositada, y como nos pasa a muchos, cada vez que vamos a buscar un concepto, nos encontramos con perlas ocultas a nuestros antiguos ojos desprevenidos (los ojos del pasado) o tal vez sin el conocimiento para entender lo allí descrito, (me decía mi amiga Paola Becerra,  el ojo ve lo que es capaz de interpretar).

Bueno, con el fin de decodificar un poco la guía, me he animado a ponerla en formato de mapa mental.

Mapa Mental - Capítulos

Mapa Mental - Capítulos y Subcapítulos

El ejercicio no fue muy estricto desde las recomendaciones para crear mapas mentales, pero si con miras a ubicar fácilmente conocimiento clave.

Mapa Mental Completo - (lo sé, no se ve nada, pero es para que te hagas una idea de lo extenso del mapa)

De igual forma, he marcado en color verde y con (*) el texto relevante o las perlas ocultas a mis ojos del pasado.

Descárgalo y Úsalo

A continuación, pongo a su disposición varios formatos de descarga y visualización

• Descargar PDF - aquí  (es el más sugerido debido al tamaño, debes descargar y abrir desde un navegador web, como: Chrome, Edge, o Firefox, etc)
• Word - aquí
• PNG Aqui
• SVG - aquí

Espero que esta decodificación les sea tan útil como lo fue para mí, en este entendimiento y reestudio de la guía.

Disfruten las perlas (las que estan con asterisco (*) y en verde)

Saludos ágiles

Jorge Abad

Algunas Ideas Claves sobre Historias de Usuario

Hola a todos:
Les quisiera compartir un listado de ideas centrales sobre historias de usuario que por lo regular comparto en los entrenamientos en Scrum:

1. Las historias de usuario no son especificaciones
2. Una historia de usuario debe ser tan pequeña que obligue a una conversación cara a cara donde todos entiendan mejor el problema (Leonardo Agudelo)
3. Es preferible una historia de usuario ambigua que una bien escrita (la razón: la ambigua invita a la conversación) (Jeff Patton)
4. Paremos de especificar las historias de usuario comencemos a explicarlas (Jeff Patton)
5. Es en serio, las historias de usuario tienen que ser pequeñas (ver post aquí)
• Una buena historia de usuario debe tomar entre 3 y 5 dias persona de esfuerzo para lograr el DONE
• Una buena historia de usuario tiene entre 4 a 8 criterios de aceptación
6. Lo más importante de una Historia se usuario es que sea menos importante que la conversación (Juan Pablo Bernal)
7. Un buen sprint backlog tiene entre 6 a 10 historias de usuario (ver más acá)
8. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante (Lucho Salazar).
9. Es un error decir: "la historia de usuario está mal especificada", pues la historia de usuario no es una especificación, es mejor que este "mal escrita" por que invita a una conversación y una aclaración sobre la misma.
10. Se llaman historias de usuario no "especificaciones de usuario", por lo tanto el énfasis se debe hacer en la historia que cuenta el usuario y no en lo que esta escrito o tratado de especificar.
11. Las historias de usuario deben ser porciones funcionales end-to-end, que cuando funcionen se implementen agreguen valor, o sea, pasen exitósamente el siguiente test:
• ¿puedo ponerla en producción?
• ¿un usuario final puede usarla sin necesidad de algun truco o script extraño?¿es decir, se puede acceder desde la interfaz de usuario y funciona completamente?
12. Una historia de usuario debe ser construible en su totalidad durante un sprint (incluyendo pruebas, documentación, despliegue y todo lo que este en la "Definition of Done")
13. "Las historias de usuario son DICHAS,  no escritas." / "Key point: User Stories are TOLD, not written".(Ron Jeffries)

@jmbeas @jeffpatton @david_caicedo http://t.co/nZu7d99Va2http://t.co/pcRLrNfs48

Key point: User Stories are TOLD, not written.

— Ron Jeffries (@RonJeffries) May 23, 2015

Espero les sean útiles estas cortas ideas.

Saludos Ágiles

Jorge Abad

Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint

Hola a todos

Continuando con la reflexión acerca del tamaño de las historias de usuario y basado en la retroalimentación de mi estimado y bien ponderado amigo Lucho Salazar - @LuchoSalazarC, quiero compartirles esta tabla de tamaños sugeridos para las historias de usuario.

La siguiente tabla cuenta con las siguientes consideraciones:

1. Es una sugerencia, cada equipo, cada producto tiene su contexto y tendrá sus propios números, prácticas emergentes y conclusiones.
2. Esta basada en el artículo "Patterns for Splitting User Stories" de Agile for All (ver post) (ver los patrones de división en español aquí - http://agileforall.com/wp-content/uploads/2013/06/Story-Splitting-Flowchart-ES.pdf ) donde se sugiere que una buena historia de usuario debe tener entre 1/6 a 1/10 de la velocidad del equipo cada sprint
3. Recordemos que el tiempo requerido para el DONE de una historia de usuario (del mundo del software) debe incluir todas las tareas técnicas que sean relevantes y requeridas, por ejemplo:
• Análisis
• Diseño
• Implementación
• Revisión Par (esta es una buena práctica)
• Despliegue
• Pruebas
• Corrección
• Despliegue
• Pruebas
• Actualización de documentación relevante para el equipo.
4. Por ejemplo si consideramos un sprint de 2 semanas y un equipo de 5 personas, el tamaño promedio sugerido de Historia de Usuario está entre 5 y 8 días persona, por lo tanto, ejemplo si tomamos la de 5 días, le tomará tomará al equipo aproximadamente 5 días-persona, lograr el DONE (o sea, todas las activadades identificadas en el punto anterior)
5. Debemos procurar que los ítemes del sprint backlog (las historias de usuario para el caso del software) sean de similar tamaño, no siempre se logrará, unas veces sí, otras veces no.
6. Sigo considerando que el tamaño razonable de Sprint es de 2 semanas, máximo 3, pero siempre tender al tiempo más corto.
7. Aunque muchas veces la construcción de historias de usuario de sistemas que tienen muchas capas requieren muchos muchos días de esfuerzo para lograr el DONE, si un esfuerzo requerido es superior a 10 días-persona, debe ser revisado cuidadosamente para determinar si es susceptible de ser reducido por técnicas de partición de historias de usuario.
8. Si como Scrum Master estás pensando que tu equipo va solo a trabajar historias de usuario en el sprint, es falso, recuerda que asiste a todas las reuniones de Scrum (Planning, Review, Retrospectiva, Daily, Refinanmiento) y estas toman entre el 10% al 20% del tamaño del Sprint.

Hasta acá este pequeño compartir, espero les sea útil.

Saludos ágiles

Jorge Abad

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,

Scrum: Hoja del Sprint y los Riesgos

Una de las características de scrum y de las metodologías ágiles es la importancia que se le da a la visualización de información o radiadores de información, esto no implica que no haya seguimiento y elementos digitales pero se le da prelación a lo visual (preferiblemente papel) esto logra:

• compromiso del equipo 
• información instantánea (no se requiere ingresar a url para saber algo)
• el equipo sabe el status del compromiso en el Sprint y en el Release de manera constante.
• se visualiza la deuda técnica
• se observan los bugs y problemas que han habido durante la construcción del producto
• se visualiza la velocidad a través de los sprints.

Una de los elementos radiar es la "Hoja del Sprint" o "Página de Información del Sprint" la cual cuenta con los campos:

• Nombre del equipo
• Nombre del producto
• Número del Sprint
• Objetivo del Sprint
• Pila del Sprint (debe estar en orden, arriba las historias mas prioritarias con su respectivo puntaje)
• Velocidad estimada
• Calendario (fecha y lugar de la diferentes reuniones)
• Daily
• Refinamiento
• Review
• Retrospectiva
• Equipo (cada miembro con su dedicación)
• Product Owner (PO)
• Scrum Master (SM)
• Cada miembro del team developer 

Un campo adicional que he observado que sirve a todo el equipo de Scrum (PO, SM y Team Developer) para poner atención a los elementos que pueden hacer fracasar el sprint, es el de RIESGOS.

La idea es poner este campo con los posibles riesgos priorizados que afectan al sprint y las historias que estan siendo afectadas por este riesgo en caso que aplique, por ejemplo:

• Riesgos
• No se llegue a un acuerdo sobre los campos (afecta historia: Depósito)
• La migración no sea "transparente" (afecta historia:  Herramienta migración)

Aunque una cosa es cierta, el SM y todo el equipo deben procurar que al sprint no se entren historias con riesgos que hagan "caer" el sprint y los puntos comprometidos (por lo general se usa un SPIKE, que es una historia con TIMEBOX y salidas definidas que permiten resolver los riesgos durante un sprint anterior, ejemplo: "realizar pruebas de concepto de la migracion",valor asignado 2 puntos). Si inevitablemente se debe entrar al sprint con riesgos, la visualización de los mismos hace parte de una buena gestión de impedimentos en cabeza SM y de todo el equipo Scrum.

De todos modos, no se debe perder la oportunidad de la retrospectiva para aprender si fue efectiva o no la gestión de riesgos y los resultados obtenidos por permitir su ingreso al sprint.

Saludos ágiles

Jorge Abad

[1] Scrum y XP desde las trincheras - http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

_

Tips para el Sprint Backlog: Primero las HU Riesgosas y luego las prioritarias

Hola a todos

Recordemos:

• Sprint backlog: ítemes de backlog (en nuestro caso Historias de Usuario - HU) comprometidos a construir durante el sprint.

De las primeras cosas que aprendí en Scrum, al ver que un sprint fallaba fue:

Hacer de primero las HU más riesgosas y aunque no sean las prioritarias para el Product Owner (PO)

Razones:

• si comienzas muy tarde a hacer la HU es probable que por sus dependencias o complejidad no la termines.
• Obvio después de la(s) riesgosa(s) poner las HU que tengan más prioridad de forma que siempre estemos dando el máximo valor a medida que avanza el sprint.

Sugerencias:

• Hacer ver al PO por que va esta(S) HU(s) de primero.- La verdad no es complejo-.
• Debido a que esta historia va primero solicitar los insumos para hacerla, en caso que no estén,  poner una fecha máxima para la recepción de insumos, en caso contrario,  hacer ver que si no se reciben oportunamente la historia se cae (no se culmina), y esos puntos no se logran.
• Lo ideal y recomendado es comenzar el sprint con los insumos (información, componentes, definiciones, etc) claros y resueltos para que el Sprint avance sin tropiezos.
• Si una es HU riesgosa y se observa que la posibilidad de completarla es casi nula debido a su complejidad:
• Definir un Spike (tarea dentro del sprint) con timebox definido (léase timebox=tiempo fijo) y objetivos definidos
• Ese spike debe tener como objetivo eliminar la complejidad y adquirir el conocimiento necesario para lograr estimar y construir esa HU en el siguiente sprint
• No tener muchas historias de usuarios riesgosas, a lo sumo 2 de un máximo de 7 HU (un sprint debería tener a lo sumo entre 6 y 8 HU), debido a que si son muchas el sprint puede ser un fiasco y no completar nada. (situación que viví y de la cual aprendimos como equipo)
• Enfocarse y enfocar al equipo durante la ejecución del sprint en máximo 2 historias al tiempo de forma que se evacue siempre lo primero. Esto en Kanban se llamaría un limite de 2.

Saludos y abrazos ágiles a todos

Jorge Abad