Cómo escribir buenas historias de usuario en Scrum

Aproximadamente el 70% de los proyectos de tecnología fracasan. Durante décadas se ha creído ampliamente que los proyectos fracasan porque no siguen las mejores prácticas o porque el equipo carece de todas las habilidades necesarias. Sin embargo, la adopción de mejores prácticas, habilidades y competencias ha mejorado con el tiempo, ¿entonces por qué los proyectos aún fracasan?

Teniendo en cuenta que el 70% de los proyectos de software fracasan debido a malas especificaciones. El retrabajo estimado asociado a estos fracasos supera los 45 mil millones de dólares anualmente.

Do 70% of Your Projects Fail? (Part 1) — Pie

La pregunta es: ¿por qué ocurre esto? La respuesta tiene dos aspectos. Primero, las especificaciones comerciales a menudo pierden el enfoque en el cliente; segundo, las especificaciones carecen de un marco de referencia general que permita a los analistas de requisitos impulsar y rastrear los requisitos desde las necesidades del cliente y la estrategia hasta la solución que se está implementando.

Para escribir buenos requisitos o historias de usuario, siga estos pasos:

  1. Defina tantas personas como sea posible para representar a los usuarios del sistema.Esto le ayudará a mantenerse enfocado en el cliente y a impulsar y rastrear los requisitos basados en las necesidades del cliente. Introducidas por Alan Cooper, las personas definen usuarios arquetípicos del sistema: ejemplos del tipo de personas que interactúan con él. Los usuarios no tienen por qué ser ni representar individuos. Un usuario también puede representar una organización.
  2. Asegúrese de que sus historias de usuario sigan las «3C»:

Minimum Viable Product Development - Define User Stories - PART 1 - Blog Systango

  • Tarjeta — Debe escribirse en una tarjeta de índice o una nota adhesiva
  • Conversación — Obtenga información detallada del Propietario del Producto
  • Confirmación — Asegúrese de que se implemente correctamente. Debe cumplir con los criterios de aceptación del usuario.
  1. Divida las historias de usuario para que tengan un tamaño adecuado y se ajusten dentro de un Sprint.Algunas formas de dividir las historias incluyen:
  • Dividir por pasos del flujo de trabajo
  • Dividir por canales de entrada/salida
  • Dividir por opciones del usuario
  • Dividir por persona/rol
  • Dividir por rango de datos
  1. Haga que cada historia de usuario siga el mnemónico INVEST:

User stories: a comprehensive guide - Justinmind

El ágilmnemónico INVEST, creado por Bill Wake, sirve como guía para garantizar elementos de alta calidad en el Product Backlog (PBIs), generalmente escritos en formato de historia de usuario.

  • Independiente: Las historias deben ser lo más independientes posible.
  • Negociable: Una historia no es un contrato. Una historia es una invitación a una conversación. La historia captura la esencia de lo que se desea.
  • Valioso: Si una historia no tiene un valor evidente, no debería hacerse.
  • Estimable: Una historia debe ser estimable o dimensionada para poder priorizarse adecuadamente.
  • Pequeño: Para una iteración de dos semanas, las historias de usuario deben tener un promedio de 3 a 4 días de trabajo, ¡en total! Esto incluye todo el trabajo necesario para llevar la historia al estado de «Listo».Cuanto más pequeña sea la historia de usuario, mayor será la precisión de la estimación!
  • Verificable: Cada historia debe ser verificable para considerarse «Listo».

Dejar una contestacion