¿Cómo funciona la división de historias de usuario por happy/unhappy flow?

Las buenas historias de usuario y sus criterios de aceptación implican flujos de éxito (felices), happy flows, y de fallo (infelices), unhappy flows. El flujo de éxito, flujo feliz o happy flow representa la situación perfecta donde hay pocas o ninguna opción y describe el comportamiento de la funcionalidad cuando todo va bien. El flujo de fallo, flujo infeliz o unhappy flow trata cualquier flujo alternativo, desviación, de excepción o de problema que pueda ser posible.

El identificar los diversos flujos inherentes a un funcionalidad la permite entender más claramente. El Propietario del Producto puede decidir qué flujos son más importantes en este momento. Quizás bloquear un usuario después de fallar tres veces no es importante en este momento en el que aún tenemos pocos usuarios.

¿Cuándo aplicarla?

Cuando la funcionalidad implica un happy flow en el que todo sale bien y uno o más flujos alternativos.

Ejemplo de una historia de usuario de login en un banco:

Como usuario

Quiero acceder a mi home-banking

Para poder acceder a mis movimiento bancarios de forma segura

Diagrama con flujos feliz e infeliz

División considerando flujos feliz e infelices:

Happy flow

Como usuario

Quiero logarme con mi cuenta de de correo electrónico

Para poder acceder a mi home-banking

Unhappy flows

Como usuario

Quiero resetear mi contraseña cuando mi login falla

Para poder intentar acceder de nuevo

Como usuario

Quiero tener la opción de registrar una cuenta de correo electrónico nueva si no puedo acceder con la actual

Para poder acceder a mi home-banking

Como responsable de seguridad del banco

Quiero bloquear usuarios que se loguen con

credenciales inválidas tres veces seguidas

Para poder proteger el sistema de hackers

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Una historia de usuario se puede optimizar incrementalmente?

Si, podemos dividir una historia de usuario utilizando la estrategia de división por optimizar ahora o más tarde. Hay historias en las que gran parte del esfuerzo consiste en hacer que su ejecución sea rápida. En este caso la implementación funcional no es compleja, la complejidad está en los requerimientos no funcionales, como en el rendimiento por ejemplo.

Se puede aprender mucho de una solución inicial lenta, e incluso puede tener algo de valor para el usuario. En este caso la estrategia de división trata de implementar la funcionalidad en diversos grados de perfección y optimización, puede resumirse en "hazlo funcionar" y después "haz que sea rápido". Ayuda al Propietario del Producto a priorizar las historias resultantes dando prioridad a lo que sea más necesario para la gran mayoría de los clientes.

Es importante resaltar que esta estrategia se refiere a la optimización funcional, no a una optimización de código que pueda servir de excusa para incurrir en deuda técnica.

¿Cuándo aplicarla?

Cuando la funcionalidad pueda implementarse a diferentes niveles de perfeccionamiento y optimización, hacerla funcionar primero y después mejorarla para cumplir con los requerimientos no funcionales.

Ejemplo de una historia de búsqueda de hoteles:

Como visitante

Quiero buscar hoteles en un vecindario

Para poder restringir mi búsqueda a la zona donde esté ubicado

División considerando los diferentes grados de optimización para implementar la funcionalidad:

Como visitante

Quiero buscar hoteles considerando un radio a partir de una dirección base

Para poder acotar mis búsquedas

Como visitante

Quiero introducir el código postal y buscar en el vecindario

Para poder no tener que completar la dirección base

Como visitante

Quiero usar la ubicación de mi GPS y buscar en el vecindario

Para poder no tener que completar la dirección base

Como visitante

Quiero obtener los hoteles más buscados en el vecindario de forma inmediata

mientras que otros hoteles se cargan en background

Para poder obtener resultados más rápidamente

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Cómo dividir una historia de usuario por tipos de datos o parámetros?

Esta estrategia de división de historias de usuario en elementos más pequeños se basa en la complejidad de los datos o los parámetros que utiliza. En este caso la complejidad de la historia viene marcada por las variaciones en los datos, y lo que plantea esta estrategia es incorporar esa complejidad de manera incremental a través de historias más pequeñas. Adicionalmente esta estrategia permite entender los parámetros que maneja con más claridad.

Imaginemos una funcionalidad de búsqueda libros y que la dividimos en historias con las búsquedas individuales; esto nos permite estimar la funcionalidad con mayor precisión, y también le permite al Propietario del Producto tomar decisiones sobre su prioridad. Quizás las búsquedas relevantes sean por título y por ISBN, se acerca septiembre y los padres estamos pendientes de comprar libros de texto; otros tipos de búsqueda pueden implementarse por ahora de manera simplificada o dejarlas para más adelante.

Podemos dividir en historias según
el esquema de base de datos
Cortesía de Pixabay

Otro ejemplo es dividir la funcionalidad según los tipos de datos que devuelven; quizá la idea sea presentar el resultado visualmente con gráficos, pero por ahora podemos decidir mostrarlos en un formato tabular y crear los gráficos manualmente con Excel.

También podemos inspirarnos para dividir en diagramas de entidad-relación (DER), éstos sugieren varios grupos diferentes de datos sobre lo que basarnos. Si en un DER tenemos entidades como "Libros", "Categorías", "Autores", ... podemos esperar historias de usuario relacionadas con esas entidades.

¿Cuándo aplicarla?

Cuando la historia es divisible por los tipos de datos que retorna o por los parámetros que se supone debe manejar.

Ejemplo de una historia de usuario para una web de gestión de reservas de restaurantes:

Como comensal

Quiero encontrar un restaurante que se adapte a mis deseos

Para poder llevar a mi pareja a una cena romántica

La división genera tantas historias como criterios de búsqueda de restaurantes tenga valor desarrollar:

Como comensal

Quiero buscar restaurantes por tipo de cocina

Para poder encontrar rápidamente un restaurante que se adapte a mis deseos

Como comensal

Quiero buscar restaurantes por un rango de precios

Para poder obtener resultados de búsqueda más relevantes

Como comensal

Quiero buscar restaurantes por rango de distancia

Para poder obtener resultados cercanos a mi ubicación

Como comensal

Quiero buscar restaurantes por un grupo de ingredientes principales

Para poder obtener resultados de búsqueda más relevantes

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Una historia de usuario puede dividirse por casos/escenarios de test?

Esta estrategia es útil cuando es difícil dividir una historia de usuario únicamente en base a la funcionalidad, y se tiene que hacer en base a todos los casos/escenarios de prueba derivados de los criterios de aceptación que debe de pasar la historia. Los escenarios de prueba relevantes pueden traducirse fácilmente a historias de usuario y pueden implementarse de forma incremental.

Los escenarios de prueba en entornos automatizados suelen estar escritos en gherkin, un lenguaje creado a tal efecto para que las pruebas puedan ser entendidas tanto por los equipos de desarrollo y los técnicos como por los Propietarios del Producto, interesados de negocio, analistas e incluso el cliente.

Sintaxis gherkin para describir escenarios de prueba

Si un escenario de prueba no es muy común o no presenta un riesgo lo suficientemente alto, el Propietario del Producto puede decidir omitir la funcionalidad asociada por el momento y enfocarse en escenarios de prueba que brinden más valor. También puede decidir simplificar algún escenario de prueba para cubrir los problemas más urgentes.

¿Cuándo aplicarla?

Cuando podamos responder a la pregunta: ¿Qué escenarios tienen que ser comprobados para saber que la funcionalidad está bien implementada?

Ejemplo de una historia de usuario y sus escenarios de prueba susceptible de ser divida por esta estrategia:

Como cliente

Quiero retirar dinero del cajero automático

Para poder evitar ir al banco a hacer una cola

Escenario 1: Cuenta tiene crédito

Dado que la cuenta tiene crédito

y que la tarjeta es válida

y que el cajero tiene dinero disponible

Cuando el cliente pide dinero

Entonces la cuenta es debitada

y el dinero es entregado al cliente

y el cliente recupera su tarjeta

Escenario 2: La cuenta excede el límite negativo acordado con el banco

Dado que la cuenta excede el límite negativo acordado con el banco

y que la tarjeta es válida

Cuando el cliente pide dinero

Entonces el cajero muestra un mensaje negando el pedido

y el dinero no es entregado al cliente

y el cliente recupera su tarjeta

Escenario 3: El cliente ha iniciado la operativa en su móvil

Dado que el cliente ha introducido el importe a retirar en la App Móvil

Cuando coloca el móvil con el código QR frente al escanner del cajero

Entonces el cajero entrega el dinero directamente al cliente

La división por escenarios de prueba de esta historia genera nuevas historias:

Escenario 1:

Como responsable del banco

Quiero comprobar que la cuenta del cliente tiene crédito

Para poder no entregar dinero por error

Como responsable del banco

Quiero comprobar que la tarjeta del cliente es válida

Para poder no entregar dinero por error

Como responsable del banco

Quiero comprobar que el cajero tiene dinero disponible

Para poder asegurar la entrega del dinero

Escenario 2:

Como responsable del banco

Quiero que el cajero deniegue la entrega del dinero a través de un mensaje

Para poder evitar que la cuenta exceda el límite negativo acordado con el banco

Escenario 3:

Como cliente

Quiero iniciar la operativa de retirar dinero del cajero automático en la App Móvil

Para poder evitar hacer una cola y obtener el dinero directamente

Como podemos ver en ejemplo esta estrategia ayuda a aplicar implícitamente otras estrategias. Los escenarios 1 y 2 implican estrategia de división por reglas de negocio y el escenario 3 de división por opciones/plataformas de entrada.

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Cómo dividir una historia de usuario por opciones/plataformas de entrada?

Esta estrategia propone dividir las historias de usuario por la diversidad de interfaces o medios por los cuales un usuario puede interactuar con el sistema. Por ejemplo están los diferentes dispositivos (ordenadores de sobremesa, portátiles, tablets, teléfonos móviles, pantallas táctiles, ...) con sus sistemas operativos que pueden requerir personalizaciones (Windows, Android, iOS, ...).

Al dividir con esta estrategia el Propietario del Producto puede priorizar fácilmente qué opciones de entrada o plataformas son más importantes. Por ejemplo es probable que una versión para móvil sea suficiente por ahora y podamos construir la versión para portátil más adelante.

A veces la complejidad se encuentra en la interfaz de usuario y no tanto en la funcionalidad. En ese caso la estrategia de división pasa por una historia de usuario con una interfaz lo más simple posible que luego se enriquece con historias incrementales que hagan la interfaz más usable y/o elegante.

¿Cuándo aplicarla?

Cuando la historia tenga que soportar varias formas de entrada y/o plataformas, y nos podamos preguntar ¿hay una versión más simple que podamos construir antes?

Ejemplo de una historia de usuario de una agencia de viajes on-line:

Como viajero

Quiero comprar vuelos entre dos destinos

Para poder disfrutar de mis vacaciones conociendo mundo

Historias resultantes de la división por esta estrategia:

Por dispositivo

Como viajero

Quiero comprar vuelos entre dos destinos a través de una App Móvil

Para poder disfrutar de mis vacaciones conociendo mundo

Como viajero

Quiero comprar vuelos entre dos destinos a través de un ordenador de sobremesa o portátil

Para poder disfrutar de mis vacaciones conociendo mundo

Por complejidad

Como viajero

Quiero poder elegir vuelos tecleando la fecha que me interesa

Para poder encontrar el billete

Como viajero

Quiero poder elegir vuelos seleccionando la fecha
a través de una elegante interfaz de usuario tipo calendario

Para poder encontrar el billete

Inicialmente el viajero ha de imprimir la página del navegador, más tarde añadimos una historia con una impresión específica:

Como viajero

Quiero imprimir el vuelo comprado

Para poder abordar al avión

Las estadísticas del blog marcan que la combinación de Chrome y Windows son la preferida de los lectores, por tanto nuevas historias de usuario pueden estar priorizadas según esta combinación

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

¿Cualquiera ha de tener la autoridad para parar el tren?

Inbar Oren hablando de la PI Planning totalmente distribuida

Estoy de asistente virtual en el European SAFe® SUMMIT 2020 y asistí a la charla "Fully Distributed PI Planning - How to Collaborate and Align in a Remote Environment" de Inbar Oren, y cuando le oí decir la siguiente afirmación:

Everybody has the ability
to stop the train

comprendí la profundidad del compromiso que adquieren todos los individuos subidos a un (ART) Agile Release Train.

Al final de la PI Planning todo el ART participa del voto de confianza con una técnica muy simple llamada fist of five: El RTE pregunta "Dado lo que sabe cada uno, ¿qué tan seguros os sentís con el plan creado por el equipo para alcanzar los objetivos del PI?" y todos levantan en el mismo instante una mano con 1 a 5 dedos extendidos (desde 1 que significa sin confianza en el plan a 5 que significa un plan perfecto). Primero lo pregunta para dentro de los equipos y después lo pregunta a toda la sala.

Todos han participado durante dos o tres días en el evento, todos deberían de estar convencidos de que el plan funcionará, recordemos que en SAFe, y en Agilidad en general, los que planifican son los que van a hacer el trabajo. Si el voto promedio de la sala es de al menos 3 dedos el plan se considera bueno, si fuera menos habrá que retrabajar y hará falta un nuevo voto de confianza.

Dejar una PI Planning de dos o tres días sin un plan comprometido no es una opción, no podemos empezar en ningún caso en falso, estamos hablando que 100 personas pueden fallar y eso no debemos permitirlo. Por tanto queremos el feedback de todos del nivel de confianza en el plan obtenido; si hubiera alguien que no confiara deberemos de aclarar sus preocupaciones antes de empezar el PI. Los que hayan votado uno o dos dedos tienen la oportunidad de compartir su preocupación y razonarla, quizá sepan o hayan visto algo que los demás no. El RTE preguntará ¿Qué habría de ocurrir para que subierais vuestro voto por encima del 2?

Pero veamos qué significa ese voto de confianza, y qué compromiso implica: En primer lugar los equipos se comprometen a hacer todo lo que esté en sus manos para cumplir con los objetivos comprometidos del PI, que ellos mismos han marcado; y también se están comprometiendo a escalar de inmediato si se enteraran de cualquier impedimento que evite que se pueda cumplir con esos objetivos.

Esa es esencia de la frase de Inbar, todo el mundo tiene la habilidad (y el deber si es el caso) de parar el ART. Esto es pura esencia Lean del sistema de producción de Toyota cuando se educa a los operarios a "jalar la palanca", a para la linea de producción si identifican una mejora o un problema en la misma.

A lo largo de la ejecución del PI va a haber accidentes, incompatibilidades inesperadas, riesgos inexplorados, retrasos imprevistos y todos, absolutamente todos deben de estar comprometidos a hacerlos trasparentes a todo el ART en el momento en que surjan. En una empresa Lean/Agile se reconoce que los problemas imprevistos siempre existen y que tanto el liderazgo como TI lo entienden, lo aceptan y ponen los medios necesarios para resolverlos en el menor tiempo posible.

¿Las reglas de negocio son una buena forma para dividir historias de usuario?

Esta estrategia de división propone que ciertas reglas de negocio especiales (estándares de la industria, regulaciones legales y cualquier tipo de restricciones complejas), que deban de cumplirse, sean incorporadas paulatinamente como ampliaciones incrementales de la funcionalidad inicial. 

Así el Propietario del Producto puede obtener historias de usuario iniciales que cubran un subconjunto de las reglas de negocio absolutamente necesarias, e implementar las restantes más adelante o de forma simplificada. Una regla simplificada como un mensaje en una tienda on-line que diga "No enviamos pedidos fuera de UE" puede que sea suficiente para empezar.

¿Cuándo aplicarla?

Cuando la historia de usuario involucra un conjunto de reglas de negocio implícitas o explícitas, algunas de las cuales podamos incorporar incrementalmente a posteriori.

Ejemplo de una historia de usuario de una tienda on-line:

Como comprador

Quiero pagar los artículos de mi carrito de la compra

Para poder recibirlos en mi casa

La división de esta historia genera historias igualmente complejas usando diferentes reglas de negocio:

Como propietario de la tienda

Quiero rechazar pedidos menores a 10 euros

Para poder evitar compras no rentables

Como propietario de la tienda

Quiero rechazar clientes de fuera de UE con pedidos inferiores a 100 euros

Para poder evitar gastos de envío que hacen la compra no rentable

Como propietario de la tienda

Quiero reservar stock de productos pedidos durante 48 horas

Para poder ofrecer a los clientes un stock real

Como propietario de la tienda

Quiero cancelar automáticamente pedidos para los que no he recibido el pago en 48 horas

Para poder vender esos productos a otros clientes

Las reglas de negocio se derivan de las políticas

Las reglas de negocio a menudo están implícitas por lo que para descubrirlas puede ser útil aplicar la estrategia de división por casos/escenarios de test primero.

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)