sábado, 22 de abril de 2017

¿Cómo afecta la agilidad a la percepción del mundo?

Resaltar los círculos bien trazados dará visión de lo que
queremos y hará que los demás mejoren con el tiempo
Oí una afirmación que me hizo pensar: "El ser humano parece que nunca esté contento". Javier, un alumno de uno de mis cursos de Scrum, cuando hablé de que hemos de reaprender a recibir feedback, me invitó a leer sobre el método del bolígrafo verde que quiere promover el refuerzo positivo en los niños. Allí descubrí la razón de la afirmación: según la autora del método "las insatisfacciones que sufrimos en la vida están provocadas por la costumbre de resaltar los errores y no los aciertos".

Para ser coach ágil hay que tener la mentalidad de coaching adecuada, recordemos que hemos de estar convencidos y creer que el coachee, quién recibe el coaching, sabe más sobre su realidad y por tanto sus opciones, riesgos y la solución a sus problemas que nadie. Y que el coach ha de considerar que lo que haya hecho el coachee lo ha hecho con la mejor intención y con el mejor uso de sus conocimientos en esas circunstancias". En definitiva hemos de creer en las personas.

Esta mentalidad ha ido calando muy fuertemente en mi, es muy potente y agradecido ver como hago emerger el talento y la motivación en las personas, y eso sin duda ha cambiado mi perspectiva del mundo. En una ocasión un director de TI me dijo que ¡¡¡me veía demasiado feliz!!! Me quedé sin palabras unos segundos, no hubiera esperado nunca una frase así. Simplemente le dije que si no me veían feliz nadie creería en el cambio de forma de trabajo que yo traía como Scrum Master. En otra ocasión, cuando hablaba de dar confianza y valor a las personas, otro mando intermedio me dijo que no podemos basarnos en el buenismo... me sonreí para mis adentros y pensé, "¿Qué? ¿Nos basamos en el malismo para alcanzar proyectos exitosos y una empresa mejor? ¿Matamos toda creatividad para seguir siendo una empresa que sigue la estela de otras?".

Lo más interesante del método del bolígrafo verde es que al reforzar los aciertos, y no prestar atención a los errores, estos últimos acaban desapareciendo de forma natural. Si ponemos el foco en las cosas bien hechas, como por ejemplo las entregas en las revisiones de sprint, creamos una cultura de confianza en la que no haya miedo al fracaso, tomamos nuestros errores como oportunidad de aprendizaje y nos basamos en ciclos cortos como son los sprints, haremos evolucionar y mejoraremos nuestra compañía, vida profesional e incluso nuestra vida personal de forma continua.

Recordemos que el fracaso no es otra cosa que el esfuerzo mal dirigido, una oportunidad para levantarse, aprender y crecer. Quién no fracasa y siempre hace las cosas "bien" probablemente no haya corrido riesgos y por tanto haya quedado estancado en su mediocridad. La humanidad ha aprendido y evolucionado a base de prueba-error, y cuanto más cortos los ciclos, más rápido el aprendizaje y menor el dolor.

Definitivamente la mentalidad ágil se ha instalado en mi ADN y me siento apóstol del buenismo, definitivamente creo en las personas y sus interacciones... y eso impregna fuertemente mi perspectiva del mundo.

Soy humano y el miedo al cambio forma parte de mi naturaleza, pero sé que todo cambio tiene muchas probabilidades de ser a mejor y que a base de cambios todo evoluciona. Quizá no sepamos de antemano a donde vamos, pero si a lo largo del camino nos adaptamos y cambiamos a lo que nos hace más felices, viviremos una vida mas llena y feliz. No olvidemos que la vida no es otra cosa que un camino... para ir en la dirección correcta creemos nuestra pila de producto personal y disfrutemos de cada historia que vayamos viviendo :-D
Una "pila de producto" llena de buenos deseos y sentimiento en una heladería en Barcelona :-)

miércoles, 5 de abril de 2017

¿Qué pruebas automatizar y cuáles no desde la perspectiva ágil?

Cuadrantes Agile Testing - Gracias Marisa
Mi compañera Marisa ha presentado recientemente la matriz Agile Testing Quadrants desarrollado por Lisa Crispin y Janet Gregory, que está compuesta por 4 cuadrantes que ayudan a decidir cuando y dónde aplicar pruebas automatizadas.

Q1 - Pruebas dirigidas a tecnología que dan apoyo a los equipos de desarrollo, son pruebas que aconsejan automatizar. Son pruebas de integración a nivel de:
  • Pruebas unitarias: casos de prueba para cada función no trivial o método en el módulo, de forma que cada caso sea independiente del resto
  • Pruebas de componentes: pruebas unitarias a nivel de componentes, un conjunto de servicios o funcionalidades a través de interfaces definidas
Q2 - Pruebas dirigidas a negocio que dan apoyo a los equipos de desarrollo, son pruebas que aconsejan automatizar en la medida de lo posible, la parte no automatizable se hará manualmente. Engloban a grandes rasgos las:
  • Pruebas funcionales: basadas en la ejecución, revisión y retroalimentación de las historias de usuario previamente diseñadas
  • Ejemplos, pruebas de historia, prototipos, simulaciones
Q3 - Pruebas dirigidas a negocio y críticas para el producto, pruebas que requieren conocimiento del producto y negocio y por tanto aconsejan que sean manuales:
  • Pruebas exploratorias: se diseñan "al vuelo" casos de prueba que se ejecutan a la vez que se aprende sobre el sistema
  • Pruebas de aceptación de usuario: están enfocadas en las necesidades del usuario, sus requerimientos y procesos de negocio, determinan si el sistema satisface los criterios de aceptación de Propietario del Producto y usuarios
  • Escenarios, pruebas de usabilidad, alfa/beta
Q4 - Pruebas dirigidas a tecnología y críticas para el producto, pruebas sobre requerimientos no funcionales que aconsejan ejecutar con herramientas diseñadas a tal efecto.
  • Pruebas de rendimiento: para determinar si los tiempos en el sistema realiza una tarea en condiciones particulares de trabajo son adecuados
  • Pruebas de seguridad: miden la confidencialidad, integridad y disponibilidad de los datos desde la perspectiva del sistema
  • Mantenibilidad, escalabilidad...

lunes, 3 de abril de 2017

¿Como hacer una Kata TDD en una simulación de Scrum?

Mi compañera Marisa y yo hemos ideado una simulación basada en la Kata Test Driven Development (TDD): Example Walkthrough de Viktor Farcic. Combina la Kata con una simulación de Scrum.

En la fase preparatoria se constituyen los diferentes equipos del ejercicio, recomendable de 3 a 4 miembros, y cada uno de ellos prepara su tablero. Los equipos se forman por mesas y es muy aconsejable equilibrar el conocimiento, que el expertise esté balanceado y haya expertos de java en cada uno de ellos. El tablero debe de tener el diseño de la imagen que sigue y el equipo lo cuelga cerca de su mesa. Para cada requisito del ejercicio han de prepara un post-it y colocarlo en la columna "Pila de producto".
Tablero para la Kata TDD con Scrum
La simulación trata de hacer 3 sprints, con todas sus reuniones, para que el equipo desarrolle la calculadora descrita en el ejercicio de la Kata. El trainer o profesor hace de Propietario del Producto para resolver dudas del ejercicio. El ciclo de reuniones será como sigue:
  • 5 minutos para la planificación de sprint: el equipo decide donde hacer el corte en la pila de producto y llevarse los post-its correspondientes a la columna de "Pendiente". Cada post-it lo han de marcar con el sprint para el que ha sido planificado, así podremos ver el sprint para el que estaba previsto cada requisito y el sprint en el que se ha completado.
  • 25 minutos de construcción en los que el equipo construye la calculadora en base a los requisitos. ¡Atención! El equipo ha de construir los requisitos en el orden del ejercicio y de uno en uno, y lo hace ante un solo ordenador a modo de mob programming, lo que implica que cada 5 minutos aproximadamente el teclado rota de miembro. Los requisitos finalizados pasan de la columna "En curso" al área correspondiente al sprint en la columna "Hecho". ¡Atención! Un requisito no está finalizado sin la correspondiente refactorización.
  • Para la revisión de sprint se lleva el workspace a un ordenador con proyector, usualmente el del profesor, y cada equipo hace la demo de lo que han construido ante los demás equipos que actúan a modo de interesados.
  • Finalmente 5 minutos para una retrospectiva en la que cada equipo busca una sola acción de mejora para el siguiente sprint.
Evolución de los tableros a lo largo de los 3 sprints de la Kata con los alumnos del CSD de marzo de 2017
Las instrucciones de la Kata TDD que siguen son la traducción del post Test Driven Development (TDD): Example Walkthrough de Viktor Farcic. Tanto en su post como al final de este, en el área de descargas, se pueden ver las soluciones a cada uno de los requisitos.

Ciclo TDD
El proceso TDD descansa en una forma de desarrollo que depende de la repetición de un ciclo muy corto. Primero el programador escribe un caso de prueba, que verifica una funcionalidad, y después escribe la cantidad de código mínima necesaria para pasar ese caso de prueba. Finalmente refactoriza el código para que sea un código que cumpla estándares de calidad.

Los pasos que se siguen son:
  • Crear la prueba
  • Ejecutarla y comprobar que falla
  • Escribir código que pase la prueba
  • Refactorizar el código
  • Repetir esto hasta obtener el código con el nivel de calidad deseado
Seguido mostramos el enunciado de cada requisito/iteración del ciclo TDD. Se debe de leer cada requisito e intentar buscar una solución. Tengamos en cuenta que la forma de probar e implementar no es única, por lo tanto hay más de una posible solución.

El ejercicio trata de crear una calculadora que sea capaz de sumar los números que hay en una cadena de caracteres con el método sumar(String números) con la siguiente funcionalidad:
  • El método puede recibir 0, 1 o 2 números y devolverá su suma. Por ejemplo son válidas las cadenas "", "1" o "1,2". Para la cadena vacía debe devolver un 0.
  • Permitir que el método maneje una cantidad de números ilimitada.
  • Permitir que para separar los números venga un salto de línea marcado por una "n" en vez de una coma. Por ejemplo la cadena "1n2,3" es válida y debe devolver un 6.
  • Permitir distintos delimitadores. Para cambiar el delimitador empezar con una cadena que contenga el delimitador de la siguiente manera "//[delimitador]\n[números…]". Por ejemplo: "//;\n1;2" debe de devolver un 3.
  • Todos los escenarios deben ser soportados. Es decir, delimitador coma, delimitador salto de línea y delimitador cambiado.
  • Si se invoca al método sumar con números negativos, este debe lanzar una excepción "los negativos no están permitidos" y mostrar los números negativos erróneos.
  • Los números mayores de 1000 se deben de ignorar, de forma que 2+1001=2.
Requisito 1: El método sumar puede aceptar 0, 1 o 2 números separados por una coma:
  1. Escribir un caso de prueba que compruebe: si se reciben más de 2 números la función lance una excepción, si se reciben 2 números devuelva true y si se recibe una cadena que contiene un carácter no numérico lance una excepción.
  2. Escribir la función sumar que sea capaz de superar estos 3 casos de prueba.
 Requisito 2: Para la cadena vacía el método devolverá 0:
  1. Escribir un caso de prueba que compruebe que cuando se invoca el método sumar con la cadena vacía devuelve un 0.
  2. Modificar el método sumar para que devuelva 0.
Requisito 3: El método devolverá la suma de números:
  1. Añadir los casos de prueba para comprobar que el método sumar es capaz de devolver un número cuando es invocado con un número, o de sumar dos números cuando es invocado con 2 números.
  2. Modificar el método sumar para que o devuelva un número o sume dos.
Requisito 4: Permitir que el método sumar maneje una cantidad indefinida de números:
  1. Añadir un caso de prueba para comprobar que el método sumar es capaz de sumar por ejemplo los números 3+6+15+18+46+33. Ojo hay que quitar el caso de prueba que comprueba que si se envían más de dos números se lanza una excepción.
  2. Modificar el métodos sumar para que pueda sumar estos números. Ojo, hay que quitar la excepción que devuelve cuando recibe más de 2 números.
Requisito 5: Permitir que el método sumar maneje saltos de línea entre los números, además de comas:
  1. Añadir el caso de prueba que compruebe que un salto de línea (n) se acepta como separador de números dentro de la cadena.
  2. Modificar el método sumar para que tenga en cuenta que el delimitador puede ser una coma o una n.
Requisito 6: Permitir el uso de distintos delimitadores:
Para cambiar el delimitador, al principio de la cadena se incluirá de lo siguiente "//[delimitador]\n[numeros…]" por ejemplo "//;\n1;2" debería ser tomado como los números 1 y 2 separados por el delimitador ";".
  1. Incluir un caso de prueba para comprobar que cuando se envía la cadena "//;\n1;2", el resultado de la suma es 3.
  2. Modificar el método sumar para que contemple este caso. El resto de los casos deben seguir funcionando.
Esta vez hay un montón de código que refactorizar. Partimos el código en 2 métodos. El método inicial analiza la cadena buscando el delimitador y después llama al método sumar con los parámetros cadena y delimitador para que sume los números. Como disponemos de módulos de prueba para comprobar que todo sigue funcionando, no hay problema con todos estos cambios (refactorización). Si algo va mal los test encontrarán el problema.

Requisito 7: Si hay números negativos se lanzará una excepción:
Llamar al método sumar con un número negativo lanzará una excepción "los números negativos no están permitidos" y se mostrarán los números negativos enviados en el mensaje.
  1. Incluir un caso de prueba para probar que para la cadena ("3,-6,15,-18,46,33"), se lanza una excepción en la que en el mensaje se incluyen los números -6 y -18. 
  2. Modificar la calculadora para que lance la excepción en el caso de que la cadena contenga números negativos.
Requisito 8: Los números más grandes que 1000 deberían ser ignorados:
Por ejemplo: sumar 2 + 1001 = 2.
  1. Incluir un caso de prueba para comprobar que los números mayores de 1000 no se suman
  2. Modificar el método sumar para que no sume los números mayores de 1000.
Dale una oportunidad a TDD

A menudo a los principiantes en TDD el proceso les parece apabullante. Una de las quejas más comunes es que TDD relentece el proceso de desarrollo. Esto es cierto al principio, toma un tiempo hacer las cosas de esta nueva forma y coger velocidad, sin embargo después de un poco de práctica el proceso acaba ahorrando tiempo de desarrollo, consigue mejores diseños, fuerza la refactorización, incrementa la calidad y la cobertura de código y asegura que el software está probado. Otro gran beneficio es que los test son documentación sobre lo codificado, y de esta forma la documentación siempre está actualizada.

TDD provoca que el programador se centre en su tarea, codificando solo aquello que es necesario. Además en último término hace que los programadores hagan mejor su trabajo.

Descargas / Downloads
Mis agradecimientos a Viktor Farcic por su post original y a Marisa por la traducción y la facilitación del ejercicio.

domingo, 2 de abril de 2017

¿Existe alguna retrospectiva de alineamiento basada equipos que califican sus habilidades?

Tablero de ejemplo de la retrospectiva, en rojo dos puntos a tratar
En este post quiero presentar una dinámica de retrospectiva que podría responder a la pregunta: ¿estamos en la misma onda?

Los equipos califican sus habilidades en diferentes categorías en un gráfico de araña para que finalmente discutan sobre el resultado. Se trata de la retrospectiva de telaraña de Brian Marick, una retrospectiva concebida para equipos ya integrados y comunicativos. Tiene la ventaja de ser muy visual y hacer emergen malentendidos rápidamente.

El Scrum Master prepara el tablero y explica mediante una descripción inicial y clara el significado de cada una de las categorías, es muy importante establecer un entendimiento común antes de proceder. Las categorías que propongo son:
Cada categoría la marca con 5 rayas perpendiculares, rayas que representan una escala del 1 al 5 desde el centro al exterior. Se le pide entonces a cada miembro del equipo que marque en cada categoría con una X lo que cree que fue el último sprint: 1 = muy poco y 5 = muchísimo de la categoría. 

Finalmente, ante el tablero completado, el equipo analiza el resultado obtenido:
  • Observando aquellas categorías que tienen las marcas mas cercanas al centro, como el (1) en el tablero de ejemplo.
  • Aquellas en que los valores de diferentes miembros distan mucho entre si, señal de posibles malentendidos dentro del equipo, como el (2) en el tablero de ejemplo.
La discusión que emerge sirve para abrir las puertas a posibles áreas de mejora, que de otro modo podrían escaparse a la consideración del equipo.

sábado, 1 de abril de 2017

¿Hay definiciones de hecho (DoD) a diferentes niveles?

Los 4 niveles donde aplica DoD
La definición de hecho, DoD (Definition of Done), es un convenido del equipo y el Propietario del Producto en forma de una simple lista de criterios y actividades que agregan valor verificable y demostrable al producto.

DoD es aplicable a nivel de tarea, historia de usuario, sprint y release, e incluye los criterios y actividades necesarias para dar por terminado cada uno de los elementos.

Tarea:
  • Implementada
  • El código escrito cumple estilos y directrices
  • Hechas las pruebas unitarias
  • Integrada en el repositorio
  • Integra con el resto en el build
  • Gestor de tareas actualizado
  • Satisfechas ciertas métricas: cobertura, análisis estático, etc.
  • Tarea aprobada por el tester
  • Todas las tareas asociadas están hechas
  • Las incidencias detectadas en fase de desarrollo están resueltas
  • El código está documentado y/o comentado
  • La documentación y otros requisitos que requiere el proyecto/producto están hechos
  • La historia satisface los criterios de aceptación
  • Hechas las pruebas de integración
  • La historia ha pasado las pruebas unitarias acumuladas y de aceptación de forma manual o automática
  • Comprobada si sigue los estándares de ingeniería/arquitectura
  • Cumple con los requerimientos no funcionales
  • La historia está instalada en un entorno tipo test, staging o preproducción y pasó las pruebas de humo
  • Historia de usuario aprobada por el Propietario del Producto
  • Todas las historias planificadas están hechas
  • Medios de distribución están producidos
  • Comprobada la documentación de usuario
  • Cumple con los requerimientos no funcionales y estándares
  • Hechas las instrucciones de instalación/despliegue de la release
  • Hechas pruebas de seguridad, despliegue y regresión
  • Resueltas todas incidencias criticas y de resolución necesaria para despliegue
  • Comunicados de release y formación a usuarios hecha
  • Release aprobada por el Propietario del Producto

domingo, 26 de marzo de 2017

¿Hay algún juego que permita experimentar un sistema de arrastre versus empuje?

En mis cursos de Kanban hacemos un taller de construcción de aviones de papel que hace experimentar a los alumnos la gran diferencia de aplicar un sistema de arrastre respecto a un sistema de empuje. Para ello uso el Pull Systems, Push Systems: The Paper Airplane Game de Shmula y en este post quiero mostrar mi experiencia.
Diseño de la línea de montaje, muchas gracias Shmula
El taller consiste en dos vueltas de 5 minutos para la construcción aviones de papel, la primera con un sistema de empuje y la segunda con un sistema de arrastre.

Primero han de constituirse los grupos de trabajo, cada uno de 6 participantes. Les invito a buscar un nombre para el equipo y autoasignarse los roles de manera que haya 4 trabajadores, 1 encargado de calidad y 1 encargado para medir tiempos.

La primera vuelta, que hace experimentar el sistema de empuje o push, trata de seguir las instrucciones de cada una de las estapas de la línea de montaje (siguiente imagen) y trabajar a un ritmo confortable tratando de producir lo más rápido posible. Antes de empezar se coloca una unidad de producto parcialmente terminado en cada área entre etapas. El facilitador o trainer cronometra el tiempo de construcción de 5 minutos.
Instrucciones para las 4 estapas de la línea de montaje, muchas gracias Shmula
El encargado de calidad prueba cada uno de los aviones que llegan al final de la línea, aprueba los que vuelan bien y rechaza (archiva en una papelera) los que no cumplan con un mínimo.

Estaciones con aviones en curso y el
área de calidad con aviones OK y KO
El encargado para medir tiempos anota el tiempo de ciclo de una muestra de aviones, una buena opción es que este marque un avión antes de la primera etapa, o introduzca una hoja de color para distinguir el avión, y haga las mediciones cuando este llegue al área de calidad. También anota el WIP total, cantidad de aviones en curso que hay en la mesa. Finalmente hace el promedio del tiempo de ciclo que registra en el tablero.  

La segunda vuelta hace experimentar el sistema arrastre o pull. Se introduce una simple regla, un trabajador no puede hacer su trabajo, y debe esperar, si el área entre él y la estación que tiene a continuación no está vacía, regla que convierte el sistema en un sistema de arrastre. Igual que en la primera vuelta se coloca una unidad de producto parcialmente terminado en cada área entre etapas y se toman las mismas métricas.

Las métricas recogidas se anotan en un tablero compartido, en el que cada columna muestra los datos de un equipo en particular. El facilitador o trainer se sitúa ante el tablero y efectúa una serie de preguntas con el objetivo de generar debate y reflexión entre los participantes:
  • ¿Por qué el tiempo de ciclo es inferior en el sistema de arrastre que en el sistema de empuje?
  • ¿Por qué hay menos WIP en el sistema de arrastre que en el de empuje?
  • ¿Es mejor poco WIP o mucho?
  • ¿Dónde estaba el cuello de botella?
  • ¿Qué sistema es mejor: el de empuje o el de arrastre?
  • Para las estaciones 1 y 2, ¿Qué tiempo habéis pasado desocupados en un sistema y en el otro? ¿Debería eliminarse ese tiempo muerto?
Una de las sorpresas usuales entre los participantes es cuando ven que con en sistema de arrastre han construido más aviones, su impresión suele ser exactamente al revés, casi no se lo creen, cuentan que con empuje no paraban de trabajar y tenían la sensación de haber construido mucho aviones. Con el sistema de arrastre las cosas ocurren con ritmo y con un espacio correctos, trabajamos de forma más ordenada y efectivamente somos más productivos.

Cuando les pregunto a los participantes por como han vivido las dos vueltas, la mayoría cuenta que en la primera vuelta estuvieron focalizados en su tarea, en trabajar y trabajar, y que en la segunda vuelta fueron conscientes del proceso completo y se sentían parte del todo. Ese aire que nos da el límite de WIP, cuando no podemos trabajar mientras el área hasta la siguiente etapa no esté vacía, hace que tengamos visibilidad sobre toda la línea de montaje y que nos sintamos parte del todo.

En el sistema de arrastre los participantes son conscientes del cuello de botella que representa la estación número 3, y que se produce por el hecho de tener que dibujar una estrella. En ocasiones algún grupo incorpora de forma espontanea alguna mejora, como por ejemplo la decisión de las estaciones colindantes, la 2 y la 4, de ayudar a la 3.

Algunos participantes hablan de haber "sobrevivido" al sistema de empuje y de haber "vivido" el sistema de arrastre.
Fiesta final de lanzamiento de todos los aviones construidos :-)
Agradecimientos a mis alumnos del curso de noviembre de 2016

domingo, 19 de marzo de 2017

¿Cómo estimar rápidamente una pila de producto nueva con tallas de camisa?

Pared para estimación de Elefante Blanco
Hay muchas técnicas que se pueden utilizar para estimar a alto nivel una pila de producto. En este post quiero presentar la que se denomina El Elefante Blanco y que es a la vez simple y muy efectiva.

El equipo se sitúa en forma de semicírculo frente a un tablero o una pared, con cartas de tallas de camisa como cabecera de columnas. El moderador, usualmente el Scrum Master, mezcla el conjunto de historias de usuario y las pone boca abajo en una mesa frente a todos ellos. La dinámica requiere un reloj o cronómetro para medir el tiempo para cada turno, usualmente de entre 30 y 60 segundos.

La dinámica se pone en marcha en cuanto el moderador inicia el cronómetro, es la señal para que el primer miembro lleve adelante los siguientes pasos:
  • 1. Elegir una historia de la mesa
  • 2. Leer la historia en voz alta
  • 3. Colocar la historia en una de las columnas definidas en la pared (XS, S, M, L, XL)
  • 4. Explicar al equipo porqué elige una columna en concreto
  • 5. Reiniciar el cronómetro para el siguiente miembro
La decisión de en qué columna colocar la historia ha de ser propia del miembro que le toca el turno, no debe de haber ninguna interferencia externa. Puede hacer preguntas al Propietario del Producto, pero no debe de discutir la estimación con sus compañeros. Si el miembro no asigna la historia en el tiempo establecido para el cronómetro, entonces la historia será colocada en la columna del medio.

La introducción de una sola historia a la vez ayuda a limitar la incertidumbre. El primer participante no tiene que considerarlo todo, sólo tiene que considerar una historia. La complejidad aumenta a medida que se añaden más historias, pero el trabajo de los participantes previos ayuda a construir "andamios" que ayudan a tomar la decisión.

Una vez estimada la historia, el participante del turno explica las razones basadas en su conocimiento de experiencias pasadas u observaciones que le han llevado a colocarla en la columna determinada. Es esencial que el resto del equipo observe y escuche atentamente, sin intervenir, para comprender la totalidad del contexto y la situación de la historia

Después de un par de interacciones todas las historias de usuario habrán sido colocadas en la pared, a partir de ese momento los participantes pueden mover una historia existente de una columna a otra. En ese caso el miembro de equipo lee de nuevo la historia y explica la razón por la cual cree que se debe de reestimar su tamaño y colocarla en otra columna.

Si el participante estuviera satisfecho con las estimaciones simplemente ha de indicar que desea ser saltado diciendo "salto". Si una persona no toma la decisión dentro del tiempo establecido entonces se interpretará como que desea ser saltada. La dinámica finaliza cuando la pila producto haya sido estimada completamente y todos los miembros indican que desean ser saltados.