RespuestasAgiles: ¿Qué son los puntos de historia?

/

¿Cuándo podríamos estimar una historia de usuario con mejor certeza? La matriz de Stacey, una técnica a usar en el Refinamiento

Hola a todos

La matriz desarrollada por Ralph Stacey, conocida como la Matriz de Stacey, permite entender cuando de acuerdo con los ejes de Requerimientos y Tecnología, podemos tener una aproximación de gestión simple, complicada, compleja;

Matriz de Stacey. Tomado de (1)

 

y dados estos escenarios, se ha usado en los últimos años, para justificar en que escenarios trabajar con métodos tradicionales y cuando con enfoques ágiles (existen cientos de artículos al respecto).

Matriz de Stacey. Tomado de (2)

Usando este mismo enfoque, podríamos identificar en un taller de Inception o de Refinamiento, cuando una historia de usuario o una épica incluye mucha o poca incertidumbre para ser estimada y, por ende, desarrollada, tanto desde el punto de vista de requerimientos, como de tecnología, proporcionándonos estimaciones indirectas sobre tiempos y esfuerzos requeridos (toda estimación incluye una probabilidad y una incertidumbre asociada).

La zona donde cualquier equipo de desarrollo, ágil o no, estima con confianza, es aquella donde hay alta certeza en los requerimientos y alto certeza en la tecnología y forma de construirlo. Los Product Owners deben procurar que la mayoría de las historias de usuario y épicas que llevan a un equipo se encuentran en esta zona. Ahora, si existe incertidumbre, podríamos hacer uso de técnicas de partición de historias de usuario (3) o de spikes para realizar investigaciones de aquellos elementos que no se encuentran claros al momento de desarrollar.

Los equipos ágiles deben preferir historias en esta zona de confianza, y estos elementos podría hacer parte de una Definición de Ready o Preparado adecuada, para que las historias puedan ser incluidas en el planning. Los siguientes criterios que garantizan esta zona de estimación con certeza: 

• Las historias cumplen cumplen INVEST y las 3C
• Existe un entendimiento consistente de parte del product owner y del equipo acerca de la historia de usuario.
• Las historias cuentan con claros criterios de aceptación 
• Se han resuelto las dependencias técnicas y funcionales
• Las ambigüedades se han resuelto
• El tiempo para construir-probar-desplegar la historia de usuario se encuentra en horizontes de tiempo menor o igual a 4 días-persona (esto es una heurística que he observado en los equipos ágiles, en este número de dias las estimaciones son más certeras y confiables. Habrá que hacer un estudio riguroso para confirmar mi experiencia e hipótesis).

Para cerrar, los invito a que usen esta matriz para realizar refinamiento de historias de usuario con sus equipos, asegúrense que existe certidumbre en la tecnologia y acuerdo en los requerimientos, de esta forma fluirán mejor sus sesiones de planning y no se enfrascarán en discusiones innecesarias.

Saludos ágiles,

Jorge Abad

Referencias

1. Entendiendo la complejidad: La matriz de Stacey - https://academy.jeronimopalacios.com/courses/145560/lectures/5315213
2. https://www.researchgate.net/figure/Stacey-Matrix-Stacey-1996-adapted-to-software-development_fig3_336899045
3. Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario

"Todos tienen un plan hasta que son golpeados en la cara". - Mike Tyson

 

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

Un Método Adicional de División de Historias de Usuario: Criterio de Equipo o Hasta Acá Llegamos

Hola a todos

Existe un método adicional de división (splitting) de historias de usuario al presentado en Leído y Recomendado: División de historias de usuario -clic aquí- y es el usado por el Criterio del Equipo o al que yo llamo "Hasta acá llegamos" y la situaciones en las que he observado que se presenta son las siguientes:

Situación 1: El equipo observa una historia de usuario muy grande

• El Product Owner (PO) explica una historia de usuario
• El Equipo la estima y la ve muy grande (ver post) o muy riesgosa,
• Entre PO y Equipo se estima hasta donde llegan en esa historia (dependiendo si la dividen por valor para el Sprint o Riesgo) y si el resto será en otra historia de usuario que posiblemente se construya en este sprint o se decida realizar el siguiente.

Situación 2: El product backlog esta casi listo y se quiere añadir una historia de usuario

• Se tiene el sprint backlog casi listo, queda un poco de capacidad libre para una nueva historia de usuario.
• El PO explica una historia de usuario
• El Equipo observa que no hay capacidad para asumir esta historia de ese tamaño y las subsiguientes historias también parecen ser de tamaños similares o superiores.
• El Equipo con el PO dividen la historia de forma que se logre incluir lo que más genera valor en el planning actual y se deja para otro sprint el resto (pero en una nueva historia).

Espero haya sido útil este corto compartir.

Saludos ágiles

Jorge Abad

Aclarando Sobre Historias de Usuario

Hola a todos

Existe una página de Facebook que pone excelentes temas de cuestionamiento sobre testing llamada "Señor Tester" - clic aquí para verla -, lo cierto es que esta semana publicaron algo que comenté pues hace parte de los malentendidos relacionados con las historias de usuario.

A continuación les comparto el post y mi respuesta

Saludos Ágiles 

Jorge Abad

------------------------

El Post: https://www.facebook.com/elseniortester/photos/a.863366253809076.1073741828.826564797489222/1457673961044966/?type=1&theater

mi respuesta fue:

Esta es la transcripción

genial...es lo mejor que puede suceder.. y observo varias cosas:

• las historias de usuario no se envían, se explican en el planning
• entre más ambiguas mejor...pues implicará que el #ProductOwner, se haga entender por todo el equipo
• Al tester no lo estan invitando al planning mal #Agile, mal #Scrum o #FrAgile -- tiene que estar allí con todo el equipo, hace parte del equipo
• te recomiendo este post   - Algunas Ideas Claves sobre Historias de Usuario - clic aquí..-
• las historias de usuario NO SON ESPECIFICACIONES.. su creador argumenta que si hubiera querido que fueran especificaciones, se llamarían ESPECIFICACIONES DE USUARIO, pero se llaman historias por que deben ser contadas y explicadas
• Al Señor Tester  le esta tocando un equipo que hace mal #Agile, mal #Scrum o #FrAgile

un abrazo Señor Tester  y espero algún días hagas parte de un verdadero equipo ágil

Un Cuarto Método para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning

Hola a todos

Hoy quisiera compartir un cuarto método de los tres anteriormente compartidos en el post "Tres Métodos para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning" - (clic aquí para leerlo).

Es muy parecido al ojo de buen cubero.

El proceso es sencillo

1. Se toma una historia de usuario que todo el esfuerzo (1) requerido para construirse tome entre uno y dos  días-persona (o sea, si sumas todas las horas usadas para construir la historia de usuario sin considerar tiempos muertos tome entre uno y dos días) - Consejo: entre más cercano a un día de esfuerzo es mejor - de ahora en adelante esa será la historia pivote (2) y tendrá el tamaño de un punto
2. Luego pregúntale al equipo. ¿cuántas historias pivote o de un punto son capaces de hacer en un sprint?
3. El equipo hará su estimación y dirá por ejemplo somos capaces de hacer 20 de esas.
4. Ok, acabas de tener la capacidad de tu equipo
5. Ahora si, con esta información comienza el planning y compara todas las historias con respecto a la historia de usuario pivote, preguntando por ejemplo ¿esta nueva historia es 1,2,3,5,8 veces la historia pivote?, El equipo realizará planning póker y sumaras los puntos hasta que llegues a un número cercano a 20.

Otro punto importante a tener en cuenta, también determina cual es tamaño máximo que el equipo puede aceptar de historia de usuario, es decir

• Si el sprint es de 2 semanas, es decir 10 días hábiles, y 8 de ejecución quitando las reuniones de planning, dailys, refinamiento, review, retrospectiva
• si la historia es de aproximadamente 1 día, el tamaño máximo deberá ser 8 puntos, 13 puntos sería imposible de lograr
• si la historia es de aproximadamente 2 días, el tamaño máximo deberá ser 5 puntos (y eso con un alto riesgo de no lograrse)

Y recuerda una buena práctica es que tu sprint backlog tenga entre 6 a 10 historias de usuario de similar tamaño

Hasta acá este corto compartir.

Saludos Ágiles 

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Esfuerzo es diferente a Duración, algo te puede tomar 2 días de esfuerzo pero la duración puede ser 3 pues hay tiempos muertos entre una tarea y otra hasta completar la historia de usuario
2. Hace un tiempo realice una tabla de tamaño de historias de usuario de acuerdo al tamaño del sprint (http://www.lecciones-aprendidas.info/2017/05/Tamanos-sugeridos-de-historias-de-usuario.html ), cada vez me convenzo más que deben ser lo más pequeñas posibles. 

El Planning, el Tasking, el Tablero Kanban, la Guía de Scrum y un Tip Poderoso para “Oler” Impedimentos

Hola a todos, este es uno de los post que hace tiempo tenía pendiente por escribir y por fin se alinearon los astros y pude escribirlo.

Empecemos, según la Guía Oficial de Scrum (1) el planning consta de dos partes:

• Tema Uno: ¿Qué puede hacerse en este Sprint? (conocido como “El Qué”): El cual consiste en la identificación del Objetivo del Sprint y la lista de ítems de backlog que hacen parte del producto que si se completan lograrían el Objetivo del Sprint

• Tema Dos: ¿Cómo se conseguirá completar el trabajo seleccionado? (conocido como “El Cómo”): El cual consiste  que el Equipo de Desarrollo decide cómo construirá esta funcionalidad para formar un Incremento de producto “Terminado” durante el Sprint que cumpla con el Objetivo y contenga los ítems seleccionados en el paso anterior más el plan para terminarlos.

Adicionalmente, para el tema 2 dice claramente:

“El Equipo de Desarrollo por lo general comienza diseñando el sistema y el trabajo necesario para convertir la Lista de Producto en un Incremento de producto funcional. El trabajo podría ser de tamaño o esfuerzo estimado variables. Sin embargo, durante la Planificación del Sprint se planifica suficiente trabajo como para que el Equipo de Desarrollo pueda hacer una proyección de lo que cree que puede completar en el Sprint que comienza. Para el final de esta reunión, el trabajo planificado por el Equipo de Desarrollo para los primeros días del Sprint es descompuesto en unidades de un día o menos.” (Esto último es conocido en el mundo de Scrum con el Tasking, o la descomposición en tareas de los ítems de backlog - como la palabra misma lo sugiere-)

Aquí vemos dos cosas:

• Se sugiere que el trabajo se descomponga de forma gradual en unidades, o sea, NO SE DESCOMPONGA TODO A PRIORI  en el planning del sprint (ya sea por timebox o conveniencia), sino que se identifique claramente las tareas próximas de lo próximo que se va a hacer y luego se descomponga el resto cuando estemos cercanos a construirlo (esto es conocido en el mundo de gerencia de proyectos como Planeación Gradual o Rolling Wave Planning – la cual empleamos nosotros ampliamente en el mundo ágil –). Acá quiero hacer una precisión, nunca lo he hecho así, siempre sugiero o hago la descomposición de todas las historias de usuario en tareas durante el planning  –y nos ha ido bien –, haré el experimento y lo compartiré.
• Lo segundo que me parece MUY PODEROSO es descomponer el trabajo en unidades de UN DÍA O MENOS.

Y es en esto último donde uno dice: “Claro, tiene sentido, de esa manera todos los días se finalizará algo y de esa forma se sentirá el progreso y se identificarán fácil los impedimentos y puntos de atasque".

Basado en lo anterior vienen los siguientes puntos

Cómo he trabajado el tasking o cómo lo he visto

Este ejercicio de descomponer las historias de usuario en tareas de un día o menos (léase Tasking), y me he encontrado con equipos que han decidido manejarlo de diferente manera, el punto no es discutir cuál es la mejor, es mejor pensar, con cual se siente más cómodo mi equipo, adicionalmente puede que lo hagan de una forma durante un tiempo y luego cambien a otra (recordemos el principio básico de la gestión empírica “Inspección y Adaptación”), volviendo al tema las formas de tasking que he observado son:

Forma de tasking	Observación
·         Dividir la historia de usuario en tareas de tamaños de unidades entre 1 y 8, así: 1h, 2h, 3h, 4h, 5h, 6h, 7h, 8h	La verdad esta no me gusta, lo que he encontrado es que no somos buenos estimando en esta forma, pues la precisión aun a nivel de tareas aún es baja en desarrollo de software, adicional abre el espacio a la microgestión que limita al equipo y no permite que el equipo aprenda.
·         Dividir historia de usuario en las tareas de tamaños de 2h, 4h, 6h, 8h	Esta forma me gusta, brinda amortiguación si se falla en la estimación.
·         Dividir la historia de usuario en las tareas de tamaños de 2h, 4h, 8h	Esta es la que más me gusta, por la misma razón de la anterior, adicionalmente permite que falles, aprender, mejorar, da más libertad al equipo.
·         Dividir la historia de usuario en tareas sin horas pero garantizando que cada tarea es menor a un día	Esta forma la he visto en equipos muy maduros en los cuales la confianza y transparencia son una constante presente en su día a día.

Ahora el Super Tip

Este tip me lo enseño Silvia Lozano (@sila_zenufana) – y me ha servido montones con los equipos que he tenido la suerte de estar y acompañar –, quien me sugirió en el tablero kanban poner UN PUNTO por cada día que permanece la tarea en la zona del WIP (“Work In Progress” o “Work in Process”) de esta manera se identificará que una tarea requiere ayuda si tiene más de DOS PUNTOS, pues recordemos que como tenemos por regla (o sugerencia) que las tareas no deben durar más de un día, si las tareas en el tablero kanban tienen DOS PUNTOS O MÁS significa que:

• Existe un posible impedimento
• Existe una posible dificultad en desarrollar la tarea
• Existe una posible falta de foco o de habilidad por parte de desarrollador que esta trabajando en ella
• Se estimó de una forma muy optimista o con falta de conocimiento del real tamaño
• Existe un desbordamiento de alcance
• O es un punto de mejora para discutir en la retrospectiva

En cualquiera de los anteriores es un punto donde tanto Scrum Master como Equipo observan un punto en el que hay que hacer intervención.

OJO: Lo anterior funciona muy bien si tenemos la buena práctica que siempre haya en el tablero una tarea por persona del equipo – recordemos que solo somos capaces de hacer una cosa a la vez, o sea en el WIP una persona no puede tener más de dos tareas –  o sea, que en el WIP si el equipo tiene 4 integrantes a lo sumo existirán 4 post-it (o pósit (2)) a la vez que representan una tarea por cada uno de ellos.

Cerrando

Espero que lo compartido sea de utilidad en tu equipo Scrum, y para terminar tres preguntas

• ¿Cuándo fue la última vez que leíste la guía oficial de Scrum?
• ¿Qué descubrimiento has hecho?
• ¿los puedes compartir?

Bienvenida la retroalimentación y sus comentarios.

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1.  La que se encuentra en Scrumguides.org
2.  Es correcta esta forma de escribirlo, la RAE lo permite ver acá  Pósit  http://dle.rae.es/?id=TnfXVsj

Tres Métodos para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning

Hola a todos

Uno de los primeros retos que enfrenta un Scrum Master con su Equipo es realizar el primer planning, pues para este no hay velocidad anterior (1), quiero compartirles tres propuestas de como se hace este cálculo, las cuales son muy sencillas, pues la verdad en la agilidad preferimos invertir más tiempo en el desarrollo de software que en la estimación que a la larga siempre fracasamos en ellas y terminan siendo un desperdicio.

Demos inicio.


Datos de entrada

• Un equipo multifuncional de 6 personas
• Un Product Owner (obviamente, no esperaría menos)
• Un Scrum Master (obviamente, no esperaría menos)
• Un sprint de 10 días)
• Días de reuniones del sprint: 1.5 días aproximadamente  (ver tabla de tiempos reuniones de Scrum - clic aquí -)
• Planning medio dia
• Review y retrospectiva medio día
• Refinamiento máximo el 10% del tiempo del sprint
• Días efectivos del sprint: 8.5 días (8.5 días = 10 días del sprint - 1.5 días de reuniones)
• Días-persona disponibles para el producto: 51 días-persona/sprint 
• (8.5 días x 6 personas = 51)

Método 1: Un día-persona es igual a un punto (punto de historia)

Los pasos son los siguientes:

1. Determino cuantos días-persona tengo (datos de entrada: 51 días-persona)
2. Le presento al equipo una funcionalidad, por ejemplo la siguiente pantalla, con todos sus criterios de aceptación
   
3. Les pido que estimen la totalidad de esfuerzo(2) requerido en días(3) para realizar las siguientes actividades correspondientes a una Definition of Done:
• Análisis de la historia de usuario
• Diseño
• Implementación (desarrollo)
• Web services (Si es que los hay)
• Modificaciones a la base de datos (si es que los hay)
• Codificación
• Pruebas unitarias
• Inspección o prueba par
• Realizar correcciones fruto de la inspección par (o prueba par)
• Despliegue en ambiente calidad
• Ajuste en calidad
• Elaboración de casos de prueba
• Probar
• Reportar las pruebas
• Corregir en ambiente de desarrollo
• Despliegue en Calidad
• Volver a probar
• Hacer los manuales o documentos que al cliente le agregan valor (manual de usuario, manual técnico o cualquier otro documento de la Definition Of Done)
• Alguna otra actividad de la Definition of Done
4. El equipo estima que para esto por ejemplo toma 2 días de esfuerzo entonces son 2 puntos (o puntos de historia)
5. Y la velocidad máxima que tendrá ese equipo en este sprint y en los demás sprints será de 51 puntos
6. Luego se siguen estimando el resto de historias de usuario hasta que se se llega a la velocidad del sprint

Ventajas

• Para toda la organización y todos los equipos la medida es única (1 día-persona = 1 punto)

Desventajas

• Los equipos tienen velocidad estática, aunque mejoren sus procesos, interacciones, forma de trabajo, se automaticen tareas repetitivas su velocidad será siempre la misma
• Serán fiscalizados en función los puntos que son capaces de lograr debido a la cantidad de integrantes y presionados a lograr el 100% de lo comprometido

Método 2: Un punto (punto de historia) es igual a una funcionalidad pivote

1. Determino los días persona (datos de entrada: 51 días-persona)
2. Le presento al equipo una funcionalidad, por ejemplo la siguiente pantalla, con todos sus criterios de aceptación
   
3. Les pido que estimen la totalidad de esfuerzo(2) requerido en días(3) para realizar las siguientes actividades correspondientes a una Definition of Done:
• Análisis de la historia de usuario
• Diseño
• Implementación (desarrollo)
• Web services (Si es que los hay)
• Modificaciones a la base de datos (si es que las hay)
• Codificación
• Pruebas unitarias
• Inspección o prueba par
• Realizar correcciones fruto de la inspección par (o prueba par)
• Despliegue en ambiente calidad
• Ajuste en calidad
• Elaboración de casos de prueba
• Probar
• Reportar las pruebas
• Corregir en ambiente de desarrollo
• Despliegue en Calidad
• Volver a probar
• Hacer los manuales o documentos que al cliente le agregan valor (manual de usuario, manual técnico o cualquier otro documento de la Definition Of Done)
• Alguna otra actividad de la Definition of Done
4. El equipo estima que para esto por ejemplo toma 3 días de esfuerzo 
5. Se considera esa funcionalidad será el pivote y es igual a 1 punto y que estimemos relativamente el resto de las historias de usuario o pantallas según el caso.
6. La velocidad esperada ese primer sprint será = 17 puntos (51 días-personas/3 días =17 puntos) 
7. Para la siguiente historia saco el lapicero de Will Smith de Men in Black y pido que miren fijamente, diciéndoles que olviden el cálculo 1 punto es aproximadamente 3 días y que sigamos pensando solo en la pantalla y estimemos relativamente respecto este pivote.

   

   Equipo por favor miren a acá un momento y olviden que esta historia de usuario toma 3 días.

8. Se siguen estimando el resto de historias de usuario hasta que se se llega a la velocidad del sprint

Ventajas

• Se desvincula el concepto de días u horas a las estimaciones
• Los equipos encuentran mejores formas de interactuar y de resolver los problemas con el tiempo, por lo tanto con seguridad habrá aumento de velocidad y esta pantalla que en inicio tomaba 3 días es probable que al sexto sprint tome menos viendo la organización de forma tangible la mejora del equipo.

Desventajas

1. Se pierde el “control” basado en días
2. Los equipos no tienen velocidad estándar

Método 3: "Ojo de buen Cubero" o "nos comprometemos hasta aquí"

1. El equipo escucha las historias en orden, resuelven el qué y el cómo de cada una de ellas.
2. hasta un momento donde el equipo dice: "Somos capaces con estas historias, paremos el planning"

Ventajas

• Se desvincula el concepto de días u horas a las estimaciones
• Es necesaria la confianza en el equipo

Desventajas

1. Se pierde el “control” basado en días
2. Los equipos no tienen velocidad estándar

Concluyendo

De estos tres métodos sugiero más al método 2 (aunque por años usé el método 1) y con equipos maduros al método 3. Espero que este post les sea de ayuda en su primer planning,

Saludos ágiles

Jorge Abad




Importante: compartí un cuarto método en: Un Cuarto Método para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning (clic aquí)

Notas, referencias, comentarios y observaciones

1. Para la estimación de la velocidad o capacidad del segundo sprint se usa un concepto que se llama “el clima del dia anterior”, y se basa en la premisa si ayer hizo un clima es muy probable que hoy haga el mismo clima, si el sprint pasado hicimos 30 puntos es muy probable que estemos cercanos a ese puntaje, entre 25 y 35, ya es potestad del Equipo y del ScrumMaster si van más allá o nó. Lectura Recomendada Comprometiéndonos un poco más allá en el planning - clic aquí- )
2. Obvio es probable que entre una actividad y otra toque esperar un tiempo, pero nos estamos refiriendo solo a tiempo de trabajo y no se incluyen tiempos de espera)
3. Se sugiere en días, pues  de esa manera se amortiguan las malas estimaciones.
4. Lectura recomendada:Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad (clic aquí)
5. Libro recomendado: Scrum y XP desde las trincheras (clic aquí)

[Agenda Scrum] Pasos para Realizar un Planning

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para el Planning

Forma 1: A cada historia se estiman sus puntos y tareas a la vez

1. Preparar la reunión
2. El Scrum Master(SM) comparte el propósito de la reunión, timebox y los pasos a seguir
3. Se establecen las reglas y los acuerdos entre los asistentes para hacer efectiva la reunión
4. El Produt Owner(PO) comparte el objetivo del Sprint
5. El SM comparte la capacidad o velocidad del equipo en puntos (o en algun sistema equivalente) considerando la presencia o no de team members, o reuniones citadas.
6. El PO lee la historia de usuario
7. El equipo hace preguntas
8. El SM invita a que el equipo estima historia de usuario estimen en puntos (se puede usar la serie de Fibonacci u otra serie)
9. Con la facilitación del SM se llega a un acuerdo sobre cuantos puntos tiene la historia
10. Se identifican las tareas técnicas para realizar la historia de usuario (ej: crear tabla, crear pantalla, modificar SQL, armar webservice, probar, desplegar, etc)
11. (opcional) a las tareas se les asigna horas por parte del equipo llegando a acuerdos ayudados por el SM
12. Se valida si la capacidad del equipo es alcanzada en horas y en puntos por la historia de usuario estimada, si la respuesta es NO, se retorna al punto 6 con la siguiente historia de usuario
13. Si la capacidad en horas o puntos es alcanzada se finaliza el Planning
14. El SM comunica entonces:
1. Cual es el objetivo,o se actualiza con la retroalimentación de todos
2. las historias planeadas
3. las fechas para refinamiento, review, retrospectiva.
15. Se actualizan las herramientas de gestión

Forma 2: A todas las historias se les estiman sus puntos y luego sus tareas

1. Preparar la reunión
2. El Scrum Master(SM) comparte el propósito de la reunión, timebox y los pasos a seguir
3. Se establecen las reglas y los acuerdos entre los asistentes para hacer efectiva la reunión
4. El Produt Owner(PO) comparte el objetivo del Sprint
5. El SM comparte la capacidad o velocidad del equipo en puntos (o en algun sistema equivalente) considerando la presencia o no de team members, o reuniones citadas.
6. El PO lee la historia de usuario
7. El equipo hace preguntas
8. El SM invita a que el equipo estima historia de usuario estimen en puntos (se puede usar la serie de Fibonacci u otra serie)
9. Con la facilitación del SM se llega a un acuerdo sobre cuantos puntos tiene la historia
10. Se valida si la capacidad del equipo es alcanzada en puntos por la historia de usuario estimada, si la respuesta es NO, se retorna al punto 6 con la siguiente historia de usuario.
11. Si la capacidad  puntos es alcanzada se identifican las tareas técnicas para realizar todas historias de usuario (ej: crear tabla, crear pantalla, modificar SQL, armar webservice, probar, desplegar, etc)
12. (opcional) a las tareas se les asigna horas por parte del equipo llegando a acuerdos ayudados por el SM
13. Se valida que la capacidad en horas no sea superada, en caso de ser superada se informa que es requerido remover una historia de usuario al PO
14. El PO elige que historia no hace parte del sprint
15. El SM comunica entonces:
1. Cual es el objetivo,o se actualiza con la retroalimentación de todos
2. las historias planeadas
3. las fechas para refinamiento, review, retrospectiva.
16. Se actualizan las herramientas de gestión

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Notas, Referencias, Comentarios y Aclaraciones

1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo

Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad

Hola a todos
Muchas veces veo a los equipos, scrum masters y product owners enfrascados en discusiones sobre la puntuación de los ítemes de backlog y la forma de obtenerla, este no debe ser el foco (desde mi punto de vista)

Pongamos las cosas claras, según la guía lo más importante del sprint planning es definir el objetivo que se quiere lograr (o la capacidad de negocio que vamos a proporcionar con el trabajo de esas máximo 4 semanas - prefiero pensar que son 2 semanas, que es un tamaño más sano de sprint - ), en segundo lugar tenemos:

• qué vamos a hacer
• cómo lo vamos a hacer

Ese ¿qué? tiene como entrada clave la pregunta

¿que capacidad tenemos?,

basado en esta pregunta el equipo determinará a cuantos ítemes de backlog se compromenten.

Si los ítemes de backlog (historias de usuario, casos de uso, requisitos en prossa o lo que sea) se estiman en:

• Días productivos (un punto = 1 dia productivo)
• basados en una funcionalidad pivote ( 1 punto = la construcción de una funcionalidad pequeña que agrega valor)
• basado en cantidad de historias de usuario (´por ejemplo: somos capaces con 6 historias de usuario en promedio por sprint)
• en ojo de buen cubero (creemos que somos capaces de hacer esta cantidad de historias, por que una vocecita interior nos lo dice), o
• en Garrapatandamandapispuntos, donde un Garrapatandamandapispunto equivale a 3 escaramanditabitas

Es perfecto, pues llega un momento donde el equipo dice (independiente del método que elijan):

!No más¡, creemos que somos capaces de hacer hasta acá en este sprint.

Se que es dificil soltar nuestro afán de medir, pero dada la incertidumbre que tiene asociado el software ¿qué ganamos con ser más precisos?, ¿gastar más tiempo en estimaciones que igual van a fracasar?

Hasta acá esta pequeña reflexión

Saludos Ágiles
Jorge Abad

¿Cuántas historias por Sprint?

Hola a todos

Obvio en esto no hay reglas,  pero si recomendaciones. 

He  notado que por Sprint es bueno tener entre 6 y 10 historias de usuario,  ojalá todas de tamaño similar, parecido o entre el mismo rango.

Esto permitirá un flujo regular del equipo a lo largo del Sprint.

Pocas historias muy grandes hará  que cueste mucho lograr el ¡DONE!  Y posiblemente hayan historias que no se logren.  RECOMENDACIÓN: realizar división de historias.

Muchas historias muy pequeñas dan la sensación de demasiado trabajo a realizar en el Sprint, un tablero atiburrado de tareas por hacer. RECOMENDACIÓN: fusionar historias.

Atento a sus comentarios y experiencias

Saludos ágiles

Jorge Abad

Leído y Recomendado: La Definición de “Ready” es tan importante como la Definición de “Done”

Excelente artículo de Johnny Ordoñez

https://johnnyordonez.wordpress.com/2014/12/12/la-definicion-de-ready/

De colección, super-recomendado

Lo copio para tener registro...

_____

La Definición de “Ready” es tan importante como la Definición de “Done”

DECEMBER 12, 2014 / JOHNNY ORDÓÑEZ

Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie

Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de “Hecho” (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra “Hecha” para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.

Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y “Done Done” o “Accepted” cuando ha sido revisada y “firmada” por el Product Owner.

Varios agilistas sugieren  lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la “Definición de Listo”.

La Definición de “Ready” o DoR

Análoga a la Definición de “Hecho”, la definición de “Listo” es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.

¿Por qué es importante?

Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior,  el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.

Bob Galen habla mucho del “Readiness Criteria” en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):

• Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
• Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
• Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
• De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
• Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
• Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
• Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
• Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.

Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su “olfato” para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):

• Sprint plannings más rápidos;
• Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente;
• Gestión colaborativa del backlog;
• Feedback temprano;
• Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
• Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
• Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
• Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.

Pensamientos finales

Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.

Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.

Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.

Gracias, y que la agilidad esté con Ustedes.

Johnny

La cara del santo hace el milagro. Efectividad del Planning y Review

Scrum tiene muchas fortalezas, esta cubierto de soluciones para años y años de heridas de guerra de equipos de software a lo ancho y largo del mundo, cada elemento esta puesto allí ayudando a que los otros funcionen.

Una de las cosas que he observado es la fortaleza que tienen el Planning y el Review, y el milagro que logra en el equipo:

• En el Planning: El Team Developer con el P.O. (Product Owner - Dueño del Producto), entiende que se quiere construir y se compromete con unos ítemes de backlog que llevará a la DoD (Definition of Done -  Definición de terminado). La clave acá es que al equipo nadie le impone el compromiso, es un acto de libertad, coraje y confianza en si mismos -un consenso libre entre sus integrantes -. En el esquema tradicional hay un GP (Gerente de Proyecto) que le impone unos tiempos y estimaciones a su equipo, sin otra opción que cumplir o cumplir , ya sea en el tiempo asignado o en el propio después de la jornada laboral.
• En el Review: El Team le presenta al P.O. y a los Interesados* lo construido, y pasan a la gloria, a una ligera vergüenza si algo no sale como lo esperado, o una "humillación" sino cumplieron con poco o nada de lo comprometido (con su respectiva DoD). El que siente la frustración o felicidad es el equipo al mostrar el resultado a sus directos interesados (sin intermediarios o gerentes que cuenten el "chisme" de la típica pregunta ¿como les fue en la entrega?) La cara del P.O. y los Interesados es lo que más compromete y le da propósito a un equipo. 

El equipo toma poco a poco vida, reflexiona para si mismo y dice:

• tenemos que seguir dando la talla o
• no nos puede volver a pasar esta misma situación

(esta puesta la semilla para la retrospectiva)

El milagro del compromiso, coraje, foco y auto-organización poco a poco comienzan a emerger y ahí es cuando yo digo como el famoso dicho:

La cara del santo** hace el milagro

Saludos ágiles

Jorge Abad.

* Interesados: Puede ser los líderes funcionales de los clientes, usuarios, o cualquier persona que le importe en obtener un buen producto
** P.O. + Interesados

Scrum: La Reunión de REFINAMIENTO, clave para reducir Riesgos y reducir tiempo del Sprint Planning

El refinamiento aunque no es una de las reuniones oficiales de Scrum [1], si se dice que el 10% del sprint debería dedicarse a esta actividad.

Dice la guia [1]:

"El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle, estimaciones y
orden a los elementos de la Lista de Producto. Se trata de un proceso continuo, en el cual el
Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos
de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan 
sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente 
consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos
de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a
criterio suyo."

Bajo este escenario la duración de la reunión de refinamiento debería ser:

	Duración máxima de la reunión en horas
Tamaño del Sprint	1 Semana	2 Semanas	3 Semanas	4 Semanas
Refinamiento	1	2	3	4

Si lo miramos bien toma un tiempo considerable del sprint (aunque he experimentado en sprints de 2 que semanas 4 horas son suficientes),  tal vez se haga en una sola sesión o en varias según el caso, pero una de las ideas claves de scrum es:

"tengamos las reuniones suficientes de manera que no sea necesario hacer más reuniones, y podamos enfocarnos en lo que nos gusta, la construcción del producto."

.

Lo cierto es que esta actividad tiene grandes beneficios tanto para el sprint que viene, como para la construcción del producto.

Esta reunión (no-oficial) de scrum tiene como objetivo, presentar los próximos ítemes de backlog al equipo que van a entrar tanto para el siguiente sprint como para los 2 o tres próximos y discutir aspectos sobre ellos. Una de las agendas que he empleado en los refinamientos es la siguiente:

1. Lectura y estimación de las historias de usuario que posiblemente entran en el PRÓXIMO SPRINT. Se leen las historias de usuario con sus criterios de aceptación, se realiza la conversación, entendimiento y ajuste sobre las mismas.
2. Lectura de historias de usuario (no al detalle, solo el título de las mismas) que entrarán en los próximos  2 ó 3 sprints
3. En equipo se identifican los insumos requeridos para estas historias tanto desde el punto de vista de conocimiento como de entes externos al equipo (otras áreas, otros proveedores, etc)
4. En equipo se identifican los riesgos que pueden hacer que esas historias no se completen y se identifican actividades a realizar para mitigarlos.

De este manera:

• El Scrum Master y el Product Owner (y en ocasiones el Team Develper) comienzan a trabajar conjuntamente en la resolución previa de:
• riesgos
• insumos 
• e impedimentos
• El equipo conoce que viene para el próximo sprint
• El planning es una reunión mas liviana donde se presentan los aspectos modificados o afinados de las historias de usuario y algún cambio en la priorización.
• Todo el Equipo Scrum (Product Owner, Scrum Master, Team Developer) van observando como se va construyendo la visión del producto y se pueden alinear desviaciones.

Saludos ágiles

Jorge Abad.

Referencias

[1]Scrum Guides - https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100