Cómo escribir buenas historias de usuario

¿Qué són las historias de Usuarios ágiles? – Presentación

Como ya sabéis, en Apiumhub utilizamos metodologías ágiles y uno de los principales componentes de este tipo de metodologías son las historias de usuario. No es otra cosa que breves inputs que recibimos de los clientes sobre los beneficios que se quieren conseguir con la creación de un nuevo software u otro proyecto. Estas historias de usuarios, se desglosan en pequeñas tareas que no deberían llevar mucho tiempo en ser puestas en marcha. Tareas cortas que puedan ser desarrolladas en uno o varios días y ya listas para el QA, en el caso de que la historia sea muy compleja y pueda llevarnos más tiempo, la desglosamos en varias tareas más pequeñas, todo para que el ciclo de testing empiece antes y nos dé antes feedback acerca de las casuísticas de uso. El tiempo de realización de estas tareas puede verse influenciado por tres factores:

• La necesidad de un gran esfuerzo para poderla llevar a cabo de la manera más fiel posible y consiguiendo la mejor experiencia final del usuario.
• La necesidad de un estudio previo a su puesta en marcha, que puede implicar un retraso en la producción.
• La espera de un feedback externo para aclarar ciertos puntos que nos impiden avanzar.

¿Qué características deben tener las historias de usuario?

Es importante no confundir las historias de usuario con las tareas.

• HITORIAS DE USUARIO: Las historias, deben ser creadas por el cliente (un PO) y siempre pensando en una finalidad del producto.
• TAREAS: Mientras que las tareas, será la manera en que los desarrolladores consigan paso a paso cumplir estos requisitos optimizando los resultados.

Gracias a esta práctica, podemos sensibilizarnos con el producto, entender su misión y en base a esto, tomar unas decisiones u otras además de ganar agilidad en la gestión de problemas ganando perspectiva sobre la estructura de los problemas derivados de la implementación. Por otro lado, no solo se consigue un mayor conocimiento sobre el producto, sino que nos ayudará a mejorar nuestra relación con el cliente (y el programa o lenguaje con el que se ha desarrollado la solución), haciendo que este sea más participativo y dándole la posibilidad de encarrilar el proyecto de una manera específica.

Nos permite crear y evolucionar a la par que el proyecto crece, puesto que las historias no son únicas, sino que en función de la fase de nuestro proceso, se pueden ir reajustando, ya que son pequeñas peticiones que no implican largos períodos de trabajo. Aportan una información imprescindible para poder llevar a cabo proyectos únicos y mejorar el marco de trabajo puesto que hace partícipe de una forma mucho más íntima a los miembros de equipo.

Evaluando las características de las historias de usuarios y su aplicación en una metodología ágil podríamos decir que es un proceso que consta de tres fases:

1. En primer lugar, el cliente nos hará llegar un pequeño escrito con las funcionalidades que considere necesarias, de forma esquemática. Básicamente nos manda casos de uso reales y problemas que piensa que debería resolver nuestro programa sin entrar en detalles técnicos como estructura o lenguaje de la implementación.
2. A posteriori, se hace una reunión de equipo, donde se establecen prioridades y se le da feedback al cliente, de manera que nos aclara cómo poder resolver según qué situaciones o poder hacer consultas sobre puntos incoherentes de las historias creadas. Además se evaluaran requisitos y se tendrá en cuenta en la planificación. También se traducirán los casos de uso del cliente a un lenguaje más técnico en la que se evalúen frameworks, lenguajes y funciones que debería contemplar la solución para tener una perspectiva más realista del proceso.
3. Por último, la comprobación y validación de que una historia de usuario se ha creado con éxito.

Las buenas Historias de Usuario (User Stories) son un elemento clave en la metodología Agile – es a través de ellas que definiremos las funciones de la aplicación que estamos creando. La metodología Ágil se basa en el principio de que las especificaciones de un proyecto deberían ser fáciles de entender y mantener. El sistema de gestión de proyectos Waterfall, que era el más común antes de la irrupción de la metodología Agile, era extremadamente complejo: IEEE Ansi 830 (1993, Rev 1998). Los principios de desarrollo agile o ágil cambiaron esta práctica a favor de las historias de usuario (HdS). Las HdS no son tan exhaustivas como los requerimientos clásicos, pero la información que ofrecen tiene mucho más sentido, ya que una historia de usuario define una funcionalidad dando una perspectiva más útil y real sobre los problemas que resolverá la aplicación. Puedes revisar documentación que hemos elaborado sobre SCRUM o KANBAN dos de los frameworks agiles más famosos del mundo del software. En el marco o framework scrum estas historias se materializan en sprints (períodos cortos en los que se van cerrando tareas). En el marco KANBAN, sin embargo, las historias de usuarios se introducen en una especie de backlog dónde más tarde se priorizan para lograr una estimación y planificación del proyecto. Puedes ponerlos en práctica con herramientas como JIRA o TRELLO. O también puedes ver otras herramientas agiles si te interesa esta temática.

¿Por qué se necesitas elaborar historias de usuarios?

Las buenas historias de usuario deben ofrecer un actor, un objetivo, un contexto, una motivación y una forma de validarla – y debe permitir al product manager, al usuario y al desarrollador elaborar y discutir sobre ella de cara a poder crear el valor deseado. Es por eso que son tan útiles. Al desarrollar una historia de usuario debe quedar muy claro que estamos delante de una entidad viva, y que empieza con una propuesta inicial initial para abrir el diálogo entre cliente, manager y equipo de producto. El hecho de que en muchas ocasiones este diálogo no tiene lugar no debe llevarnos a la falsa creencia de que una historia de usuario es inmutable durante todo el proyecto.

Cómo escribir buenas historias de usuario – MODELO INVEST

Los modelos de desarrollo basados en buenas historias de usuario son menos exhaustivas pero son una gran ayuda a la hora de definir el set de funcionalidades que se deben implementar desde el punto de vista del usuario, es decir, para que el resultado de nuestro software cumpla con las necesidades reales del cliente. Preferiblemente, buenas historias de usuario deberían seguir el modelo INVEST:

• “I” Independiente – Independiente de otras historias de usuario. Una historia no depende del resto de historias, de forma que se pueden clasificar por prioridad, como se desee, pues no tienen un orden lógico.
• “N” Negociable – Deben existir diálogos entre el cliente y el equipo de desarrollo, flexibilidad, no es un contrato cerrado. Las historias como tal, en su primera fase, son ideas, o conceptos, pero se deben desarrollar en la fase de comunicación.
• “V” Valiosa – Cada historia de usuario debe añadir valor al producto, usuario, cliente o comprador.
• “E” Estimable – El esfuerzo requerido por cada historia de usuario debe poder expresarse de manera más o menos objetiva (tiempo o puntos de historia – complejidad). Una vez finalizada la conversación debemos poder estimar las historias, si no son estimables será necesario una segunda puesta en común.
• «S» Small (Pequeña)- Cada historia de usuario, idealmente, debería caber en una iteración (sprint). En caso contrario, se sugiere trocearla en partes más pequeñas. Una buena historia debería poderse realizar en una semana, por lo que no suelen ser extensas.
• «T» Testeable – Cada historia de usuario debe poder ser validada. Es necesario probar una historia para ver si se ha resuelto con éxito.

Requisitos de una tarjeta – Presentación

Las tarjetas forman parte de la primera entrega de la historia de usuario, donde se especifica de manera escueta la necesidad a tratar en el sprint, no sólo deben ser breves y precisas, sino que deben responder a tres preguntas que normalmente se sitúan en el reverso de la tarjeta.

• ¿Cómo quién? Donde se especifique el tipo de usuario para quién se hace la funcionalidad.
• ¿Qué? Aclarando cuales son los objetivos a los que tenemos que enfrentarnos.
• ¿Para qué? Definiendo el motivo del lado de negocio por el cual se ha creado la historia.

Además se puede incluir una nota de prioridad para tener una visión global de la importancia de cada tarjeta.

Desventajas de las historias de usuario

No todo son ventajas, aunque si es verdad, que los pocos inconvenientes que tienen estas prácticas, son fácilmente solucionables.

• Es difícil de medir la eficacia de un proyecto con los resultados de una historia, aunque estos hayan sido positivos, pues necesitaremos una visión más global para poder clasificar un proyecto terminado como correcto.
• Necesitaremos desarrolladores cualificados que tengan una visión muy clara sobre sus posibilidades y cómo conseguir objetivos a corto plazo, puesto que las historias se desglosan en pequeñas tareas.
• Para poder asumir la escalabilidad de un proyecto grande, necesitaremos de profesionales, pues las historias nos dan pistas, pero es necesario tener visión a largo plazo para agrupar las historias y ofrecer datos más precisos.
• Es necesario un continuo feedback con el cliente para resolver posibles dudas o incluso para ir agregando historias a nuestros sprints.

Partes de una Historia de Usuario – PLANTILLAS

Las buenas historias de usuarios están formadas por las siguientes partes:

• Título
• Descripción
• Criterios de aceptación
• Discusiones posteriores

¿Cómo debe ser el título de una Historia de Usuario?

El título de una historia de usuario sigue la siguiente fórmula:

• COMO <rol>
• QUIERO <objetivo>
• PARA <motivación>

Las historias de usuario definen una funcionalidad, pues en una sola frase debe quedar claro QUIEN (rol) hará una ACCIÓN (objetivo) para satisfacer una NECESIDAD (motivación). La plantilla que deberías seguir para elaborarlas tendría esta pinta: “Como [perfil], [quiero] [para].”

Ejemplos de historias de usuario (aplicables a SCRUM/KANBAN):

COMO usuario QUIERO poder buscar transacciones PARA poder detectar gastos innecesarios en mi cuenta durante cierto periodo de tiempo Ejemplo Historia de Usuario 1 – Transacciones

• ROL: Usuario
• OBJETIVO: Poder buscar transacciones
• MOTIVACIÓN: Detectar gastos innecesarios en mi cuenta durante cierto tiempo

COMO usuario QUIERO poder acceder a la agenda de enfermería PARA utilizar sus funcionalidades Ejemplo Historia Usuarios 2 – Agenda

• ROL: Usuario
• OBJETIVO: Poder acceder a la agenda
• MOTIVACIÓN: Utilizar funcionalidades

El título de una historia de usuario debe mapear una funcionalidad de nuestro producto o software. Cuando escribimos historias de usuario, es una buena práctica el usar personajes en vez de roles, ya que dan incluso más contexto. Por ejemplo:

COMO usuario QUIERO ser capaz de mostrar la lista de visitas PARA poder gestionar la llegada de pacientes y de salas de espera

vs:

COMO enfermera QUIERO ser capaz de mostrar la lista de visitas PARA poder gestionar la llegada de pacientes y de salas de espera

Con el simple cambio de “usuario” a “enfermera” estamos dando mucho más contexto a nuestra historia de usuario y la hacemos mucho más legible para cualquier persona sin background técnico. Debemos recordar que el título de una historia de usuario debe mapear una sola funcionalidad de nuestro producto o software.

En este otro artículo profundizamos sobre diferentes ejemplos de historias de usuario en el desarrollo de software. Te animamos a leerlo.

Descripción Historia para que sea útil en equipos que utilizan el método Kanban/Scrum

La descripción de una historia de usuario ayuda a dar contexto a dicha historia. Ésta puede contener una pequeña explicación de los user flows, algunos casos de uso y casos extremos y, en general, cualquier explicación que ayude a comprender mejor el título. La descripción no es una biblia, y recordemos que una imagen es mejor que mil palabras: elementos como links a páginas con diseños o capturas de pantalla que ayuden a clarificar lo que se está expresando son siempre bienvenidos. Una buena descripción contendrá, a ser posible, estos elementos:

• Contexto: Proveer contexto de uso y aplicación para el desarrollador y el usuario, de cara a mejorar la comprensión del título.
• Links a mockups o diseños: Resultan de gran ayuda de cara a comprender cómo mapear la funcionalidad de la historia de usuario en la aplicación.
• Limitaciones: Elementos que todos los actores involucrados en la historia de usuario deben tener en cuenta (limitaciones de navegación y de diseño, requisitos, productos involucrados o reglas de negocio).

Criterios de aceptación en historias de usuarios de la metodología Ágil – Ejemplos

Junto con el título, la parte más importante de una historia de usuario. Los criterios de aceptación son una serie de preceptos que validan la implementación de nuestra historia de usuario. Incluso a día de hoy hay equipos que no utilizan criterios de aceptación – En mi opinión, esto es un grave error. Los criterios de aceptación son fundamentales, pues:

• Ayudan al desarrollador a implementar la tarea de forma correcta
• En TDD los criterios de aceptación se mapean de manera directa sobre tests funcionales
• Siguiendo TDD de forma estricta, la implementación debería empezar con estos criterios
• Ayudan a equipo de QA de cara a dar el OK a considerar finalizada la historia de usuario
• Los criterios de aceptación deben definir juntamente con el título la funcionalidad a implementar

El equipo de QA, idealmente, debería validar que se dan todos los criterios para dar el OK a subir a producción. En general, los criterios de aceptación deben cumplir las características siguientes:

• Atomicidad: Deben tener 2 resultados únicos: ÉXITO o FRACASO (no hay “éxito parcial” – un criterio de aceptación debe dar siempre verde o rojo).
• No Ambiguos: Deben ser interpretados de única manera por N personas (algo como “el formulario debe tener un color alegre” no es válido. . .aunque cosas peores se han visto)
• Verificables: Deben estar escritos de forma que el cliente los pueda verificar rápidamente
• Completos: El grupo de criterios de aceptación debe incluir todos los requisitos funcionales

Ejemplo:

COMO usuario QUIERO acceder a la agenda de enfermería de forma segura PARA usar sus funcionalidades

Criterios de aceptación:

• El nombre de usuario DEBE tener valor, en caso contrario se mostrará el mensaje de error pertinente
• El nombre de usuario DEBE tener forma de email, en caso contrario se mostrará el mensaje de error pertinente
• La contraseña DEBE tener valor, en caso contrario se mostrará el mensaje de error pertinente
• El nombre de usuario DEBE existir en la base de datos en caso contrario se mostrará el mensaje de error pertinente
• La contraseña DEBE coincidir con la que el nombre de usuario tiene asociada en la base de datos, en caso contrario se mostrará el mensaje de error pertinente

Si el usuario y la contraseña son correctos, el usuario podrá acceder a la aplicación. Muchas veces estos criterios de aceptación pueden parecer triviales o innecesarios, pero ser riguroso con ellos mientras redactamos las historias de usuario es la mejor manera de desarrollar la funcionalidad

Discusiones posteriores con usuario final

Alguien definió las historias de usuario como “una invitación a una conversa”. En un mundo ideal, con unicornios y arcoíris, tendríamos clientes estupendos con una idea súper clara de lo que quieren desde el principio y nos lo contarían con todo lujo de detalles sin dejarse nada en el tintero. Pero eso no pasa. Nunca. Una historia de usuario abrirá normalmente una conversación entre el equipo de desarrollo/PO y el cliente. Normalmente, las historias de usuario no cambian a nivel conceptual, y son estas conversaciones las que las volverán más detalladas. Lo mismo ocurre con los grupos de criterios de aceptación. Espero que te haya servido de ayuda este artículo y que a partir de ahora pongas en práctica metodologías ágiles y puedas trabajar cómodamente con las historias de usuario.