una guía para escribir historias de usuario efectivas

¿cómo escribimos historias de usuario efectivas?

hay 5 principios rectores que recomiendo a continuación:

1. todos deberían estar felices
   conseguir que todos se unan a bordo es importante, así que consigue que todos los que escribirán y usarán tus historias de usuario introduzcan sus ideas y acuerden el formato que usarán.
2. sea consistente
   Una vez que tenga una estructura acordada, asegúrese de atenerse a ella.
3. concéntrate en lo que es importante
   Cuando los escribas, evita cualquier detalle sin importancia., Tómese el tiempo para hacerlos concisos, retire cualquier gofre, ya que solo se interpone en el camino.
4. No hay detalles de implementación
   siempre enfócate en el » por qué «y no en el»cómo». Por qué un usuario quiere algo, no cómo vamos a construirlo. Si necesita proporcionar detalles técnicos, estos deben adjuntarse como archivo de especificaciones separado.
5. claro, factible &comprobable
   asegúrese de que todos puedan entender cada historia y que sea alcanzable en el marco de tiempo con el que está satisfecho. Si vas a dar a luz en sprints de 2 semanas, entonces no debería tomar más tiempo que esas 2 semanas.,

historia de usuario anatomía

hay 3 partes obligatorias para una historia de usuario, el título, la descripción y los criterios de aceptación. Tu equipo puede estar de acuerdo en que una historia de usuario debe tener otros campos antes de que se pueda empezar a trabajar en ella. Por ejemplo, puede requerir un cesionario, puntos de historia o el impacto empresarial, pero considero que estos son opcionales, ya que no todas las organizaciones los requerirán.

Title
Los títulos deben ser cortos, únicos y no engañosos.,

algunos buenos ejemplos:

• «Agregar panel de contacto a la página de inicio»
• «agregar soporte de tarjeta de débito al carrito de compras»
• «actualizar el etiquetado de plantillas de correo electrónico»

algunos ejemplos menos buenos (tristemente del mundo real):

• «Hacer cambios acordados»
• «32072 — mapeo actualizado – upselling User story (27263)»
• «links — tracking query string for Bill trigger and smart post install

description

la descripción contiene el poder real de la historia del usuario. Debe crear empatía en el equipo para el Usuario y una comprensión del problema a resolver.,

una estructura muy popular para la descripción toma la forma de «As A want I want so so I can can».

esta estructura plantea la pregunta de «como quién»? ¿Quién es el usuario que enfrenta el problema? Puedes hacer referencia a una persona aquí si las estás usando, alternativamente, dale un nombre al usuario y agrega algún contexto a la situación del usuario. Trate de evitar el uso de «como cliente» o «como usuario», ya que esto es menos eficaz en la creación de empatía para un usuario real.

la descripción debe estar escrita en un lenguaje simple y claro, sin términos técnicos ni abreviaturas., Deberías preguntarte «¿ puede tu abuela entenderlo?»Un nuevo miembro del equipo debe ser capaz de leer la descripción y entender exactamente cuál es el problema que debe resolverse.

los siguientes ejemplos reales se han tomado de un proyecto para agregar funcionalidad a un sistema de cuentas en línea para clientes de una empresa de energía del Reino Unido.,

algunos buenos ejemplos:

• » Como John, un cliente con un medidor de electricidad tradicional, quiero entender por qué no puedo ver los gráficos de mi consumo de energía con más detalle que mes a mes para poder decidir si quiero cambiar esto y obtener un medidor inteligente instalado.»
• » Como Bart, un cliente proactivo de medidores tradicionales que desea asegurarse de que mi próxima factura sea precisa, quiero saber si una lectura de medidores ya se ha presentado hoy y que no necesito enviar otra.,»

algunos ejemplos menos buenos:

• «como usuario, quiero evitar que los clientes trad puedan profundizar por debajo del nivel más alto para que se administre su experiencia como cliente»
• «Como cliente que ha proporcionado un medidor leído hoy o ha tenido una lectura de combustible estimada hoy, no se me debe permitir enviar otro medidor leído hoy, ya que SAP no puede aceptar más de un medidor leído por combustible por día.»

los ejemplos menos buenos se reescribieron para que fueran los buenos ejemplos anteriores, ya que los problemas que describieron no estaban claros., Este proceso de refinamiento debe realizarse en cualquier momento en que cualquier parte de una historia de usuario no esté clara. Sólo asegúrate de que todos en el equipo es consciente y acepta los cambios.

criterios de aceptación

los criterios de aceptación se utilizan para demostrar la integridad de la historia del usuario. Esto es útil para desarrolladores y probadores.

escribir los criterios de aceptación es una forma efectiva de ir a través de todos los detalles de la historia antes de comenzar cualquier trabajo. Muchos peligros potenciales o trabajos inesperados pueden ser «descubiertos» temprano escribiendo buenos criterios de aceptación.,

una estructura muy popular para los criterios de aceptación toma la forma de «dado Given cuando Then entonces.» como se ve en los ejemplos a continuación.

si una historia de usuario tiene más de 10 criterios de aceptación, puede ser una indicación de que la historia está haciendo demasiadas cosas. En este caso, recomiendo considerar dividir la historia.

todo El equipo debe estar involucrado en la redacción de los criterios de aceptación. Si esto no es posible, recomiendo encarecidamente que todos los lean y estén de acuerdo con ellos antes de trabajar en ellos. Esto es especialmente cierto de cualquier persona involucrada en probar el trabajo.,

numerar los criterios de aceptación facilita su referencia.

algunos buenos ejemplos:

1. dado un cliente con un medidor tradicional en el gráfico de barras de uso de energía
   Al hacer clic en la herramienta-tip durante un mes
   , Se muestra una ventana emergente que coincide con el diseño especificado.
2. dado que un cliente de combustible dual ve el gráfico de barras de consumo de energía
   cuando tienen meses con valores estimados
   , La leyenda del gráfico debe mostrar claramente un icono de electricidad estimada con una barra roja clara
   , entonces la leyenda del gráfico debe mostrar claramente un icono de gas estimado con una barra azul claro.,

Cuando no lo necesitamos historias de usuario

tareas Técnicas

a Veces una tarea técnica, no parece relacionarse con un cliente. Si este es el caso, no uses una historia de usuario. Pero siempre vale la pena considerar por qué está haciendo una tarea técnica; ¿está actualizando una biblioteca para mejorar la velocidad de los usuarios? Si es así, debería ser una historia de usuario.

Bugs

Si se encuentra un error durante la prueba de una historia de usuario en la que se está trabajando actualmente, entonces debe estar asociado con esa historia de usuario.,

Si un error se encuentra por algo que no sea una historia de usuario, entonces no debe estar asociado con una historia de usuario, pero se agregó a la acumulación como un trabajo independiente.

mejora continua

Las historias de los usuarios evolucionarán a medida que se aprenda más sobre el trabajo a realizar. Esto es bueno, continuar mejorándolos hasta el punto de liberar el trabajo a los usuarios., Solo asegúrese de que todos en su equipo estén al tanto y estén de acuerdo con cualquier cambio que se realice.

sigue refinando el proceso. Sea ágil, reflexione sobre cómo funcionan sus historias de usuario para su equipo, discútalas en retro y siga mejorando la forma en que las Escribe.