Guía Scrum | 21. Errores en las historias de usuario

Las historias de usuarios describen cómo funciona la funcionalidad de un nuevo producto en un lenguaje comercial o cotidiano. Sin embargo, su preparación requiere mucho tiempo, esfuerzo y reflexión. En la entrada de hoy, señalamos los errores más comunes de las historias de usuario y sugerimos cómo tratarlos.

Los errores más comunes de las historias de usuario: tabla de contenido:

1. Introducción
2. Problemas con 3W
3. Problemas con 3C
4. Errores de la historia de usuario: resumen

Introducción

User Story puede ser una gran herramienta para motivar al equipo a proponer nuevas soluciones a los problemas presentados desde la perspectiva del usuario. Escribimos sobre qué es User Story en una entrada separada. Y en este artículo, presentamos INVEST, que es un método popular para escribir buenas historias de usuarios. Hoy nos centraremos en los errores de User Story.

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é? (¿Para qué sirve?)

Sin embargo, los problemas pueden acompañar las respuestas a cada una de estas preguntas. El problema menos común es la duda sobre qué debe 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 que se cometen al crear User Stories es no responder con suficiente precisión a la pregunta: ¿para quién? En otras palabras, ¿quién es el usuario al que se dirige el cambio planificado?

A menudo, una respuesta genérica que señale al Cliente o al Usuario final como 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 su historia de usuario, es posible que descubra 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 User Story. Eche un vistazo a un ejemplo de errores de Historia de usuario donde la descripción de la funcionalidad adicional reemplaza el objetivo:

Como cliente, quiero comprar una varita mágica con un solo 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 agrega otro elemento a la lista de compras del cliente potencial. Por lo tanto, al preparar una Historia de Usuario, no olvide los motivos de las alteraciones en la funcionalidad del Producto.

Problemas con 3C

Podemos dividir el proceso de trabajar con User Stories en tres etapas llamadas 3C:

• Tarjeta : la tarjeta en la que se guarda la historia de usuario
• Conversación : una conversación dentro del Equipo Scrum sobre la tarjeta Historia de usuario
• Confirmación : definición de criterios de aceptación que confirman que se ha completado una tarea

Pueden ocurrir errores 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 relacionan con la longitud y el volumen de la historia de usuario. La historia de usuario necesita coherencia y no andarse con rodeos, como dicen, hasta un grado tan preciso que cada palabra cuenta.

Esto se debe a que el problema de la tarjeta User Story tiene dos dimensiones. Una es la forma en que está formulada: concisa y con la cantidad mínima necesaria de enumeración. El segundo 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 del usuario es el punto de partida para una conversación con el equipo de desarrollo. Por lo tanto, es incorrecto tratarlo como una descripción de la tarea a realizar. Deshabilita la posibilidad de negociación y discusión sobre diversas formas de su implementación. User Story no debe tratarse como una descripción de los requisitos para la funcionalidad de un nuevo producto, es más bien una invitación a iniciar una conversación sobre soluciones técnicas específicas que conducirán a la realización del valor comercial definido por User Story.

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 vaguedad en los criterios de desempeño.

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. Por lo general, se encuentra en el otro lado de la tarjeta que contiene la historia de usuario.

Errores de la historia de usuario: resumen

Al preparar y aplicar User Stories, vale la pena apegarse a las siguientes reglas:

• Identificar con precisión al Usuario afectado por el cambio
• Defina claramente el propósito de crear una nueva funcionalidad del producto.
• Mantenga su Volumen lo más corto posible
• Tratar la historia del usuario como un punto de partida para las discusiones de solución con el equipo de desarrollo
• Establecer reglas claras para la aceptación.

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos