En el anterior post estuvimos viendo los problemas más comunes que nos encontramos cuando nuestras historias de usuario no cumplen los principios de una buena historia de usuario, que recordemos son:

  1. Está enfocada a aportar valor al usuario
  2. Está bien definida y estructurada
  3. Es lo suficientemente auto explicativa para que exista el mínimo número de dudas funcionales y técnicas posibles

En este post hablaremos sobre los principios y técnicas que nos ayudarán a definir, estructurar y desarrollar una buena historia de usuario.

Los conceptos y técnicas vistos aquí son simples recomendaciones. Son las técnicas más usadas en la mayoría de equipos, pero eso no quiere decir que nuestro equipo de desarrollo use otra nomenclatura o forma de uso, siempre que se adapte a las necesidades del equipo, y siempre que se cumplan con los principios anteriores.

Principios útiles

Hay dos principios muy útiles que nos van a ayudar a definir una HU de forma correcta:

  • Principio CCC: Cómo estructurar una buena HU.
  • Principio INVEST: Características principales de una buena HU.

CCC

Vamos a empezar estructurando correctamente nuestras historias de usuario.  Este concepto que proviene de la metodología Extreme Programming (XP), como muchos de los conceptos de Scrum (Differences between scrum and extreme programming – Mike Cohn), que nos cuenta los aspectos más críticos a la hora de estructurar nuestras historias de usuario, de forma que incida en los principios de aporte de valor al usuario, colaboración por parte de todo el equipo y favorecer la estimación y la priorización de las historias.

Empezaremos siempre definiendo el Card (primera C), tal y como hemos hecho anteriormente.

Ejemplo:Yo como usuario de la aplicación móvil, necesito poder hacer transferencias seguras con la huella del teléfono para poder enviar dinero de forma segura y rápida”

 

Esto hará además que demos un contexto de en qué consiste la historia, sin ni siquiera necesitar entrar en el detalle de la misma (es muy útil cuando estamos priorizando nuestro backlog a vista de pájaro).

La segunda C habla de Conversation (y va muy unido a la N de INVEST que veremos ahora) y trata de que la HU es un concepto en constante cambio, es decir, que es negociable (incluso durante su desarrollo), y que aquí se expresan todas las conversaciones que han ocurrido para dar contexto a la historia. Conversaciones funcionales y técnicas, es decir, todo lo que ha hablado el PO con el usuario, lo que ha hablado el líder técnico con el equipo, lo que han hablado todos en una sesión de refinamiento… En resumen, todo lo que se considere útil y necesario para describir la HU. El objetivo de esta parte es que surjan el menor número de dudas técnicas y funcionales durante el desarrollo, y sirva como documentación funcional del proyecto.

La tercera C, y para mí la más importante de todas, es la de Confirmation, es decir, qué criterios de aceptación debe cumplir la historia de usuario para cubrir todos los requisitos funcionales (de hecho, podrían estar enunciados por el propio usuario, aunque normalmente es el PO el que las enuncia). Suele representarse con el lenguaje Gherkin (given-when-then):

Ejemplo: “Comprobar que, dado un usuario que quiere entrar en la aplicación, cuando intenta introducir los credenciales con los datos correctos, el sistema le dejará pasar y accederá a la página principal

 

Crearemos tantos criterios de aceptación como sean necesarios para cubrir todos los casos de prueba de la HU. Estas comprobaciones nos ayudarán a:

  • Definir el ámbito de la HU. Esto nos ayudará a estimarla.
  • Definir los diferentes flujos de ejecución (caso feliz y casos de error). De hecho algunas HU suelen llevar algunos adjuntos (diagramas de actividad, de secuencia, etc.) que clarifiquen estos flujos de ejecución.
  • Nos van a ayudar a definir los tests de nuestra aplicación en base a specification by example:


arrow

Más info: https://www.agilealliance.org/glossary/three-cs

INVEST

Este acrónimo describe las características que debería tener toda HU bien definida. Se describen a continuación sus siglas:

I: Independent -> La HU debería ser lo suficientemente independiente a nivel funcional como para ser abordada de principio a fin sin dependencias con otras HU. Nos recuerda un poco a la I del principio FIRST de los test unitarios. Esto no siempre se cumple, es posible que surjan dependencias entre HUs que no se puedan solucionar de forma sencilla. En estos casos tenemos que relajar el concepto de independencia de HUs.

N: Negotiable -> La HU está en constante negociación, desde su ideación hasta su finalización. Con esto rompemos el concepto de contrato que comenta el agile manifesto.

V: Valuable -> La HU debe aportar valor a alguien. Si no, no es una HU o no está bien planteada.

E: Estimable -> Debemos poder ser capaces de dar una estimación a la HU. Si existen tantas incertidumbres que no podemos estimarla, tendremos que refinarla antes.

S: Small -> La HU nos debe entrar en un sprint (2-4 semanas de desarrollo, depende de las necesidades del equipo). Con esto haremos un aporte de valor seguro cada finalización de sprint, que es la base del agilismo (modelo iterativo e incremental). Si la HU es demasiado grande y no entra en un sprint, deberíamos dividirla en varias HU más pequeñas.

T: Testable -> La HU debe poder probarse dentro de nuestro sistema.

SMART

Este acrónimo nos puede servir tanto para HU como para subtareas. Para no extender más el post, os dejo el enlace para que le podáis echar un vistazo: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Patrones de división de HU

Por último, es muy buena práctica saber identificar cuándo una HU debe ser dividida en varias, sobre todo para cumplir con la I y la S de INVEST. Una HU será susceptible de ser dividida cuando:

  • Tenemos conjunciones y conectores: Una HU que se enuncie como “Yo como usuario quiero poder buscar mis productos y quiero poder obtener su información detallada para poder visualizarlos”. Se podría dividir claramente por la conjunción “y” en dos HU:
    • “Yo como usuario quiero poder buscar mis productos para poder acceder a ellos de forma más sencilla”
    • “Yo como usuario quiero poder obtener la información detallada de los productos para poder conocer todas sus características”

Si os fijáis, la parte del ‘para’ ha cambiado en las nuevas HU. El poder dividirlas hace que enfoquemos el ‘para’ de forma más precisa.

  • Tenemos palabras genéricas: Podemos encontrarnos con “Yo como usuario quiero obtener información de mis productos”. Sí, pero… ¿qué información? Seguramente cuando refinemos esta HU, nos salgan varias relacionadas con el tipo de información que queremos sacar de nuestros productos.
  • Tenemos un flujo de trabajo bien definido: Una HU que se enuncie como: “Yo como usuario de la aplicación quiero acceder a la aplicación a través de un login, luego poder contratar una tarjeta, y luego poder hacer transferencias”. Esta HU se podría dividir en los tres pasos de los que consta el flujo.
  • “Yo como usuario de la aplicación quiero acceder a la aplicación a través de un login, para poder acceder de forma segura”
  • “Yo como usuario de la aplicación quiero poder contratar una tarjeta, para poder realizar pagos con la misma”
  • “Yo como usuario de la aplicación quiero poder hacer transferencias, para poder enviar dinero a otras cuentas”
  • Tenemos muchos criterios de aceptación: Esto nos da indicios de que la HU está cubriendo demasiados casos de prueba, y es posible que cubra varias funcionalidades que puedan ser divididas

No todo es una historia de usuario

Ok, ya tenemos entendido cómo estructurar y definir una buena historia de usuario, pero… ¿qué pasa si estamos abordando un requisito no funcional (mejora de performance en nuestro sistema, refactorización, deuda técnica, instalación de sistemas, etc.)?

La mejor forma de definir tareas que no aportan valor al usuario final, como Chores (tareas técnicas) o Spikes (tareas de investigación) es mediante la notación definida del desarrollo basado en funcionalidades (o FDD):

<acción> <resultado> por|para|de|a <objeto>

Por ejemplo:

 

“Mejorar el rendimiento de la consulta de DNIs de cliente”
<acción> <resultado> <objeto>

 

Más información: Not Every Needs to Be a User Story: Using FDD Features – Mike Cohn

Conclusiones

Llegados hasta aquí, con estos principios y prácticas podemos definir buenas historias de usuario, que hagan que se cumplan los siguientes criterios:

  • La HU estará definida para dar un aporte de valor al usuario, que es en el que nos tenemos que centrar en todo momento en desarrollo de las funcionalidades de nuestro sistema.
  • La HU tendrá las mínimas dudas posibles, es decir, le quedará claro a todo el equipo antes de empezarla, y podrá ser asumible por cualquier miembro del equipo (esto es parte de otro concepto que deberíamos tener en cuenta en nuestras HU: Definition of Ready
  • La HU se podrá terminar a tiempo en el sprint actual, siempre cumpliendo nuestro Definition of Done
  • La HU tendrá un nivel de aislamiento que permita estimarla de forma adecuada y desacoplarla de otras HU para poder hacer una entrega continua e incremental de valor.

Podéis seguir más artículos, noticias y datos interesantes en https://www.ingtechit.es y en mi cuenta de Twitter