Las Historias de Usuario describen cómo funciona una nueva funcionalidad del Producto en un lenguaje cotidiano o de negocios. Sin embargo, su preparación requiere mucho tiempo, esfuerzo y reflexión. En la entrada de hoy, señalamos los errores más comunes en las Historias de Usuario y sugerimos cómo abordarlos.
Los errores más comunes en las Historias de Usuario – tabla de contenido:
Introducción
La Historia de Usuario puede ser una gran herramienta para motivar al equipo a proponer nuevas soluciones a problemas presentados desde la perspectiva del usuario. Escribimos sobre qué es una Historia de Usuario en una entrada separada. Y en este artículo, presentamos INVEST, que es un método popular para escribir buenas Historias de Usuario. Hoy nos centraremos en los errores en las Historias de Usuario.
Problemas con 3W
Una Historia de Usuario adecuada responde a las preguntas:
- ¿Quién? (¿Quién es el usuario objetivo del Producto?)
- ¿Qué? (¿Qué capacidades tiene el Producto y qué puede hacer?)
- ¿Por qué? (¿Qué propósito cumple?)
Sin embargo, pueden surgir problemas con las respuestas a cada una de estas preguntas. El problema menos común es la duda sobre qué debería cambiar en el producto en respuesta a las necesidades del cliente. Por lo tanto, nos centraremos en los problemas relacionados con ¿Quién? y ¿Por qué?
¿Quién? – persona del usuario
Uno de los errores más comunes al crear Historias de Usuario es no responder a la pregunta con suficiente precisión: ¿para quién? En otras palabras, ¿quién es el usuario para quien se pretende el cambio planeado?
A menudo, una respuesta genérica que señala al Cliente o Usuario Final como el destinatario del cambio no es suficiente. La solución a este problema es imaginar al destinatario como una persona específica. Una persona es una imagen modelo del cliente objetivo. En otras palabras, una persona es una representación de la persona que utilizará el Producto de una manera específica.
Después de analizar tu Historia de Usuario, puedes encontrar que cuenta las historias de diferentes personas al mismo tiempo. Si hay muchos usuarios objetivo, vale la pena considerar dividir la Historia de Usuario en fragmentos más pequeños para evitar acciones contradictorias, mutuamente excluyentes o simplemente ineficaces.
¿Por qué? – un objetivo mal definido
A veces, la última sección de la Historia de Usuario se convierte en la fuente de problemas. Debe especificar el valor comercial de los cambios realizados durante la ejecución de la Historia de Usuario. Echemos un vistazo a un ejemplo de errores en las Historias de Usuario donde la descripción de una funcionalidad adicional reemplaza el objetivo:
Como cliente, quiero comprar una varita mágica con un clic porque quiero comprar una alfombra voladora la próxima semana.
En lugar de dar la razón para comprar la varita mágica, esta Historia de Usuario añade otro elemento a la lista de compras del cliente potencial. Por lo tanto, al preparar una Historia de Usuario, no olvides las razones para las alteraciones en la funcionalidad del Producto.
Problemas con 3C
Podemos desglosar el proceso de trabajo con Historias de Usuario en tres etapas llamadas 3Cs:
- Tarjeta – La tarjeta en la que se guarda la Historia de Usuario
- Conversación – Una conversación dentro del Equipo Scrum sobre la tarjeta de la Historia de Usuario
- Confirmación – definición de criterios de aceptación que confirmen que una tarea ha sido completada
Los errores pueden ocurrir en cualquiera de estos, que describimos a continuación.
Tarjeta
La tarjeta de memoria que almacena la Historia de Usuario tiene una capacidad limitada. Por lo tanto, los problemas más comunes se refieren a la longitud y el volumen de la Historia de Usuario. La Historia de Usuario necesita coherencia y no dar rodeos, como se dice, a tal grado preciso que cada palabra cuenta.
Esto se debe a que el problema de la tarjeta de la Historia de Usuario tiene dos dimensiones. Una es la forma en que se formula: concisa y conteniendo un mínimo necesario de enumeración. La segunda es el tamaño real de la Historia de Usuario. Una oración general puede expresar una gran cantidad de tareas que no se pueden completar durante un solo Sprint.
Conversación
La formulación de una oración de la Historia de Usuario es el punto de partida para una conversación con el Equipo de Desarrollo. Por lo tanto, es incorrecto tratarla como una descripción de la tarea a realizar. Desactiva la posibilidad de negociaciones y discusiones sobre diversas formas de su implementación. La Historia de Usuario no debe ser tratada como una descripción de requisitos para una nueva funcionalidad del producto, sino más bien como una invitación a iniciar una conversación sobre soluciones técnicas específicas que llevarán a la realización del valor comercial definido por la Historia de Usuario.
Confirmación
Escribimos sobre los criterios de aceptación que deben definirse para cada Historia de Usuario en detalle en el texto que describe qué es una Historia de Usuario. Sin embargo, uno de los errores comunes es la falta de claridad de los criterios de rendimiento.
Una Historia de Usuario bien escrita contiene una descripción de la situación en la que se implementa. Su prueba es que el Usuario aprovecha la nueva funcionalidad creada por el Equipo de Desarrollo.
Una herramienta útil para validar la Historia de Usuario es desarrollar una prueba de aceptación. Esto suele estar en el reverso de la tarjeta que contiene la Historia de Usuario.
Errores en las Historias de Usuario – Resumen
Al preparar y aplicar Historias de Usuario, vale la pena seguir las siguientes reglas:
- Identificar con precisión al Usuario afectado por el cambio
- Definir claramente el propósito de construir una nueva funcionalidad del producto
- Mantener su Volumen lo más corto posible
- Tratar la Historia de Usuario como un punto de partida para discusiones sobre soluciones con el Equipo de Desarrollo
- Establecer reglas claras para la aceptación
Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Como Gerente de Proyectos, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo presión de tiempo la convierten en la mejor persona para hacer realidad proyectos complicados.
Scrum Guide:
- Glosario de términos básicos, roles y nociones
- ¿Qué es Scrum?
- Valores de Scrum
- ¿Cómo implementar Scrum en tu empresa?
- Equipo Scrum - ¿qué es y cómo funciona?
- ¿Quién es un Product Owner?
- Los errores más comunes del Product Owner
- ¿Quién es el Scrum Master?
- Los errores más comunes del Scrum Master
- ¿Qué estadísticas y métricas debería seguir el Scrum Master?
- Equipo de Desarrollo en Scrum
- Los errores más comunes de los desarrolladores
- Artefactos de Scrum
- Escalando Scrum
- Sprint Backlog
- ¿Qué es el Product Backlog?
- ¿Qué son las Historias de Usuario?
- Creando la mejor Historia de Usuario con INVEST
- Los errores más comunes en las User Stories
- Criterios de Aceptación de la Historia de Usuario
- Estimación y Puntos de Historia en Scrum
- Planificación Poker
- Juego de Estimación del Equipo
- Definiendo Incremento
- Eventos de Scrum
- ¿Qué es un gráfico de quema?
- Ventajas y desventajas del gráfico de burndown
- Tableros Kanban en Scrum y Scrumban
- Velocidad en Scrum - Velocidad del Equipo de Desarrollo
- Scrum diario
- Planificación del Sprint
- Revisión del Sprint
- ¿Qué es una Retrospectiva de Sprint?
- Errores comunes durante una Retrospectiva de Sprint
- Cuidado del Product Backlog
- ¿Cómo crear e interpretar un gráfico de burndown?