Historias de usuario / user stories 10 consejos para escribirlas como todo un experto

Las historias de usuario son probablemente la técnica ágil más popular para capturar la funcionalidad de algún producto o servicio a lo largo de un proyecto; ya que al trabajar con historias de usuarios facilita la comprensión y la razón de ser de ese requerimiento para la persona encargada de cumplir con esa tarea.

Si bien puede parecer fácil comúnmente no lo es, y esto termina por complicar el entendimiento y realización de correctas historias de usuario. Es por ello, que en Kaizenia te decimos como escribir correctamente estas también llamadas User Stories y completar con éxito tus proyectos:

1. Los usuarios son lo primero

Como su nombre lo sugiere, una historia de usuario describe cómo un cliente o usuario emplea el producto y se cuenta desde la perspectiva del usuario. Además, las historias de los usuarios son particularmente útiles para capturar una funcionalidad específica, como buscar un producto o hacer una reserva.

¿Qué es una historia de usuario?

Si no sabe quiénes son los usuarios y los clientes y por qué querrían usar el producto, entonces no debe escribir ninguna historia de usuario. Primero realice la investigación necesaria del usuario, por ejemplo, observando y entrevistando a los usuarios. De lo contrario, se arriesga a escribir historias especulativas basadas en creencias e ideas, pero no en datos y evidencia empírica.

2. Use Personas para descubrir las historias correctas

Una gran técnica para capturar sus ideas sobre los usuarios y clientes es trabajar con personas. Las personas son personajes ficticios que se basan en el conocimiento de primera mano del grupo objetivo. Por lo general, consisten en un nombre y una imagen; características, comportamientos y actitudes relevantes y un objetivo.  El objetivo es el beneficio que la persona quiere lograr, o el problema que el personaje quiere ver resuelto con el uso del producto.

Las metas personales lo ayudan a descubrir las historias correctas, pregúntese qué funcionalidad debería ofrecer el producto para cumplir los objetivos de las personas.

3. Crear historias en colaboración

Las historias de usuario están pensadas como una técnica ligera que te permite moverte rápido. No son una especificación, sino una herramienta de colaboración. Las historias nunca se deben entregar a un equipo de desarrollo. En cambio, deberían estar integrados en una conversación: el propietario del producto y el equipo deberían analizar las historias juntos. Esto le permite capturar solo la cantidad mínima de información, reducir la sobrecarga y acelerar la entrega.

Puede llevar este enfoque más lejos y escribir historias en colaboración como parte de su proceso de preparación de acumulación de productos. Esto aprovecha la creatividad y el conocimiento del equipo y los resultados en mejores historias de usuario.

Si no puede involucrar al equipo de desarrollo en el trabajo de la historia del usuario, entonces debería considerar usar otra técnica más formal para capturar la funcionalidad del producto, como casos de uso.

4. Mantenga sus historias simples y concisas

Escribe tus historias para que sean fáciles de entender. Manténlos simples y concisos. Evite términos confusos y ambiguos, y use voz activa. Céntrate en lo que es importante y deja de lado el resto. La siguiente plantilla pone al usuario o cliente modelado como una persona en la historia y hace que su beneficio sea explícito. Se basa en la plantilla popular de Rachel Davies, pero he reemplazado la función de usuario con el nombre de persona para conectar la historia con la persona relevante.

Como <persona>,

Quiero <¿qué?>

de modo que <¿por qué?>.

Use la plantilla cuando sea útil, pero no se sienta obligado a aplicarla siempre. Experimenta con diferentes formas de escribir tus historias para entender qué funciona mejor para ti y tu equipo.

5. Comience con Epics

Una épica es una historia de usuario a alto nivel, sin tanto detalle.  Por lo general, se divide en varias historias de usuarios a lo largo del tiempo, aprovechando los comentarios de los usuarios sobre los primeros prototipos y los incrementos del producto. Puede pensarlo como un título y un marcador de posición para historias más detalladas.

Comenzar con épicas le permite dibujar la funcionalidad del producto sin comprometerse con los detalles. Esto es particularmente útil para describir nuevos productos y características ya que le permite capturar el alcance aproximado, y le permite ganar tiempo para aprender más sobre cómo abordar mejor las necesidades de los usuarios.

También reduce el tiempo y el esfuerzo necesarios para integrar nuevos conocimientos. Si tiene muchas historias detalladas en la cartera de pedidos del producto, a menudo es difícil y lleva mucho tiempo relacionar los comentarios con los artículos apropiados y conlleva el riesgo de introducir incoherencias.

6. Refine las User Stories hasta que estén listas

Divida sus epicas en historias más pequeñas y detalladas hasta que estén listas, claras, factibles y comprobables. Todos los miembros del equipo de desarrollo deben tener una comprensión compartida del significado de la historia y no debe encajar demasiado en un sprint, deben de encontrar una manera efectiva de determinar que la historia está lista.

7. Agregar criterios de aceptación

Al dividir las epicas en historias más pequeñas, recuerde agregar criterios de aceptación. Los criterios de aceptación complementan la narración, ademas de que te permiten describir las condiciones que deben cumplirse para que la historia esté lista. Los criterios están enriqueciendo la historia, hacen que sea comprobable y proporcionan esa historia para que sea demostrada o entregada a los usuarios y otras partes interesadas. Como regla general, tenemos de tres a cinco criterios de aceptación para historias detalladas.

8. Utilice tarjetas de papel

Las historias de usuarios surgieron en una metodología ágil llamada XP o Extreme Programming.  Hay una razón simple, las historias de usuarios se capturaron en tarjetas de papel. Este enfoque proporciona tres beneficios descritos a continuación:

  1. las tarjetas de papel son baratas y fáciles de usar.
  2. Requieren colaboración, todos pueden tomar una tarjeta y anotar una idea.
  3. Las tarjetas se pueden agrupar fácilmente en la mesa o pared para verificar la consistencia y la integridad y para visualizar las dependencias. Incluso si sus historias se almacenan electrónicamente, vale la pena usar tarjetas de papel cuando escriba nuevas historias.

9. Mantenga sus historias visibles y accesibles

Las historias quieren comunicar información. Por lo tanto, no los oculte en una unidad de red, en la intranet corporativa de la selva o en una herramienta con licencia. Hazlos visibles, por ejemplo, colocándolos en la pared. Esto fomenta la colaboración, crea transparencia y hace que sea obvio que comenzará a quedarse sin espacio en la pared.

10. No confíes únicamente en las historias de los usuarios

Requiere una gran experiencia de usuario (UX). Las historias de usuario son útiles para capturar la funcionalidad del producto, pero no son adecuadas para describir los viajes del usuario y el diseño visual. Por lo tanto, los libros de cuentos, guiones gráficos, diagramas de flujo de trabajo, guiones gráficos, bocetos y maquetas.

Además, las historias de los usuarios no son buenas para capturar los requisitos técnicos. Si necesita comunicarse con un elemento arquitectónico, como un componente o servicio, escriba historias técnicas o use un lenguaje de modelado como UML.

Finalmente, escribir historias de usuario vale la pena cuando desarrolla software que es probable que se reutilice. Pero si quiere crear rápidamente un prototipo desechable o una maqueta para validar una idea, entonces escribir historias puede no ser necesario.

Recuerde: las historias de usuario no tratan de documentar los requisitos, sino más bien le permiten moverse rápido y desarrollar proyectos lo más ágil posible.

Puedes seguir aprendiendo