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 MVP verderamente ú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.

CCC. Card. Conversation. Confirmation

Las historias de usuario siguen un principio muy sencillo propuesto por Ron Jeffries 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: La historia 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: 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 necessidad y su viabilidad. Esto implica tanto a técnicos cómo a stakeholders. Y recordemos que los stakeholders no son únicamente usuarios.
• Confirmation: Usualmente, conocer en detalle la necesidad no es garantia 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).
• Confirmation: 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.

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

Probablemente, 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 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 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 Prduct Owner para asegurar la comprensión.
3. El Product Owner deba haberla 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.