Historias de usuario, algo más que una definición funcional

En el curso de un proyecto ágil, hacemos un fuerte empeño en la necesidad de que el equipo pueda enfocarse en un objetivo de valor pequeño (mejor dicho, asumible por el equipo).

Esto permite al equipo aislarse de la complejidad a menudo inalcanzable del producto completo, y centrarse en proporcionar un MPV (Mínimo Producto Viable) verdaderamente útil para la organización.

Para llegar a este objetivo de trabajo primario en agilidad, existe el concepto de historia de usuario. La historia de usuario proporciona una herramienta poderosa a la vez que extremadamente sencilla para negociar una necesidad concreta con los stakeholders.

Si necesitáis un recordatorio de las claves de la metodología Agile, aquí tenéis un artículo al respecto.

CCC. Card. Conversation. Confirmation

Las historias de usuario siguen un principio muy sencillo propuesto por Ron Jeffries (Essential XP: Card, Conversation, Confirmation (ronjeffries.com)) en el año 2001. Y que, hay que decirlo, es una buena práctica inicialmente pensada para otro marco de trabajo ágil muy conocido: XP

Ron Jeffries establece el principio donde las historias de usuario han de ser CCC:

• Card (tarjeta): La historia de usuario ha de poder definirse en una tarjeta de tamaño reducido. Esto permite a todas las partes fomentar la siempre deseable capacidad de síntesis, a la vez que nos permite centrarnos en lo que realmente es importante. La necesidad debería poder explicarse de forma sencilla en unas pocas líneas. Si esto no es posible, quizás estamos intentando explicar una necesidad demasiado compleja que debería dividirse.
• Conversation (conversación): Lo escrito en la historia no es el producto del trabajo en solitario de un técnico, de un Product Owner o de un usuario. Ha de ser el producto de una conversación de valor entre todas las partes interesadas. Una conversación de valor significa, entre otras cosas, contar con la participación activa de las personas adecuadas para intentar garantizar la correcta comprensión de la necesidad y su viabilidad. Esto implica tanto a técnicos cómo a stakeholders. Y recordemos que los stakeholders no son únicamente usuarios.
• Confirmation (confirmación): Usualmente, conocer en detalle la necesidad no es garantía de que esta será finalmente construida con la calidad esperada. Hemos de incluir una descripción de cómo consideramos que aquello finalmente construido proporciona el valor que buscamos. Es lo que se conoce cómo criterios de aceptación. Y esta labor es responsabilidad del negocio (no de los técnicos). No es suficiente explicar detalladamente la necesidad. También hemos de incluir una descripción de cómo consideramos que aquello finalmente construido proporciona el valor que buscamos.

Como se puede observar, la definición de una Historia de Usuario, tiene su estructura y seguirla hará más fácil a todos los interlocutores y participantes del proyecto su comprensión. ¿Y os podéis preguntar, cómo se redacta? ¡Nada más fácil! De manera genérica y para facilitar las cosas, podemos seguir el siguiente patrón:

Definition of Ready

Del último aspecto de este sencillo principio (confirmation), probablemente seremos conscientes de una gran verdad en proyectos complejos:

No es suficiente comprender la necesidad para construir una solución

Seguramente, para ser realmente eficientes y proporcionar un incremento de valor con calidad, necesitamos tener cobertura de otros aspectos necesarios. Y aquí aparece el concepto de DoR – Definition of Ready (Definición de Listo). La Definition of Ready se puede entender cómo un acuerdo en el Scrum Team, en que el equipo define los elementos informativos o las condiciones que una historia de usuario debe contener para que el equipo considere construirla. Y está claro que no es suficiente con una descripción de la necesidad.

Estos elementos probablemente son dependientes del tipo de proyecto o la complejidad de la propia organización. Pero a menudo podemos determinar algunas condiciones comunes a la mayoría de los proyectos. Algunos ejemplos:

1. La necesidad debe estar descrita de forma comprensible y suficiente.
2. El equipo técnico debe haber estudiado esta necesidad. Complementando informativamente esta descripción de la necesidad y, si fuese necesario, habiendo tenido una Refinement con el usuario o el Product Owner para asegurar la comprensión.
3. El Product Owner deba haber priorizado la historia de usuario para que el equipo la pueda considerar una prioridad de construcción para el siguiente Sprint.
4. El usuario, o en su defecto el Product Owner, debe haber incluido en la historia de usuario los criterios de aceptación, que son los elementos que conforman el principio de confirmation

Si la historia está “ready” en lo referente a la presencia de todos estos elementos y otros que pueda considerar necesarios, solo queda una acción importantísima para al funcionamiento óptimo y eficiente del equipo, que es la estimación en esfuerzo de las historias de usuario. Con esta actividad el equipo técnico determina el peso de la historia en la variable de la complejidad. Y esto ayuda a la hora de determinar la capacidad o la carga de trabajo del equipo en cada Sprint.

¿Quieres más información? Consulta nuestros servicios y déjanos asesorarte en todo aquello relacionado con una transformación Ágil efectiva. O si lo deseas, te podemos ofrecer una consultoría Agile sin coste para ayudarte en la transformación de tu empresa.