Scrumízate
La eliminación de las tareas y tratar sólo con historias puede ser uno de los puntos más complicados en la aplicación de las metodologías ágiles. Definir las historias de usuario es una buena práctica en Scrum. Deshacerse de las tareas clásicas es complicado, necesitamos cambiar la forma en la que describimos el trabajo a realizar.
¿Qué son las historias de usuario?
Primero vamos a dejar claro el concepto de historia de usuario.
Definimos historia de usuario como la menor unidad de trabajo, que se expresa como un beneficio para los usuarios. Habitualmente las escribimos utilizando la siguiente sintaxis:
Como [personaje], quiero [conseguir algo] para [producir un beneficio]
En las metodologías ágiles, y también en Scrum, las historias de usuario nos sirven para definir las características y funcionalidades de nuestra aplicación. En las metodologías ágiles las historias de usuario nos dan sentido al trabajo que se hace. Crear buenas historias de usuario nos ayuda a que todos los implicados puedan tomar las decisiones correctas durante la ejecución del trabajo.
Si te interesa entender cómo las historias de usuario te pueden ayudar en la definición de un proyecto o en la creación de su mínimo producto viable puedes leer este artículo, en el que comparamos los casos de uso tradicionales con las historias de usuario.
El origen del problema
Cuando nos ponemos a elaborar la lista de lo que tenemos que hacer nos resulta muy tentador limitarnos a escribir una lista de ítems, muchas veces muy poco definidos y muy genéricos. Cuando esta lista cae en manos de un equipo que no se siente implicado en la confección de la lista de su trabajo ni conoce los objetivos, tampoco se sentirá implicado en la toma de decisiones durante el trabajo.
Las historias de usuario en Scrum nos sirven para generar motivación al equipo sobre el trabajo a realizar. Seguro que a todos nos puede resultar familiar una situación en la qué nos han asignado una tarea y no entendemos el porqué. Cuando te encuentras en esta situación, realizas el trabajo pero desconoces el motivo. Realizar tares sin saber el porqué genera estas dos reacciones:
- No entender el motivo del trabajo provoca que cuando lo hacemos no sabemos qué enfoque es el qué se está buscando. Es muy fácil que nazca dentro del equipo el sentimiento que se le ha encargado un trabajo de relleno.
- La dirección se puede sorprender de cómo puede ser que el equipo no se sienta motivado con el trabajo que realiza y que no entienda porqué se hacen ciertas cosas o se toman algunas decisiones.
Podemos afirmar que tenemos un problema de mala comunicación y de desinformación. Se trata de una situación en la qué cómo equipo no estamos recibiendo, o no nos están proporcionando, la información suficiente para realizar el trabajo correctamente.
Como seres humanos tenemos la capacidad de comprender personajes, deseos y motivaciones. En cambio, nos es mucho más complicado intentar abstraer partes sueltas de una línea argumental y tratarlas de ligar fuera de contexto. Es mejor conocer el motivo por el que se hace el trabajo que tener que descubrirlo enlazando tareas disconexas.
Historias de usuario cómo parte de la solución
Para conseguir que todo el equipo esté alineado en el trabajo que se debe realizar y que conoce los motivos por los que se hace, necesitamos convertir las tareas en historias. Las historias tienen un personaje que necesita alguna cosa para un beneficio. Comprendiendo los tres elementos sabemos porqué realizamos un trabajo.
Cuando empezamos a considerar una tarea lo primero en lo que tenemos que pensar es en el personaje o el rol de la persona. Para centrarnos en el personaje lo mejor es responder a las siguientes preguntas:
- ¿Para quién se está haciendo esa tarea?
- ¿Con qué lentes, entre todas las ópticas que existen en el mundo, debemos mirar para fabricar esta cosa?
El siguiente punto a comprender es el qué. Bajo la óptica tradicional de generar listas de tareas, este es el punto en el que se concentra el trabajo de la mayoría de la gente. Aquí empiezan y acaban su trabajo en la elaboración de la lista de tareas a realizar. En realidad este punto sería solo la mitad del trabajo.
Finalmente debemos pensar cual es la motivación de ese trabajo. En cierto modo, esto es la clave de todo. Sin saber esto no podemos construir la solución. Para ello recomendamos responder a estas preguntas:
- ¿Para qué le servirá?
- ¿Cómo va a complacer este trabajo a nuestro cliente?
A modo de ejemplo vamos a ver como estas tres partes de una historia de usuario nos modifica el resultado o solución al problema.
Primero, nos vamos a imaginar una historia de usuario que acaba de la siguiente manera:
... quiero un coche para poder ir a trabajar.
Si nos imaginamos ahora quien es el personaje de esta historia, podríamos imaginar estos dos inicios:
- Como persona que vive en las afueras de la ciudad...
- Como granjero que vive en un pueblo rural...
Nos encontramos que según el personaje con el qué escribimos la historia de usuario podemos hacer interpretaciones distintas de lo que podría ser el vehículo ideal para esa persona. Con este ejemplo de historia de usuario podemos entender todas sus motivaciones. Si conseguimos esto el equipo podrá dar la mejor respuesta y ofrecer la mejor solución.
¿Cómo escribir historias de usuario cortas?
Las historias de usuario en agile no nos sirven para generar más documentación. Normalmente se debe evitar escribir mucho, si escribimos demasiado no será una historia de usuario. ¿Cómo podemos escribir buenas historias de usuario en Scrum?
A menudo me he encontrado con historias de usuario que son una epopeya. Llamamos epopeya o historia épica a las historias demasiado largas como para poder ser estimadas. Puedes leer acerca el dimensionamiento relativo para estimar la cantidad de trabajo sobre una historia de usuario mediante el uso de Poker Plan en este post. Para poder explicar esta situación lo haremos con esta historia de usuario de ejemplo.
Ahora nos imaginamos que formamos parte del equipo de Amazon y definimos la siguiente historia de usuario:
Como cliente, quiero la tienda de libros más grande del mundo para poder comprar cualquier libro que quiera en el momento que quiera.
Esta historia de usuario cumple con sus características básicas:
- Existe un personaje
- Existe algo a construir
- Existe una motivación
- Está alineada con lo que quiere ser Amazon
Aún así estamos delante una historia de usuario que como equipo no podemos hacer demasiado con ella. Necesitamos desglosarla. Necesitamos dividir la historia de usuario. La historia de usuario es la unidad mínima en la que se define el trabajo a realizar. ¿Cómo podemos dividir las historias de usuario?
Para poder dividir la historia de usuario necesitamos pensar en los distintos personajes implicados en la aplicación que deseamos construir. Si estamos pensando en redactar las historias de usuario de una página web orientada a vender libros, podríamos escribir las siguientes:
- Como cliente, quiero poder buscar libros por género para encontrar el tipo de libro que me gusta.
- Como cliente, quiero meter el libro en un carrito de la compra para poder comprarlo.
- Como jefe de producto, quiero poder realizar un seguimiento de las compras del cliente para poder ofrecerle unos libros determinados basándome en sus compras anteriores.
Estas tres historias de usuario el equipo las entiende y entiende sus motivaciones. Para empezar a trabajar en la solución debemos abrir un debate en cómo llevarlas a cabo. A partir de este momento el equipo ya puede empezar a trabajar en cómo será la solución.
Estamos ante historias de usuario suficientemente específicas cómo para poder empezar a actuar. Aún así estas historias de usuario no prescriben la forma en la que van a hacerse las cosas. En las metodologías ágiles, también en Scrum, el equipo es autónomo para decidir cómo realizar el trabajo.
El equipo decide cómo conseguirá hacer el trabajo. Qué se debe hacer lo decide el valor de negocio.
En Scrum las historias de usuario las escribe el Product Owner. Si te interesa conocer las responsabilidades del Prodcuct Owner más allá de definir las historias de usuario en el desarrollo ágil puedes leer este artículo.
Marketing, diseño, desarrollo... todos en un mismo equipo
Estamos en un mundo en qué necesitamos personas con roles y profesiones distintas para poder sacar adelante un proyecto. En las metodologías ágiles el trabajo se hace en equipo así pues debemos crear equipos multidisciplinares, que sean capaces de realizar todo el trabajo, de inicio a fin.
No podemos concebir en una organización ágil que hablemos del equipo de diseño, el equipo de desarrollo, el equipo de sistemas...
No sólo es importante contar con un equipo con profesionales de distintos orígenes, también es imprescindible que el equipo esté implicado con el trabajo a realizar. Si no se consigue pronto nos encontraremos en el problema comentado al inicio del post.
En un equipo agile, diseñadores y desarrolladores trabajan en el mismo equipo. No sólo están en el mismo equipo sino que están implicados y trabajan juntos. En Scrum cuando tenemos una historia de usuario empieza el trabajo colaborativo para encontrar la mejor solución.
En este momento nos encontramos ante la oportunidad perfecta para entender todos los puntos de vista, los problemas derivados o las interpretaciones que se pueden hacer acerca de las necesidades o motivaciones de la historia de usuario. Si sabemos que un desarrollador siempre piensa en preguntas del estilo ¿Qué haremos cuando suceda esto? Es mejor tenerlo en cuenta desde el primer momento que no que aparezca en fases más avanzadas de la solución.
Un equipo con perfiles profesionales distintos y que trabaja de forma conjunta y en equipo nos da la ventaja de cambiar los marcos de la discusión. Seguro que te has encontrado en reuniones donde integrantes de los departamentos de marketing, diseño y desarrollo están cerrados en su posición de "yo tengo razón y tu no".
Trabajar juntos a partir de la historia de usuario nos genera un sistema en el que conseguimos que cada uno del equipo trabaje, y piense ideas, para solucionar el problema.
Este trabajo conjunto nos hace llegar a acuerdos básicos de equipo de cómo se realizará el trabajo. Este acuerdo deja todo el equipo alineado en los motivos por los que se realiza un trabajo. Cada miembro del equipo, en la parte que le toca, busca las mejores aportaciones para ayudar a encontrar el camino hacia la mejor solución.
Conclusiones
Somos humanos. A los humanos nos gustan las historias. No nos gustan las tareas. Nos gusta todavía menos hacer trabajo sin conocer el motivo. Y, a parte de no gustarnos, nos desmotiva no sentirnos implicados en el planteamiento de la solución.
Para poder empezar a trabajar y a priorizar qué trabajo debemos hacer necesitamos redactar las historias de usuario. En Scrum todas las historias de usuario se almacenan en el backlog. Si quieres saber cómo puedes priorizar las historias de usuario puedes seguir con este post.
¿Cómo elaborar buenas historias de usuario?
- Definir el personaje, usuario, cliente o persona que va a utilizar lo que nosotros vamos a hacer.
- Conocer lo qué le gusta y lo qué no le gusta, su pasiones, entusiasmos, frustraciones o alegrías.
- Comprender sus motivaciones. ¿Cómo satisfacen sus necesidades estos personajes?
Es imprescindible pensar primero en quién va a ser el que reciba el valor de algo. En segundo lugar qué es lo que debemos realizar. En tercer lugar porqué necesita este trabajo.
Tenemos que hacer historias de usuario en las que ponerse a trabajar. No es un buen enfoque plantear tareas a despachar.
Si quieres aprofundizar en el desarrollo ágil te puede ser interesante leer estos artículos:
- El Mínimo Producto Viable nos sirve para aprender.
- ¿Qué prácticas agile debemos aplicar en los proyectos?
Te ha gustado el post? No olvides en suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
