La historia de usuario no es el santo grial que muchos creen, sino un contenedor que sirve como recordatorio de una conversación entre el Product Owner y el Development TeamUna historia de usuario es una promesa para mantener una conversación. Contrariamente a lo que mucha gente cree, el Product Backlog en Scrum está poblado por muchos tipos de requerimiento y solamente uno de ellos son las historias de usuario.
Es más acerca de la conversación que de la historia de usuario en sí misma. La conversación es lo que da las razones inherentes en la historia de usuario a lo que hay que hacer en el producto. La historia de usuario es únicamente un recordatorio de esa conversación.
Las 3 C’s de la historia de usuario
Los elementos fundamentales de una historia de usuario son la Tarjeta (Card), la Conversación (Conversation) y Confirmación (Confirmation). Estos tres elementos son más importantes que cualquier detalle que pongamos en la historia de usuario en sí misma, y componen los elementos fundamentales de la historia de usuario. Sin ellos, la historia de usuario no está completa.
Tarjeta (Card): La tarjeta refleja los elementos más importantes de la historia de usuario. Expresa el valor que se quiere conseguir desde el punto de vista del usuario. Expresar un historia de usuario desde el punto de vista del desarrollador (As a developer I want…) o desde la organización (As the organisation I want to…) es una mala práctica que refleja la incapacidad de pensar en el valor para el usuario final.
Conversación (Conversation): Después de escribir la historia de usuario en la tarjeta, es necesario tener una conversación al respecto de su contenido. Hay que saber responder a cuestiones sobre el valor y sobre el resultado esperado de la implementación. Esta conversación puede suceder en cualquier momento; es habitual que se produzca durante el refinamiento del Backlog o el Sprint Planning.
Confirmación (Confirmation): La confirmación es un acuerdo que refleja que todas las personas implicadas, Product Owner y Development Team, entienden cuales son los elementos, valor y resultado esperado de la historia de usuario. Muchos equipos cometen el error de no tener esta confirmación, lo cual lleva a fricciones y problemas durante el Sprint Planning.
Modelo de historia de usuario
Una historia de usuario generalmente sigue un patrón definido
As a... Persona para la que se cubre una necesidad
I want... lo que queremos que ocurra, por ejemplo una características o una funcionalidad
So that... el valor que obtiene la persona de la implementación de la característica o funcionalidad.
En la primera parte de la historia de usuario, es muy útil hacer referencia a usuarios de nuestro producto, usuarios que estén descritos y estudiados usando el modelo de User Personas, que toman una serie de rasgos de múltiples usuarios y construyen una persona ficticia que haga uso de la aplicación.
En la segunda parte de la historia de usuario, se explica lo que desde el punto de vista de la persona debería de suceder, sin entrar en descripciones técnicas. Una buena historia de usuario no tiene en cuenta lo que el sistema puede hacer, sino lo que el usuario quiere obtener.
Una historia de usuario está totalmente centrada en el usuario, y no en el producto o la organización.En la tercera parte, se expresa el valor que la persona quiere obtener, lo cual ayuda a entender y refinar, o incluso cambiar la forma en la que usuario obtiene el valor esperado.
Como se puede comprobar, las historias de usuario están totalmente alineadas con la expectativa del usuario, sin tener en cuenta capacidades o restricciones de nuestro producto. Una buena historia de usuario es aquella que está construida sobre datos reales, obtenidos de los propios usuarios.
Vanesa Tejada tiene una gran presentación sobre como escribir historias de usuario
Criterios de Aceptación
Los criterios de aceptación son los detalles de una historia de usuario, y ayudan a completar el patrón de valor expresado por la misma. Los criterios de aceptación incluyen los detalles que ayudan a visualizar la película completa y mejoran el entendimiento que el Product Owner, los Stakeholders y el Development Team tienen sobre lo que se va a realizar.
Los criterios de aceptación cumplen dos funciones: Clarificar el contexto en el que ocurre la historia de usuario y facilitar saber cuando están realmente terminadas.Los criterios de aceptación también son el medio por el cual el Development Team es capaz de saber cuando un ítem del Product Backlog está terminado, y ser capaces de testar los elementos de la historia de usuario en conjunto.
Unos buenos criterios de aceptación son claros, concisos, expresan una sola cualidad del ítem del Product Backlog y en la mayoría de ocasiones son redundantes, explicando desde múltiples puntos de vista cual es la imagen finalizada de la historia de usuario.
Además, pueden contener requerimientos no funcionales, si estos no están recogidos en la Definition of Done del equipo, como velocidad de la aplicación, concurrencia o elementos de seguridad que deben ser implantados para considerar la historia de usuario terminada.
Specification by example
Otro elemento que puede resultar de ayuda en una historia de usuario es expresar los resultados deseados mediante un ejemplo, que ayude a entender al Development Team cual es el resultado deseado al implementar una historia de usuario.
No solamente es válido para Algoritmos, sino que también puede ser muy útil en el caso de implementación de diseños en un producto ya existente. Herramientas como InVision ayudan a los especialistas en UX/UI a diseñar flujos en una aplicación que posteriormente pueden ser implementados como especificaciones en el producto final, siendo uno de los criterios de aceptación que la UI del producto sea cómo la del diseño inicial.
También puedes leer más sobre Specification by Example en el blog de Martin Fowler.
Brillante post.
Soy estudiante de Testing de Software en el Centro de Ensayos de Software del Uruguay, y realmente tu trabajo me resultó sumamente esclarecedor.
Gracias por la generosidad de compartir tu conocimiento.
Un abrazo desde Uruguay.
El esfuerzo por explicar es destacable y se agradece, pero, faltan ejemplos, y en castellano. No se trata de copiar ejemplos de otros y sin traducir. De esta manera la explicación cae en saco roto.
Brillante post.
Soy estudiante de Testing de Software en el Centro de Ensayos de Software del Uruguay, y realmente tu trabajo me resultó sumamente esclarecedor.
Gracias por la generosidad de compartir tu conocimiento.
Un abrazo desde Uruguay.
El esfuerzo por explicar es destacable y se agradece, pero, faltan ejemplos, y en castellano. No se trata de copiar ejemplos de otros y sin traducir. De esta manera la explicación cae en saco roto.
Jeronimo, una pregunta filosófica.
Me estoy capacitando en metodologías ágiles, porque creo que puede ser una metodología de planificación u organización del trabajo y de trabajar útil en cualquier ámbito, pero soy entrenador de rugby.
En tu perfil pones que te encanta el rugby.
¿que similitud encontras entre el scrum de rugby y la metodología scrum?
¿has podido transferir elementos del rugby a la cultura de equipos de trabajo ágiles?
Saludos
Hola, los criterios de aceptación deben contener detalles técnicos ??
Depende, Valentina. Es una decisión del Scrum Team. Hay Product Owners más pegados a la descripción técnica y otros más pegados al negocio. Conforme el equipo Scrum madura, debería de hacerse más propietario de este tipo de detalles