Scrumízate
Querido lector, si estás en este post seguramente conoces qué son las historias de usuario. Como ya sabes y a modo deresumen, las historias de usuario son una excelente herramienta para representar las necesidades del usuario y centrando el punto de mira en la aportación de valor.
Tradicionalmente los requisitos se plasmaban en grandes documentos con diagramas y fichas de casos de uso y otros modelos de la ingeniería del software. Los requisitos se percibían como un contrato cerrado sin tener presente los rápidos cambios que nos ofrece cada día el entorno.
¿Verdad que te suena eso de los cambios de requisitos?
Como apunta el Manifesto ágil, los requisitos cambiarán, incluso en las etapas más avanzadas del desarrollo. Normalmente los equipos de desarrollo reaccionan mal ante estos cambios y esto es un error. Como equipo nuestro propósito es aportar el máximo valor al cliente o usuario y todo su feedback en el uso del software debe ser bienvenido para la mejora del mismo.
Durante los últimos años he escrito bastantes artículos alrededor de las historias de usuario y como las podemos aprovechar para centrar el esfuerzo de un equipo de desarrollo y maximizar así el rendimiento. Todos estos textos han sido creados a partir de mi experiencia personal en la empresa privada y, en la mayoría de los casos, hemos obtenido unos resultados excelentes.
Te invito a leer estos posts para entender mejor las historias de usuario y como aplicarlas:
- Historias de usuario, trucos y consejos
- Estrategias para aportar valor al usuario
- Los humanos entendemos las historias y no nos gustan las tareas
- ¿Los cambios que nos piden los clientes pueden ser gratis?
- ¿Qué hace el product owner en un equipo de desarrollo ágil?
- ¿Planficas basado en fantasías?
- Historias de usuario para definir los "requisitos de un proyecto"
1. Plantilla historias de usuario
En este post te ofrecemos una visión general de las historias de usuario, explicando detenidamente sus tres elementos principales: la tarjeta, la conversación y la confirmación. Para el primer y tercer elemento también te damos, al final de la introducción, el acceso de forma totalmente gratuita a nuestra plantilla para crear historias de usuario.
Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común del usuario. (Wikipedia)
Las historias de usuario son transversales a cualquier frameworks ágil que podáis estar usando, ya sea scrum, extreme programming (XP) o incluso kanban.
Una definición para cada elemento de las historias de usuario sería la siguiente:
- Tarjeta (Card): Describe los elementos más importantes de la historia de usuario. Se centra en el valor que se persigue desde el punto de vista del usuario.
- Conversación: Toda historia de usuario debe ir acompañada de una conversación por parte del equipo. En Scrum los momentos ideales para la conversación es durante el refinamiento del backlog, el sprint planning o en algún momento después de la daily.
- Confirmación: Consiste en el acuerdo de todas las partes (cliente, product owner, equipo de desarrollo) sobre cuales son los elementos, el valor y el resultado esperado de la historia de usuario en cuestión.
Puedes descargarte aquí la la plantilla para definir historias de usuario (aquí si prefieres en Keynote).
2.Formato de las historias de usuario (Tarjeta)
Para que puedas utilizar bien la plantilla que acabas de descargar vamos a explicar brevente el formato de las historias de usuario y como aplicarlo. Cuando trabajamos con la visión del producto debemos llevar sólo las gafas del usuario y oblidarnos de los puntos técnicos, del equipo o las prioridades. Nunca debemos escribir historias de usuario que presenten descripciones técnicas.
El objetivo de las historias de usuario es describir qué necesita el usuario y cual es su beneficio sin importarle el cómo será la solución.
Las historias de usuario serán siempre en lenguaje común. Las historias de usuario deberán ser independientes entre ellas. Para que nos entendamos, una historia de usuario no tiene en cuenta el estado actual o futuro del producto, solo expresa una necesidad del usuario durante el uso del producto.
El estándard de las historias de usuario es una frase redactada que responde a las siguientes preguntas:
- ¿Quién se beneficia?
- ¿Qué se quiere?
- ¿Cuál es el beneficio
El resultado de la frase redactada tiene la siguiente sintaxis:
Como [rol] quiero [algo] para poder [beneficio].
Por ejemplo, en un eCommerce podríamos contar con las siguientes historias de usuario:
- Como usuario quiero ver la lista de productos para poder identificar aquellos productos en los que estoy interesado.
- Como usuario quiero acceder a la información completa del producto para poder valorar mi interés en el producto.
- Como usuario quiero poner el producto en el carrito de la compra para poder efectuar la transacción.
Una frase no es suficiente para describir una funcionalidad! Cierto, pero las historias de usuario no son solo una frase!
Las historias de usuario nos deben generar conversaciones profundas acerca de la funcionalidad. La conversación nos llevará a unos criterios de aceptación, en los que el equipo se alineará para acordar en qué consiste aquella funcionalidad y como se realizará.
Como estarás pensando, las historias de usuario son una herramienta muy interesante para fomentar la comunicación dentro del equipo. Las historias de usuario permiten que el product owner involucra a todos los miembros en la definición del producto.
Querido lector, si realmente quiere profundizar en las historias de usuario te recomiendo la lectura del libro de Mike Cohn, Historias de usuario aplicadas. Se trata de una buena introducción a las historias de usuario con el objetivo de identificar qué convierte una historia de usuario buena o mala.
3.La fuerza de la conversación
Si eres product owner o trabajas con historias de usuario debes reforzar continuamente la idea de qué una simple frase escrita con una sintaxis determinada no significa que todos comprendan el auténtico valor.
Necesitamos entender que una historia de usuario es una promesa.
Cada una de las historias de usuario nos permite abrir un diálogo entre todos los miembros del equipo. La verdadera fuerza de las historias de usuario es el poder de las personas conversando y pensando por conseguir un objetivo superior.
Serán las conversaciones las que nos permitirán:
- Detallar a mayor nivel como se realizará la solución
- Clarificar los aspectos de valor, funcionamiento y técnicos
- Resolver las dudas que aparezcan
Querido lector, si trabajas con historias de usuario y no estás utilizando la conversación con estos objetivos estás dejando pasar la mayor oportunidad que te ofrece la herramienta. Recuerda que las historias de usuario nos ayudan a concentrar a todo el equipo en aportar el máximo valor posible en cada iteración.
Conseguir acuerdos
Las conversaciones que promueven las historias de usuario tienen como objetivo principal la consecución de acuerdos sobre los distintos puntos hablados. Estos acuerdos, que quedarán reflejados en los criterios de aceptación, nos permitirán validar que una historia de usuario está terminada.
Los criterios de aceptación nos evitan la aparición de discrepancias futuras sobre la necesidad descrita en la historia de usuario. Como product owner o scrum máster debes promover que en la conversación participen todos los puntos de vista implicados (desarrollo, producto, operaciones, marketing, clientes, usuarios...
Cuantos más puntos de vista participen mayor será el entendimiento de la necesidad. A mayor entendimiento mayor facilidad en acordar qué significa realmente una historia de usuario. Querido lector, es en este momento cuando descubrirás la auténtica fuerza de las historias de usuario.
Fomentar la comunicación
Seguro que no te descubro nada si afirmo que la comunicación es uno de los grandes problemas de las organizaciones. Una mala comunicación empieza a generar errores y la suma de ellos genera grandes bolsas de ineficiencias en las empresas. Esto también ocurre en los equipos de desarrollo ágil.
Cuantas veces no has vivido una discusión entre un desarrollador (o has sido tú el desarrollador) y un cliente interno de la empresa (tester, product owner, key account, marketing...) acerca de qué significaba un requerimiento una vez ya está programado o en producción?
Seguro que tu respuesta es que unas cuantas ocasiones. Seguidamente deberías pensar en el desperdecio de tiempo y esfuerzo que acabas de vivir y como harás que nunca más vuelvas a tener esta sensación.
Para tu suerte querido lector estás leyendo un articulo que te ofrece las herramientas y conocimientos para empezar a solucionar está situación y aprovechar la fuerza que las historias de usuario te ofrecen, la comunicación implicada en el valor para el usuario.
Si quieres saber más acerca de cómo las historias de usuario nos ayudan a motivar al equipo puedes leer este post, en el que se plantea que a los humanos nos gustan las historias y no las tareas.
4. Los criterios de aceptación (Confirmación)
El resultado que debes obtener de la conversación son unos criterios de aceptación claros y específicos que todo el equipo comprenda exactamente de la misma forma. Los criterios de aceptación nos permitirán evaluar en el futuro si la implementación que se está desarrollando olas pruebas que se realicen está terminada.
De algún modo podemos afirmar que lo que hacemos es detallar la historia de usuario para:
- Entender mejor el trabajo a realizar
- Definir aquellos puntos indispensables
- Los eventos del sistema o las interacciones del usuario
Como escribe Jerónimo Palacios, los criterios de aceptación cumplen principalmente la función de clarificar el contexto el que ocurre la historia de usuario y facilitar la identificación de que una historia de usuario está realmente terminada.
Formato de los criterios de validación
Querido lector, en mi opinión el formato de las criterios de validación debe ser aquél en el que el equipo se sienta comfortable. En todos los equipos en los que he participado han sido frases muy simples y concisas en las que todos entendíamos exactamente lo mismo.
Aún así, los estándares marcan que los criterios de validación también tienen su sintaxis definida. Si no estás acostumbrado a trabajar con historias de usuario empieza utilizando esta sintaxis:
Escenario [número] - [Título del escenario (opcional)]: En caso que [contexto] y adicionalmente [contexto], cuando [evento], el sistema [resultado / comportamiento esperado].
- Contexto: Descripción precisa sobre las condiciones que desencadenan el escenario previsto
- Evento: Acción realizada por el usuario en el contexto descrito.
- Resultado: Descripción de la situación esperada por parte del usuario.
Un error frecuente cuando empiezas a trabajar con historias de usuario es construir historias demasiado largas. La conversación y consecución de los criterios de validación nos ayudarán a detectar los casos en los que necesitamos dividir una historia de usuario.
Conclusiones
Si has llegado hasta aquí y has leído atentamente acabas de aprender una herramienta que puede ser clave para potenciar la participación dentro del equipo y en la toma de decisiones sobre el trabajo a realizar.
Has aprendido a valorar que un equipo auto-organizado y con la capacidad de decidir sobre la evolución del producto avanzará más rápido y en la dirección deseado por parte de los clientes, negocio o ,los más importantes, los propios usuarios
Con esto aprendido solo que grabes en tu mente que las historias de usuario son una herramienta para mejorar la comunicación entre las personas involucradas. Si no generas conversaciones sobre las historias de usuario tienes un grave problema.
Querido lector, deja de quejarte diciendo que las historias de usuario no son lo bastante completas o concretas o que en producto escriben malas historias de usuario. En lugar de la queja, usa la conversación. Es el punto de partida para generar acuerdos.
Ante una historia de usuario levántate, junta a los involucrados, empieza una conversación y generad acuerdos.
Recuerda siempre que todos deben participar en la definición de las historias de usuario. Cuando digo todos es todos: product owner, developers, clientes, usuarios, marketing, operaciones...
Cuanto mayor sea el número de personas involucradas en el acuerdo más fácil será trabajar en la dirección correcta, que se traducirá en aportar el valor deseado y esperado a nuestro producto.
Menos es más.
Las historias de usuario nos permiten definir las funcionalidades de una forma concreta, pequeña, fácil de mantener y sin grandes documentaciones. Si la comunicación es un problema, la documentación excesiva también lo es. Las historias de usuario deben contener sólo la información imprescindible.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
