¿Cómo se mide el valor de las historias de usuario?

Con cada sprint aumenta el valor de negocio del producto

La información "valor" representa el valor de negocio que aporta una historia de usuario una vez realizada, es una información más profunda que la razón de la historia misma ya que está íntimamente ligada a la lógica de negocio. ¿Pero qué mide esa información? Podríamos decir, hablando en plata, que representa "cuánto dinero está dispuesto a pagar nuestro cliente por esa funcionalidad". Cuanto más esté dispuesto a pagar, más valor de negocio tiene. Tal como funcionan Scrum y la Agilidad entregar valor significa focalizarnos en resolver los problemas de alguien o en dar beneficios a alguien..

Adicionalmente quiero resaltar que hay historias que no tienen valor de negocio, por ejemplo una página de login, pero sin las cuales no se pueden construir las otras historias que si tienen valor. El valor de negocio es muy importante para priorizar correctamente, focaliza al equipo de desarrollo en todo momento en aquello que es prioritario construir y maximiza el valor y la satisfacción percibida por el cliente en cada sprint, pero no es lo único, hay dependencias y otros factores que pueden determinar la prioridad, es por ello por lo que valor y prioridad son dos informaciones independientes.

El valor se mide con una escala arbitraria (normalmente valores numéricos) que aporta la historia de usuario o epic al cliente o usuario. Ha de ser una escala con la que el Propietario del Producto y los usuarios de negocio se sientan cómodos, series  de números naturales del 1 al 10, del 1 al 100, del 1 a 1.000.000 o la serie de Fibonacci por ejemplo.

Billetes del Monopoly

Una forma que me parece muy estimulante y divertida es repartir billetes del Monopoly por el valor total del proyecto a cada uno de los usuarios de negocio involucrados, y que estos repartan el dinero en función del valor que le atribuyen a cada historia de usuario. Es un ejercicio que les acerca a la realidad, no les toca directamente el bolsillo pero lo simula muy bien. Finalmente el valor es la suma del los billetes de todos, opcionalmente se puede dividir el resultado por 100 o 1000 para que sea un número más manejable.

Benoît Pointet y Thomas Botton proponen en su artículo "Key Dimensions of User Stories" estimar el valor de la misma manera que el equipo estima el esfuerzo, mediante cartas de planning poker con la serie de Fibonacci. El valor, igual que el esfuerzo, es sumativo y relativo entre historias. La idea es que el Propietario del Producto y los expertos de negocio jueguen a planning poker, y de la misma manera que se crea una base de conocimiento en las reuniones del equipo, las reuniones para la estimación de valor crearán una base de conocimiento compartida para usuarios y gente de negocio.

Esta propuesta tiene dos efectos colaterales muy interesantes: trae respeto y comprensión del equipo hacia el Propietario del Producto, y, este último comprenderá más fácilmente porqué el equipo necesita en ocasiones reestimar ciertas historias de usuario.

¿Cómo evitar los post-its voladores que se desprenden de los tableros Kanban?

Post-its reforzados con celo sobre un whiteboard

Todos los que trabajamos con tableros físicos hemos sufrido la caída de algún post-it mientras poblamos el mismo en la planificación del sprint, o lo que es peor, en el momento en que hemos acabado el tablero y lo mostramos en todo su esplendor, va y se despega un post-it, y medio fastidiados medio divertidos observamos como cae burlón y suavemente y aterriza en el suelo sin más. Y luego están las caídas que nadie ve y que luego no siempre sabemos de dónde provenía... o cuando alguien ajeno al proyecto pasa cerca y con el movimiento del aire provoca alguna caída y furtivo coloca los post-its caídos rápidamente en dónde mejor le parece...

Tablero de corcho con
post-its reforzados con chinchetas

Convivimos con ello como un mal menor y a alguien se le ocurre el paliativo de hacer una foto de backup cada día antes de fin de jornada, foto que sirve para detectar al día siguiente si ha habido algún incidente en el transcurso de la noche. 

Pronto aparecen soluciones alternativas como por ejemplo utilizar celo para fijar los post-its. El resultado es una mejor fijación, pero eso hace más laborioso moverlos, hay que ir con cuidado para despegar el celo que puede doblarse y autopegarse antes de llegar al destino. Además el pegamento del celo deja rastro en el tablero whiteboard y va deteriorando la calidad del mismo.

Algunos decidimos probar con tableros de corcho y fijar los post-its con chinchetas. Es una solución, pero perdemos el potencial y la flexibilidad de los rotuladores para pintar sobre el tablero. Podemos marcar las líneas con cinta de carretero y para las etiquetas y el gráfico burndown utilizar trozos de papel fijados también con chinchetas, pero la facilidad de uso se ve muy mermada.

Post-its fijados con imanes

Volvimos al tablero whiteboard, esta vez lo buscamos magnético y fijamos los post-its con imanes. Funciona, pero siempre ocurre que hay más post-its que imanes... Además, resulta que los imanes son muy útiles para otras funciones, por ejemplo un imán rojo en un post-it puede indicar que la tarea está bloqueada. Es una solución pero perdemos otras posibilidades que harían que nuestro tablero fuera aún más funcional y ágil.

La mejor solución que hemos encontrado son los post-its super sticky. Hay varios fabricantes, nosotros hemos probado las Notas Post-it® Super Sticky de 3M de máxima adhesión. En la página del producto podemos leer entre otros beneficios:

• Permanecen pegadas más firmes y por más tiempo
• El adhesivo súper fuerte hace que permanezcan pegadas de forma aún más segura que las Notas Post-it® originales
• Las Notas Post-it® Super Sticky son súper fuertes, súper versátiles y súper llamativas

Para ilustrar lo fuerte que fijan hemos probado pegar uno a una superficie de cristal, practicarle un agujero y colgarle una tijera grande. El post-it super sticky ha soportado la tijera sin novedad durante media hora, hasta cuando dimos la prueba como ampliamente superada.

Post-its super sticky pegado en una superficie de cristal
aguantando el peso de una tijera de cocina

Michael Arrighi describe en un artículo su técnica CPT (Correct Post-it Technique) para conseguir una buena fijación. La clave está en como arrancamos el post-it del bloc, hay que hacerlo de lado, nunca de abajo a arriba. 

Como arrancar correctamente los post-its del bloc

Para determinar si los post-its son buenos y si los hemos fijado correctamente simplemente hay que quitar un post-it del tablero y fijarse como queda la parte con el adhesivo, si queda enrollada es que algo no va bien, un buen post-it bien fijado queda perfectamente plano aún quitándolo repetidas veces.

¿Cómo se realiza la planificación de sprint?

Con esta reunión, en el cuarto nivel de la planificación ágil, Scrum marca el inicio de cada sprint. En ella se planifica el trabajo a realizar en las siguientes semanas tomando como base las prioridades y necesidades de negocio, dándose respuesta a las siguientes cuestiones:

• Qué historias de usuario formarán el incremento que se entregará al finalizar el sprint
• Cuál es el trabajo necesario para realizar ese incremento previsto
• Cómo lo llevará a cabo el equipo

La reunión la conduce el responsable del funcionamiento del marco Scrum, usualmente el Scrum Master, pero en equipos maduros en Agilidad la conduce el propio equipo. Deben de asistir tanto el Propietario del Producto como el equipo al completo, y pueden asistir, sin voz ni voto, otros interesados en el proyecto, aquellos que puedan aportar información útil.

La reunión consta de dos partes, la primera responde a la pregunta: ¿Qué se entregará al terminar el sprint? y la segunda a: ¿Cómo se llevará a cabo la construcción del incremento?

Primera parte: se tratan las funcionalidades de la pila de producto

Primera parte

El Propietario del Producto presenta la pila de producto y expone los requisitos de mayor a menor prioridad y que prevé pueden caber en el sprint. Si la pila de producto ha tenido cambios significativos desde la vez anterior, explica las causas que los han ocasionado para que todo el equipo entienda el porqué del cambio. El objetivo de la reunión es que todo el equipo conozca las razones y los detalles con el nivel suficiente para comprender el trabajo a hacer en el sprint.

Tras reordenar y replantear las funcionalidades de la pila de producto, el equipo define el "objetivo del sprint" que sintetiza cuál es el valor que se le va a entregar al cliente. Ponerle nombre a las cosas nos acerca al negocio y en este caso hace que el equipo comparta la finalidad del trabajo.

Segunda parte: se estima
y se obtiene la pila de sprint

Segunda parte

Esta segunda parte debe considerarse como una reunión del equipo, por tanto deben estar presentes todos sus miembros. El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas para poner el corte a la pila de producto de hasta donde se comprometen a llegar y obteniendo así las tareas que forman la pila del sprint. Cada miembro habrá participado libremente en la planificación y creerá en el plan, y eso lleva a un sentimiento de compromiso. En este desglose el equipo debe de tener en cuenta los elementos de diseño y arquitectura que deberá incorporar al sistema.

Finalmente el equipo establece la estrategia para iniciar el sprint determinado las tareas para los primeros días del mismo, y luego, a modo de primera reunión diaria los miembros se las autoasignan uno a uno tomando como criterios sus conocimientos individuales, sus intereses individuales y una distribución homogénea del trabajo.

Tableros que intervienen en la planificación de sprint: 1 - la pila de producto en la que el equipo hace el corte (post-its verdes)
para llevarse al sprint, y 2 - Scrum Board dónde sobre las historias elegidas el equipo las desglosa en tareas (post-its amarillos)

Al final de la reunión se habrá determinado:

• Los elementos de la pila de producto que se van a ejecutar
• El objetivo del sprint
• Los criterios de aceptación y de hecho que cierran las historias de usuario y el sprint
• La pila del sprint con todas las tareas estimadas
• La duración del sprint y la fecha de la reunión de revisión

Como en todas las reuniones de planificación, esta también favorece la fertilización cruzada de ideas en equipo y aporta a la creación de una base de conocimiento común.

¿Qué tal iceScrum como software para ayudar a los equipos a alcanzar el éxito en sus proyectos?

He estado acompañando a tres equipos que para su gestión utilizan iceScrum, y he decir que he experimentado un software muy completo. Gestión visual a parte, el tablero no irradia información ni se ha convertido en un punto de referencia del equipo, este software realmente da solución a todas las necesidades de un desarrollo con Scrum. En la página de iceScrum podemos leer respecto a sus características:

Desglose de elementos: el producto se divide en sus características principales. Las características se dividen en pequeñas funcionalidades, las historias de usuario, que se implementan por el equipo a través de tareas.

Informes y métricas: iceScrum produce automáticamente informes ágiles como burndown, burnup, gráfico de estacionamiento, diagrama de flujo acumulado...

Pila de producto: la pila es el conjunto de historias que se preparan, refinan y se priorizan para que puedan ser planificadas y ejecutadas en los sprints por el equipo.

Roles: los permisos se otorgan de acuerdo con el papel en el equipo Scrum: Scrum Master, Propietario del Producto, miembro del equipo o interesados.

Lo que no me gusta

• En el tablero las tareas en curso están correctamente asignadas a los miembros del equipo, pero para poder mover una tarea de columna solo lo puede hacer el miembro propietario y este debe de estar logado, por tanto una gestión visual ágil para mover los post-its virtuales queda mermada de tal manera que es impracticable.

Equipo ante el tablero iceScrum en la reunión diaria

Lo que me gusta

• La pila de producto se representa en forma de post-its y permite la colorización, esto permite distinguir tipos de historias por su naturaleza, por ejemplo epics de historias de usuario e historias de usuario de historias técnicas.

Pila de producto y burnup

• El tablero de Scrum efectivamente gestiona el flujo de trabajo, aunque en la práctica lo hace de manera diferida.
• La opción de definición de hecho (DoD) está contemplada a nivel de sprint, esta es, a mi entender, una de las características más importantes que hacen que funcione Scrum.
• También tiene previsto la gestión de las retrospectivas.
• Y lo que me encanta es que la línea ideal del burndown no se pueda modificar una vez iniciado el sprint. Todos los equipos se quejaron de ello... de ahí hay que sacar una lección muy importante: ¡un sprint iniciado es intocable! y, el burndown es un gráfico para que el equipo sienta el avance, no una herramienta de reporting hacia arriba.

Tablero Scrum y burndown

iceScrum es un software que se puede contratar en la nube con coste, o descargar gratuitamente en su modalidad de community license (free & open source) e instalar en un servidor web propio.

¿Son aplicables los Poka-Yoke al desarrollo de software?

El Poka-Yoke es un sistema de prevención de errores utilizado en manufactura lean para minimizar el desperdicio, literalmente significa "a prueba de errores". Un dispositivo Poka-Yoke es cualquier mecanismo que ayude a prevenir errores antes de que ocurran y, este se puede diseñar con dos funciones, para prevenir errores para advertir sobre estos:

Función de control: que imposibilita de algún modo el error, como por ejemplo una tarjeta de memoria SD o un conector USB que no se puede enchufar de manera equivocada.

Función de advertencia: que resalta el error cometido de tal manera que sea obvio para el que lo haya cometido, como por ejemplo el pitido del coche cuando sacamos la llave del contacto si las luces están encendidas.

Los dispositivos Poka-Yoke fueron introducidos por el ingeniero Shigeo Shingo en Toyota en la década de 1960, y forman parte de lo que se conoce actualmente como Sistema de Producción Toyota. 

Las características principales de un buen dispositivo Poka-Yoke son:

• Es sencillo
• Es parte del proceso
• Está puesto en el lugar donde ocurre el error

Las pruebas de software son una forma de dispositivo de detección, no tanto las pruebas en su forma tradicional que se producen demasiado tarde en el proceso de para permitir una retroalimentación rápida, pero si las pruebas unitarias, las pruebas de humo y las pruebas automatizadas. Estas se acercan a la noción de Poka-Yoke ya que se encuentran cercanas al momento de los errores potenciales, y su respuesta rápida permite evitar que los errores se propaguen a lo largo del proceso.

A quién esté interesado en técnicas Poka-Yoke para la detección de errores en la construcción de software lo invito a leer el artículo de Harry Robinson "Using Poka-Yoke Techniques for Early Defect Detection".

¿Cómo incrementar la velocidad del equipo?

Incrementar la velocidad,
cortesía de Clipart Panda

Este post nace de la consulta de un alumno que empezaba su duda con "Leyendo sobre literatura acerca del uso de historias de usuarios he encontrado en varios textos la siguiente afirmación: si las historias de usuario están listas o ready (DoR) para su implementación, el equipo de trabajo puede duplicar su velocidad de desarrollo. También se afirma que la introducción de los criterios de aceptación y la definición de hecho (DoD) ayudan a incrementar la velocidad del equipo...".

Con solo el hecho de implementar Scrum se propicia la creación de equipos ganadores, equipos maduros en Agilidad de los que se habla de hiperproductividad, en que su velocidad, partiendo de equipos clásicos como se constituyen al principio en los proyectos con metodología tradicional, se puede incrementar de media un 400%. No hay magia ni heroicidad en ello, son diversos factores para los que Scrum crea el ambiente idóneo, los que hacen que un equipo incremente su velocidad de esta forma tan espectacular:

• La comunicación, la conversación en las reuniones y la creación de una base de conocimiento compartida
• La integración y la confianza entre los miembros
• Un objetivo común a nivel de equipo
• La ayuda entre miembros para formarse, desbloquear tareas y compartir ideas
• Los canales de comunicación abiertos entre equipo de desarrollo y negocio
• El compromiso adquirido, siendo el equipo quién pone los límites del sprint
• La autogestión y autoorganización que propicia el control sutil (el autocontrol)
• Planificación constante (daily-scum) que irradia la situación y da sensación de avance
• El ritmo de entregas periódico con el reconocimiento de trabajo bien hecho a final de sprint
• Y como no, las pizzas y cervezas, el team-building :-)
• Y finalmente también DoR (Definition of Ready) y DoD (Definition of Done)

Tener las historias de usuario susceptibles de entrar en el siguiente sprint cumpliendo con DoR (definición de listo), significa que los usuarios (o Propietario del Producto) han hecho sus deberes y están listas para comunicarlas al equipo de desarrollo con todo el detalle necesario. Con ello el equipo de desarrollo tendrá muy claras las ideas sobre lo que han de codificar y el código que escriban se ajustará realmente a los requisitos, haciendo que el equipo sea más eficiente y que se evite el retrabajo.

Los criterios de acepación y DoD (definición de hecho) extreman la eficiencia, si el programador sabe qué criterios ha de satisfacer de antemano tiene muchos puntos para hacer un software excelente, ya que el código que escribirá cumplirá con todos los criterios de aceptación (que son de negocio y técnicos) y cumplirá con la definición de hecho, que es aplicable a todas las historias, lo que permitirá darlas como realmente finalizadas en la revisión de sprint.

¿Qué significa cuando en Scrum se habla de trabajar por fases solapadas?

En un proyecto en cascada las fases en que se desarrolla este son secuenciales, una fase seguida de la siguiente. A priori esto parece que sea de lógica aplastante: 

• Piensa lo que quieres
• Escribe lo que has pensado
• Efectúa un plan sobre lo que has escrito
• Sigue tu plan para construir lo que has pensado

Pero si lo pensamos un poco más a fondo nos daremos cuenta de que eso nos obliga a tener todo muy claro al principio del proyecto, lo que no se piensa de entrada no tiene lugar después. Una buena idea que aparezca a medio proyecto puede convertirse en una verdadera pesadilla. Y todos sabemos que los proyectos de TI varían y cambian...

Scrum se basa en fases solapadas, estas se pueden imaginar como que a principio del proyecto se inicia de forma gradual un flujo por cada especialidad/rol necesarios para el proyecto, flujo que durará hasta finalizar el producto. Se inicia un flujo de análisis que irá por delante del de desarrollo, y a la vez este irá por delante del de las pruebas, por ejemplo:

Fases solapadas, cortesía de Scrum Manager

En el sprint 0, que es un sprint para preparar el entorno, la tecnología, las herramientas, etc., el Propietario del Producto trabaja con el cliente las historias de usuario susceptibles de entrar en el sprint 1.

Mientras el equipo trabaja en las historias del sprint 1, el Propietario de Producto trabaja junto con el cliente en las historias susceptibles para entrar en el sprint 2. Resaltar que se produce un flujo de toma de requisitos que va por delante de desarrollo y está solapado con este. Dentro del equipo tenemos algo similar, ciertas historias pueden requerir de un análisis para diseñar la solución y no es hasta que se termine este que se empieza a desarrollar. Probablemente analista y desarrollador sean el mismo, pero sus actividades son secuenciales y solapadas con otras actividades de otros miembros.