Historias de Usuario a fondo

Una Historia de Usuario es una manera de recoger los requisitos de un producto en producción. En una Historia de Usuario sólo se debe tratar necesidades valiosas para los usuarios.

Las Historias de Usuario no son únicamente la tarjeta con el título y la descripción que todo el mundo conoce. Una Historia de Usuario se compone de la TARJETA que describe brevemente qué se quiere, la CONVERSACIÓN que se tiene para profundizar en las necesidades y aclarar los objetivos de la misma y la CONFIRMACIÓN de que se entiende el objetivo de la Historia de Usuario. En inglés se le conoce como las 3 C's (CARD, CONVERSATION & CONFIRMATION).

Las principales ventajas de utilizar Historias de Usuario son:

• Deben ser cortas, lo que fuerza a representan requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas).
• Necesitan poco mantenimiento.
• Mantienen una relación cercana con el cliente.
• Permiten dividir los proyectos en pequeñas entregas.
• Permiten estimar fácilmente el esfuerzo de desarrollo.
• Son ideales para proyectos con requisitos volátiles o no muy claros.

En la descripción de un producto tenemos los siguientes elementos:

• Temas: Conjunto de EPIC's que describen un sistema o subsistema del producto.
• EPIC: Es como una Historia de Usuario a gran escala, o dicho de otro modo, con poco nivel de granularidad. Un ejemplo puede ser "Gestión de Usuario". Un EPIC debe refinarse en varias Historias de Usuario para poder ser estimado.
• Historias de Usuarios: Define "qué" es lo que se necesita tener en el producto. Debe poderse estimar e implementar durante un sprint.
• Tarea: Definen el "cómo" se va a llevar a cabo el trabajo para cumplir el objetivo de la Historia de Usuario.

Los campos

Una Historia de Usuario no está definida por un conjunto de campos que deban aparecer de manera obligatoria. Los campos a incluir se definirán según cada situación. Sin embargo, si hay una serie de campos que es aconsejable que no falten: Descripción, Estimación y Prioridad. 

Además de los tres mencionados existe un conjunto de campos que suelen incluirse: identificador, título, criterios de validación, valor, criterios de finalización, dependencias, persona asignada, sprint, riesgo y módulo.

ID

Se puede otorgar un identificador único a cada Historia de Usuario a fin de poder hacerla referencia rápidamente y de manera inequívoca.

Título 

Se puede escribir un título corto que permita identificar la funcionalidad deseada con leguaje natural.

Descripción

Para hacer una buena descripción se recomienda utilizar la técnica de User-persona. En esta técnica se busca personificar cada uno de los tipos de usuario que va a tener el producto. Así por cada tipo de usuario o rol se definirán los siguientes elementos:

• Nombre y alias: de esta manera podremos referirnos a el/ella de manera sencilla. Por ejemplo "Paco Hernandez el Mecánico"
• Datos demográficos: nos ayuda a clasificar al rol en un segmento del mercado. Por ejemplo "Persona de unos 25 años que utiliza mucho las tabletas y lo móviles pero no está acostumbrado a un ordenador"
• Descripción: nos ayuda a conocer al rol. Por ejemplo "Persona apasionada de la mecánica que está leyendo blogs de mecánica y siempre con ganas de aprender"
• Objetivos: se buscan las necesidades de este rol que le diferencie del resto. Por ejemplo "Como persona apasionada de los coches quiere tardar lo menos posible en cualquier tarea que no esté directamente relacionado con su trabajo"

En base a estos perfiles se deben definir las Historias de Usuario indicando por cada rol qué necesita en el producto y para que fin. Así, lo más óptimo es utilizar el patrón:

Como [rol de usuario] ... Quiero [objetivo] .. Para poder [beneficio]

Un ejemplo: 

    Como el Mecánico 

    Quiero consultar el stock de las piezas por su referencia 

    Para poder saber si puedo pedirla al almacén rápidamente

IMPORTANTE: Se debe separar entre persona o rol. Una persona puede tener varios roles (tener el rol de Product Owner y a la vez el rol de usuario), pero el rol de Product Owner no puede  ser en ningún caso el Rol de Usuario. Y por ello, el beneficiario de una Historia de usuario nunca podrá ser el Product Owner o el Scrum Master o un miembro del Equipo de Desarrollo, aunque sí lo podrá ser la persona que tenga uno de estos roles.

Valor

El valor se podrá medir con la escala que agrade al equipo. Se recomienda que sea una escala numérica para, posteriormente, se pueda operar con él (serie de fibonacci o los números naturales).

¿Cuánto vale una Historia de Usuario? Pues lo podemos tratar como la ley de la oferta y la demanda. Tendrá más valor cuanto más se quiera pagar por tenerlo. Así, una técnica es utilizar los billetes del monopoly y que cada interesado diga cuanto está dispuesto a pagar. Después, para tener números más manejables el valor de la Historia de Usuario se puede dividir entre 100 o 1000.

Otra opción es utilizar la técnica del Planning Pocket. Esta técnica es muy utilizada para realizar estimaciones de esfuerzo. Sin embargo, se considera muy útil su utilización para definir el valor por dos motivos: los interesados respetarán más al Product Owner y además podrán entender porque el Equipo de Desarrollo tiene que estimar varias veces.

Estimación

La estimación, al igual que el Valor de una Historia de Usuario es muy subjetiva a las necesidades de cada persona y sus experiencias. Las personas solemos pensar en números pares, por ello es importante utilizar series numéricas que nos obliguen a salir de ese patrón, como por ejemplo la serie de Fibonacci. 

La estimación se debe utilizar en base a comparaciones y siempre buscando un consenso del Equipo de Desarrollo. Para estimar las Historias de Usuario se suele utilizar la técnica del Planning Pocket. 

Sin embargo, para Temas y EPIC's se recomienda utilizar medidas como las tallas de las camisetas: XS, S, M, L y XL. El motivo es que al no ser un número no es posible hacer una traslación a horas/hombre. Así, queda claro que la estimación es muy incierta y por lo tanto deberá refinarse para obtener una estimación más fina.

Priorizacion

Para poder priorizar una Historia de Usuario se deberá disponer del valor y de la estimación. Una Historia de Usuario que sea muy valiosa deberá ser muy prioritaria, por el contrario una Historia de Usuario que requiera mucho esfuerzo deberá dejarse para el final. Así, en función de estos valores deberemos equilibrar la balanza para escoger que Historias de Usuario deben hacerse primero.

Existen varias manera de realizar priorización, aquí vamos a ver tres: técnica MoSCoW, ROI y WSJF.

MoSCoW

Esta técnica se basa en clasificar las Historias de Usuario según los siguientes criterios:

• Must have (necesario): si no se dispone de estas funcionalidades el producto no es completo
• Should have (debería): son funcionalidades que son muy importantes pero que sin ellas se puede usar el producto.
• Could have (podría): son funcionalidades deseables.
• Won't have (no lo queremos, quizá en el futuro): funcionalidades que a futuro pueden ser interesantes.

ROI

Es el Retorno de la Inversión. La prioridad de una historia se mide entre su valor y la estimación.

ROI = Valor / Estimación

Aquí nos encontramos el problema de que algunas historias no tienen valor para el usuario. Estas historias las veremos más adelante y se llaman "Historias Técnicas". Un ejemplo podría ser la instalación y configuración de un servidor. Esta acción es imprescindible para después poder acceder a la aplicación, sin embargo, no tiene ningún valor al usuario dado que a él esta historia, por si sola, no le aporta nada.

WSJF

WSJF (Weighted Shortest Job First / Primero el trabajo más pequeño). Este método utiliza una formula que permite asignar un "valor" a aquellas historias que por definición no lo tienen (Historias Técnicas).

En el siguiente ejemplo vemos una tabla con los campos:

• CD (Coste de Demora): Es el valor que deja de percibirse al no tener una determinada Historia de Usuario. Con este dato, en el caso de las Historias Técnicas, podemos obtener su CD en función del valor de las Historias de Usuario que dependen de la Historia Técnica para poder ejecutarse. Se calcula siguiendo la siguiente fórmula: CD = VN + CT + RRyVO
• VN (Valor de negocio): Es el valor de la Historia de Usuario
• CT (Criticidad en el Tiempo): Cuanto más crítica es una historia más alto debe ser el valor de este campo.
• RRyVO ( Reducción del riesgo y valor de oportunidad ): Se debe puntuar má alto cuanto más riesgos se eliminen si se desarrolla la historia y cuantas más oportunidades abra.
• EST (Estimación): Es la estimación que el equipo ha dado a la Historia
• WSJF: Es el valor que nos indicará la prioridad de cada Historia de Usuario. Se calcula así: WSJF = CD / EST

Historias de Usuario	VN	CT	RRyVO	CD	EST	WSFT
Configurar Servidor	1	5	13	19	3	6,33
Alta de Usuario	5	3	3	11	3	3,66
Alta de Producto	5	3	3	11	3	3,66
Crear pedido	8	8	1	17	5	3,4

Para llegar a tener estos valores se han de seguir los siguientes pasos:

1. Se estiman las Historias de Usuario, EPIC's y Temas.
2. Se crea una tabla donde en las filas pondremos las HU, EPIC's y Temas y como columnas cada variable del Cote de demora, la estimación y el WSJF que se calculará al final.
3. La escala a utilizar es la serie de Fibonacci (1 … 21)
4. Se rellena la tabla columna por columna.
5. Se pone el 1 al elemento más pequeño (obligatorio que exista un 1).
6. Se rellena el resto de la columna con respecto al 1.
7. Se calcula el coste demora.
8. Con todas las columnas rellenas se calcula el WSJF (WSJF = Coste demora / estimación)
9. Se ordena de mayor a menor según el valor de la columna WSFJ.

Criterios de Validación

Los criterios de validación son utilizados para poder verificar de manera objetiva que la funcionalidad solicitada hace lo que se espera de ella. Se suelen escribir como CheckList cuando una Historia de Usuario es susceptible de ser incorporada en el Sprint Backlog. Después durante la planificación se detallan más si fuera necesario.

Para garantizar la calidad de los criterios de validación se suele utilizar la técnica SMART. Un criterio de validación deberá cumplir el mayor número posible de las siguientes características:

• S - Específicos (Specific)
• M - Medibles (Mesurable)
• A - Alcanzables (Achievable)
• R - Relevantes (Relevant)
• T - La validación dura un tiempo limitado (Time-boxing)

Para la especificación de los criterios de validación se pueden utilizar lenguajes semi-formales como Gherkin. Con Gherkin los criterios de validación se escriben en lenguaje natural utilizando la siguiente estructura:

• Scenario (Escenario) [Número] … --> Descripción de la funcionalidad
• Given (Dado que) … AND (Y que) … --> Contexto/s
• When (Cuando) … AND (y) … --> Evento/s
• Then (Entonces) … --> Resultado

Por ejemplo:

    Escenario 1: Se quiere dar el alta un nuevo usuario

    Dado que un usuario "Administrador" está logado

    Cuando pulsa en el menu "Usuarios"

    Y pulsa sobre el botón "Añadir usuario"

    Entonces la aplicación muestra el formulario para añadir usuario.

La conjunción Y se utiliza para anidar las sentencia que la preceda. Así en el ejemplo anterior se están dando dos sentencias de acción, primero pulsa sobre el menú de "Usuarios" y después sobre el botón "Añadir usuario".

Dependencias

Una historia no debería ser dependiente de otra, pero si ocurre se pondrá relacionar mediante este campo. En este campo se deberá escribir los ID's de las Historias de Usuario de las que dependa.

Persona asignada

El Product Owner podrá sugerir una persona para realizar una Historia de Usuario concreta. Ha de tenerse muy presente que este campo sólo podrá tomarse como sugerencia nunca como asignación. Será, en última instancia, el Equipo de Desarrollo quien determine quien implementa dicha Historia de Usuario.

Criterios de finalización

En este campo se puede escribir la definición de "Done". Como apreciación personal creo que esta definición podrá estar escrita en otro sitio y así evitar su repetición constante.

Sprint

Si se desea llevar un control más exahustivo es posible, por cada Historia de Usuario, indicar en que Sprint se ha implementado.

Riesgo

Será el riesgo técnico o funcional asociado a la implementación de la Historia de usuario. Una posible ponderación podría realizarse con: bajo, medio y alto.

Módulo

Módulo o sistema al que pertenece la Historia de Usuario

Observaciones

Campo destinado a cualquier información extra que se estime relevante para la Historia de Usuario.

Una Historia de Usuario es corta de escribir y de leer, pero no de explicar. Como habéis podido ver tiene muchos entresijos y elementos que necesitan ser entendidos muy bien para poder sacar el máximo partido a esta herramienta.

Toda la información que he presentado en este post la he aprendido en un magnifico curso de Scrum Manager.

Un abrazo a tod@s