La historia de usuario (o user story) es una explicación formal, dentro de un contexto ágil, de una necesidad. También puede considerarse un requisito funcional del proyecto, si usamos un lenguaje más clásico. Es, en definitiva, el lugar donde va a quedar plasmado el comportamiento esperado de nuestro software, lo cual no sólo nos servirá de guía para entender qué hace y qué no hace nuestro producto, sino también será el artefacto que permitirá al equipo el trabajar sobre las especificaciones pactadas.
¿Cómo crear historias de usuario?
Las historias de usuario están divididas en tres partes: card, conversación y confirmación.
Card (tarjeta)
Se trata de una frase con el siguiente formato:
Como [tipo de usuario] quiero [necesidad] para [beneficio esperado]
Esto define los tres aspectos fundamentales en una HU:
- Tipo de usuario: nos asegura el hecho de que tenemos identificados todos los tipos de usuarios que afectan al proyecto. Por ejemplo, el tipo de usuario podría ser el cliente, el administrador de la plataforma, los usuarios premium, etc, etc. Esto responde al «para quién».
- Necesidad: nos asegura el hecho de tener definido qué es lo que pretendemos al desarrollar esta funcionalidad. Esto responde al «qué».
- Beneficio esperado: nos asegura del hecho de que esta historia aporta un valor concreto al usuario definido. Aquí detallamos cuál es el objetivo final de este desarrollo. Esto responde al «por qué».
Conversación
La conversación es un debate cara a cara con la persona que ha creado la historia de usuario (Product Owner, Product Manager, etc). En esta conversación se busca lo siguiente:
- Que el equipo entero (desarrolladores, diseñadores, PM/PO, etc) comprendan la historia de usuario y sus objetivos. La idea es seguir con la conversación hasta que todo el mundo tiene claro qué se busca, para quién y por qué.
- Que las personas que trabajarán para desarrollar la historia, tengan claras las tareas que van a tener que crear para conseguirlo.
- Que el equipo que vaya a trabajar sobre ella pueda estimar su dificultad (bien en tiempo, bien en puntos de esfuerzo).
La importancia de este debate reside en el hecho de que las historias de usuario no deben ser un mandato de la gerencia del proyecto o del cliente, sino una petición de una necesidad cuya solución (la forma en la qua la abordaremos) provenga del equipo entero.
Durante esta conversación el equipo entenderá qué se pretende, se acordará cómo llegar a ello y, por último, se llegará a un compromiso del coste de realizarlo, bien en puntos de esfuerzo, bien en tiempo. Además, ya en ese momento o un poco después, los encargados del desarrollo de cada historia de usuario deberán crearse a sí mismos las tareas necesarias para esa labor (luego hablaremos de esto), y asociarlas a la historia de usuario pertinente.
Confirmación
También llamada Criterios de aceptación. Este es el acuerdo de comportamiento de aquello que vamos a tratar de construir. Son las condiciones que la historia de usuario debe cumplir para que se dé su desarrollo como correctamente terminado. Tienen un comportamiento binario: o se cumplen o no se cumplen, no hay estados intermedios.
Ejemplos de criterios de confirmación clásicos que pueden acompañar a una historia de usuario (en Secture no los trabajamos exactamente así, un poco más abajo lo explico):
- Dada una búsqueda del usuario en la home, cuando le da al botón intro en su teclado, entonces le reenviaremos a la página de resultados.
- Dado que el usuario ha presionado el botón comprar y ha llegado a la página de confirmar compra, cuando elige PayPal como método de pago, entonces le reenviamos a la pasarela de pago de PayPal.
Nosotros, en Secture, no usamos el método clásico, ya que, en términos generales, se hacen más complejos de entender y, sobretodo, cohesionar entre ellos. Nosotros usamos un lenguaje llamado Gherkin, que nos ayuda a tener estructurado el comportamiento esperado, de una manera que entienden tanto los clientes, como los PMs, como los desarrolladores, testers, etc. Escribiremos, no dentro de mucho, otro artículo que explique Gherkin.
Modelo INVEST
Una buena costumbre a la hora de crear nuestras historias de usuario es asegurarnos de que cumplen con el modelo INVEST. Este modelo nos proporciona las pistas de cómo ha de ser una historia de usuario eficaz, y se basa en seis aspectos que veremos a continuación:
- Independiente: la historia no debe depender de otras tareas o historias para poder realizarse. Concretamente, no deben depender de historias futuras, aunque sí puede hacerlo de historias ya realizadas.
- Negociable: debe haber sido negociada y aclarada entre el cliente y el equipo.
- Valor: debe aportar valor al proyecto.
- Estimable: el equipo deber ser capaz de estimar el esfuerzo necesario para su realización. Si no es estimable, la historia debe replantearse.
- Small (pequeña): debe ser suficientemente pequeña como para caber en el sprint y, a ser posible, ser realizada en pocas jornadas o una.
- Testable: debe de ofrecer datos suficientes como para medir si, tras su realización, cumple con los objetivos marcados.
¿Cuándo se puede dar una historia de usuario por lista para calendarizarse?
En los proyectos ágiles suele existir un documento (artefacto) llamado Definition of Ready (también conocido como DoR). Este documento recoge aquellas obligaciones o características que debe cumplir una historia de usuario antes de poder introducirla en un sprint. Es decir, es una formalización de qué criterios tenemos que cumplir antes de calendarizar nuestra historia de usuario y que el equipo se enfrente a su desarrollo.
El DoR no es un elemento inmutable. Según avance el proyecto, iremos descubriendo que es conveniente cambiar, quitar o añadir características. La experiencia y, sobretodo, los tropiezos, nos darán mejor perspectiva sobre el contenido de este documento. Un ejemplo de algunas obligaciones a cumplir en un DoR podría ser:
- La historia debe escribirse exactamente en el formato de ‘historia de usuario’.
- El equipo debe confirmar que entiende los criterios de aceptación y los objetivos de la historia.
- El equipo ha estimado el esfuerzo de la historia.
- El PO ha establecido el valor de negocio de la historia.
- La historia cumple el modelo INVEST.
¿Es posible tener más de un Definition of Ready en un proyecto? Sí, puede haber varios, en función de la tiología de la historia de usuario y sus necesidades.
¿Cuándo se puede dar una historia de usuario por finalizada?
En los proyectos ágiles suele existir un documento llamado Definition of Done (también conocido como DoD). Cuando una historia de usuario cumple con todos los requisitos del mismo, puede considerarse como finalizada y lista para subirse a producción o a un entorno preproductivo. El contenido de este documento (o documentos, porque puede haber varios en función del tipo de historia de o usuario o tareas en los sprints) difiere de un proyecto a otro y no hay un estándar como tal. Lo que tenemos que tener claro es que aquí debe formalizarse qué requisitos hemos tenido que cumplir para que una historia de usuario pueda considerarse terminada.
Tener este documento permite aunar criterios y evitar disputas o malentendidos dentro del equipo una vez comenzado el desarrollo. Si todo el mundo tiene claro qué ha de cumplirse, facilitamos muchos aspectos del proyecto.
Un ejemplo muy básico de aspectos que podría tener un DoD serían los siguientes puntos u obligaciones:
- Tareas relacionadas con la historia de usuario finalizadas.
- Se cumplen todos los criterios de aceptación de la historia.
- El código ha sido revisado por dos desarrolladores distintos.
- El código asociado se ha puesto en entornos pre-productivos sin errores de compilación.
- Se han realizado test unitarios y han sido superados.
- Se han realizado test funcionales y han sido superados.
- Característica aprobada por el cliente.
- Característica aprobada por el experto en UX.
Evidentemente, este DoD podría tener muchos más puntos. Además, como comentábamos antes, es posible que necesitemos DoD distintos según la tipología de la tarea. No es lo mismo una historia de usuario que un Spike (I+D dentro de un sprint), por poner un ejemplo.
¿Cómo priorizar las historias?
Las historias de usuario son la base de cualquier proyecto ya que son el reflejo del comportamiento final que debe cumplir nuestro desarrollo. Cuando tenemos un grupo de historias de usuario y metemos estas ideas en el backlog de producto a la espera del momento adecuado para incluirlas en un sprint, ¿cómo ordenamos las historias para decidir cuándo hemos de abordar cada una? Existen muchas técnicas que nos permiten asignar prioridades, ya que está sumamente demostrado que hacerlo a ojo no es funcional si efectivo. Por ello, te invito a que leas el siguiente artículo donde hablamos de cuatro técnicas de priorización que funcionan muy bien en los proyectos.
Estimaciones de las historias de usuario
¿Cuándo se estiman?
Las historias deben estimarse siempre. Se pueden medir en base a dos conceptos:
- Puntos de historia (puntuación del esfuerzo necesario).
- Tiempo en horas: número de horas que llevará realizar la historia de usuario.
En ambos casos, se evalúan en función de diversos factores:
- Complejidad de la historia de usuario.
- Cantidad de trabajo.
- Riesgos e incertidumbres.
- Capacidad técnica del equipo de cara a su resolución.
Además, la historia de usuario puede estimarse bien en sí misma, bien a través de la suma de esfuerzo que requieran las tareas que la componen.
En el caso de los puntos de historia, estos nos servirán para medir la velocidad de nuestro equipo en los sprints (velocity). Si nuestro equipo es capaz de asumir, por ejemplo, veinte puntos de historia de media en cada sprint, diremos que la velocidad de nuestro equipo es de 20.
¿Cuándo se estiman?
Siempre después de haber acabado las tres Cs (Card, Conversation, Confirmación). Además, una historia de usuario no puede comenzarse ni calendarizarse (sprint) sin haber sido estimada.
¿Cómo se estiman?
Hay diversas técnicas que nos permiten estimar historias de usuario. Dos de las más extendidas las tenemos contempladas en el siguiente artículo.
¿Son lo mismo las historias de usuario y las tareas?
Normalmente, las tareas son hijas de una historia de usuario. Teniendo en cuenta que la user story nos indica cómo se comporta el aplicativo desde un punto de vista funcional, el equipo necesita crearse tareas concretas para conseguir tal fin. Por ejemplo, una historia de usuario puede tratar de cómo funciona el login, pero luego el desarrollador y el diseñador necesitarán crearse tareas propias para cumplir con los casos de uso, como puede ser diseñar la pantalla del login, crear campos en la base de datos, crear la lógica de negocio, etc, etc.
Por ello, una historia de usuario tiene bajo su manto varias tareas. Y estas tareas las crean los que van a trabajar con ella, es decir, el equipo que desarrolla la solución.
De todas maneras, si quieres profundizar en el tipo de tareas que existen en un proyecto ágil, puedes ver este otro artículo donde hablamos exclusivamente de ello.
Conclusiones
Las historias de usuario o user story son un artefacto capital en los proyectos ágiles. Ellas son no sólo los sustitutos de los clásicos requisitos funcionales, sino que además, bien hechas, son la documentación del proyecto desde el punto de vista funcional. Debemos cuidarlas porque son el eje principal de los distintos desarrollos y su buena utilización puede ser la diferencia entre un desarrollo ordenado, con criterio y de calidad, de uno que destaque por todo lo contrario, con todo el perjuicio que eso conlleva.
