Historias de Usuario

Guion de facilitación

1. 1

   Enunciar el objetivo o la funcionalidad que abarca la sesión. Enumerar juntos los roles de usuario implicados y lo que cada uno intenta lograr.

   8 min
2. 2

   Todas las personas escriben tarjetas de historia en silencio, una necesidad por tarjeta, en la forma rol-funcionalidad-beneficio. Pegarlas donde todos puedan verlas y quitar los duplicados.

   10 min
3. 3

   Tomar las tarjetas de una en una, empezando por la más importante. El equipo pregunta al product owner hasta que el alcance de cada historia esté claro, y reescribe la tarjeta si hace falta.

   15 min
4. 4

   Añadir criterios de aceptación a cada historia discutida para que quede claro cómo se confirmará que está terminada.

   10 min
5. 5

   Contrastar las historias con INVEST y dividir las que sean demasiado grandes. Dejar pendientes las preguntas que nadie en la sala pueda responder, cada una con un responsable con nombre.

   7 min
6. 6

   El product owner ordena las tarjetas según el orden de entrega. Acordar qué historias están listas para la próxima iteración y cuáles necesitan más conversación.

   5 min

Consejos

• Tratar la tarjeta como un recordatorio para tener una conversación, no como una especificación; si la sala se queda en silencio y las personas empiezan a pulir frases, hacerlas volver a conversar.

• Escribir las historias con quienes las van a construir y probar, porque una historia que se entrega ya terminada se salta la comprensión compartida que la hace útil.

• Cuando una historia no se deja dividir, buscar las costuras: distintos roles de usuario, pasos de un flujo de trabajo, variaciones de datos o el caso simple antes de las excepciones.

Errores comunes

• Tratar la tarjeta escrita como el requisito y saltarse la conversación, de modo que el equipo construye lo que dice la frase y no lo que necesita el usuario

• El product owner escribe todas las historias a solas de antemano, lo que convierte la sesión en una lectura y elimina la comprensión compartida

• Dejar la cláusula del beneficio vacía o genérica, de modo que nadie puede juzgar si una solución más pequeña o distinta serviría igual de bien al usuario

• Escribir historias para capas o componentes de la arquitectura en lugar de porciones que un usuario pueda ver, lo que retrasa cualquier cosa utilizable hasta que todas las capas están terminadas

• Detallar todo el backlog con la misma profundidad, lo que desperdicia esfuerzo en historias que cambiarán o que nunca se construirán

Variaciones

Para un producto nuevo, empezar con una sesión de Story Mapping para trazar el recorrido del usuario y luego escribir las historias de la primera porción. Para historias con reglas de negocio complicadas, continuar con Example Mapping para convertir las reglas en ejemplos concretos antes de que la historia entre en un sprint. Los equipos remotos escriben las tarjetas en una pizarra compartida o directamente en la herramienta de backlog mientras una persona comparte la pantalla; conviene mantener las cámaras encendidas en el paso de la conversación. Algunos equipos prefieren las job stories, que describen la situación y la motivación en lugar de un rol de usuario.

Métodos relacionados