Escribir historias de usuario buenas

Las historias de usuario son herramientas que tienen su origen en Extreme Programming y se han convertido en la forma de facto en que los equipos ágiles documentan y recopilan requisitos. Se ha escrito mucho sobre historias de usuario (enlace, enlace, enlace), así que sólo voy a hablar sobre lo que considero importante a la hora de describir buenas historias, puesto que he visto muchas historias realmente malas ahí afuera.

Para aquellos que no lo saben, las historias son un artefacto ligero que nos permiten tanto capturar las necesidades de la empresa como planear el trabajo. Normalmente están escritas en tarjetas de índices o fichas (sí… tarjetas de índice pequeñas de 3 × 5 o 4 × 6) en el idioma del negocio o cliente. En las historias de usuario, escribimos sólo lo suficiente para captar las necesidades del usuario y no más. Solemos ver las historias no como especificaciones completas de los requisitos, sino como comodines para que más adelante los desarrolladores y el negocio conversen sobre ellas.

Cuando se usa apropiadamente, la falta de detalles de una historia de usuario nos proporciona una gran utilidad, podemos utilizar el mismo documento para hablar sobre un requisito de alto nivel, para ampliar los detalles de la implementación y para volver hacia atrás, y podemos hacer todo esto con solo un par de frases. Después de haber terminado de hablar de los requisitos, podemos considerar el riesgo, identificar las dependencias y crear un plan del proyecto sin ni siquiera tener que guardar la tarjeta de índice. ¡ Wow! No conozco que existan otros artefactos para requisitos que nos permitan tal utilidad.

Con los años las personas que realmente tienen éxito con las historias se han asentado en algunos puntos en común que se encuentran en todas las historias:

• Rol: ¿Quién o qué  va a utilizar esta característica?
• Característica (o capacidad): ¿Qué es lo que el Equipo va a entregar, o a añadir, después de hayan terminado su trabajo?
• Valor: ¿Por qué el negocio quiere esta característica? ¿Qué impacto tendrá en el negocio?
• Criterios de aceptación: ¿Cómo sabremos si se ha hecho esta característica?
• Estimado: ¿Cuánto piensa el Equipo que costará esta característica?

En mi opinión, para que una historia se considere completada tiene que tener todas las características descritas anteriormente. Me parece que cuando las personas tienen problemas definiendo todas las características, las historias no están, lo que yo llamo, maduras, es decir, no se ha pensado lo suficientemente bien en ellas para que el Equipo las pueda utilizar. Además de estas características, las historias también deben seguir los criterios INVEST (este gran artículo escrito por J.B. Rainsberger también habla sobre INVEST).

Mike Cohn ha escrito un gran libro sobre historias de usuario. Lamentablemente, a pesar de todo lo bueno que tiene el libro, parece que la gente solo se han centrado en un poco de basura que contiene el libro – la plantilla de la historia de usuario. En su libro, Mike ofrece una plantilla que algunos equipos encontraron útil para escribir historias y a partir de ahí, esta plantilla ha sido la fuente de muchas malas historias y ya no voy a gastar más tinta escribiendo sobre ellas (o partes de ellas). Lo que yo tengo en contra de la plantilla es que causa que las personas dejen de pensar ya que mecánicamente rellenan el rol, la característica y el valor y omiten los criterios de aceptación y la estimación (presumiblemente porque no se encuentran en la plantilla). Cuando veo a la gente batallando con historias, es porque están tratando de meter a la fuerza su negocio en una plantilla que ayudó a algunos equipos que no voy a nombrar (y que probablemente ya no usan esta plantilla) hace cinco o seis años y – ¡sorpresa! – ya no les sirve en el momento en que se encuentran ahora.

Hay un proceso de reflexión que debe ocurrir antes de escribir una sola historia. A continuación se describen los pasos que he visto que tienden a seguir las personas que escriben historias exitosas. Por favor, tenga presente que aunque estos pasos son lineales en mi post, uno puede saltar hacia atrás, hacia adelante y si tiene sentido, también saltarse algunos pasos. El objetivo es haber respondido a estas preguntas cuando haya terminado su exploración de la historia de usuario.

1. ¿Cuáles son los roles (o usuarios) que usará su sistema?
2. ¿Cuáles son sus necesidades? ¿Cómo les ayuda el producto a lograrlas?
3. ¿Qué características (o capacidades) desea proporcionar a estos roles?
4. ¿Por qué son estas características valiosas para el negocio? ¿Qué tipo de resultados del negocio podemos esperar de estas características?
5. ¿Cuáles son las prioridades de estas características? ¿Ya hemos prometido entregar algunas de ellas?
6. ¿Cómo sabe si se hicieron estas características?

Finalmente, las personas tienen una tendencia a querer escribir muchos detalles en la parte delantera de la tarjeta de la historia. Tengo dos sugerencias para estas personas. En primer lugar, usen tarjetas más pequeñas – de verdad. Las historias de usuario son no especificaciones o documentos de requisitos. Son solo tarjetas de índice o fichas para capturar las necesidades del usuario y son un recordatorio de que tenemos que capturar esos detalles de implementación más adelante. Si está tratando de meter más y más en una ficha, podría ser una señal de que podría necesitar especificaciones o algún tipo de documentación de diseño, además de las historias de usuario. En segundo lugar, el tipo de informaciones que las personas están tratando de escribir son realmente los criterios de aceptación. Al poner estos detalles dentro de los casos de prueba, mantenemos la historia en el lenguaje del negocio y mantenemos el foco en la característica y el valor que su Equipo está proporcionando.

Esta enlace va al artículo original en inglés.