Mitos y Verdades en Agilidad: ¿Son siempre necesarias las Historias de Usuario?
En el mundo del Product Management, y mas precisamente en las tareas del Product Owner como dueño de la visión en la construcción de un producto digital, el uso de las historias de usuario suelen ser un requisito fundamental a la hora de una entrevista para cubrir ese rol en una organización que aplica la metodología agile/scrum. "¿Alguna vez has trabajado con user stories?" "¿Como escribirías una?" "¿Que características debe tener esa historia para incluirla dentro de tu backlog?".
Si bien es una práctica extendida en el framework Scrum, la guía creada por Ken Schwaber y Jeff Sutherland describe a los PBIs (Product Backlog Items) como los elementos que componen el artefacto (Backlog) pero en ningún momento sugiere o pone de ejemplo el uso de historias de usuario para describir los items que se incluirán dentro de un Product / Sprint Backlog. Entonces, ¿por qué utilizamos las Historias de Usuario casi como una parte inherente y necesaria de Scrum? ¿Es necesario su uso en todo proyecto ágil?.
El origen de una "buena práctica"
El termino "user story" fue acuñado por primera vez por el científico norteamericano Alistair Cockburn en 1998, reconocido como uno de los iniciadores del movimiento "agile" y creador (junto con otras 17 personas) del Manifesto for Agile Software Development. Las Historias de Usuario se volvieron dominantes en Extreme Programming (XP) y luego con la creciente popularidad de Scrum, fueron adoptadas por Scrum junto con otros conceptos de XP (como los ‘story points’ y las ‘stand up meetings’). A lo largo de los años, se han convertido en la técnica a la que recurren la mayoría de los equipos. Su uso ha sido fuertemente defendido por libros, blogs y trainers. En su forma actual, se consideran buenas prácticas.
¿Por qué se volvieron tan populares y efectivas?. La popularidad de las Historias de Usuario se traduce en su fácil comprensión del problema. En lugar de intentar capturar cada detalle de una función en largos requisitos, las user stories simplemente describen la esencia funcional desde la perspectiva de un usuario: la fuerza radica en su simplicidad. Por diseño, son incapaces de transmitir todos los detalles de lo que se necesita, pero a medida que el Scrum Team avanza a través del Product Backlog, entregando elementos como parte de los incrementos de trabajo, eventualmente necesitarán tener una conversación sobre lo que se necesita para implementar un próximo elemento, es decir, cuando estén a punto de implementarla, no al principio.
Las historias de usuario constituyen un enfoque de requerimientos que hace énfasis en la comunicación y participación de los usuarios en el proceso de desarrollo. Se hace foco en las necesidades (problema) y durante el transcurso del proyecto esas necesidades y prioridades pueden cambiar. Las historias de usuario favorecen el trabajo en iteraciones y la adaptación a los cambios.
Si no son user stories, ¿entonces qué enfoque puede utilizarse?
Las historias de usuario suelen presentar limitaciones a la hora de describir elementos mas técnicos dentro del Product Backlog. Asi lo sugiere Mike Cohn, miembro fundador de Agile Alliance y Scrum Alliance, en un articulo publicado en su portal especializado en agile coaching. La mayoría de los productos tienen usuarios en algún lugar a la vista, pero a menudo hay aspectos de back-end del producto donde ellos no están cerca. Es decir, podemos escribir historias donde se reflejan beneficios del sistema en los usuarios como por ejemplo: como usuario, quiero que se realice una copia de seguridad de todos los datos para que recuperar toda mi información almacenada. Sin embargo, otras veces, la funcionalidad que se describe comienza a alejarse demasiado de los usuarios reales y escribir historias de usuarios cuando no se encuentran usuarios reales se siente artificial o poco intuitivo.
Feature-Driven Development (FDD) es un proceso incremental e iterativo creado en 1997 por Jeff De Luca, que puede ayudar con un sintaxis clara y util para resolver este problema y al igual que a muchos equipos les resulta útil usar el "como, quiero, de modo que” para las historias de usuarios, FDD tiene su propia sintaxis recomendada para las funciones: la descripción de la característica comienza con la acción (un verbo) y termina con lo que sería un objeto dentro del sistema. (FDD es particularmente adecuado para el desarrollo orientado a objetos).
Una función FDD se escribe en este formato:
[Acción] el [Resultado] [por|para|de|a] un(a) [Objeto]
Como ejemplos, considere estos:
Generar un identificador único para una transacción
Combinar los datos para transacciones duplicadas
FDD puede ser una sintaxis particularmente buena cuando en funcionalidades de back-end o cuando se desarrolla una interfaz de programación de aplicaciones (API).
Otro enfoque que podemos utilizar es la función Gherkin: un lenguaje específico de dominio (DSL), que son lenguajes diseñados en concreto para resolver un problema muy específico. Gherkin está compuesto por varios elementos que permiten la comunicación entre perfiles de negocio y técnicos de forma sencilla. Gherkin tiene distintos elementos (de tipo características, comportamientos, acciones) en lenguaje natural, es decir que alguien del negocio entienda y otra persona del área técnico pueda trasladar a código.
La sintaxis elemental en formato Gherkin es:
Caracteristica (Feature): descripción de la funcionalidad a desarrollar donde los elementos que son de más alto nivel.
Escenario (Scenario): una feature puede tener uno o varios escenarios, que no son otra cosa que características (que pueden estar relacionadas o no) que se tienen que desarrollar para poder poder entregar esa feature al cliente.
Dado (Given): son las precondiciones para que se puedan ejecutar x acciones.
Cuando (When): se trata de las condiciones de las acciones que se van a ejecutar.
Entonces (Then): se trata del resultado esperado de las acciones ejecutadas.
Gherkin está diseñado para crear cualquier funcionalidad que sea de fácil lectura, generando una idea clara entre el negocio y el área técnica
Una tercera alternativa es utilizar las job stories, enfoque creado en 2013 por Intercom luego de que se dieran cuenta que con las user stories no lograban capturar situaciones, motivaciones y resultados que ellos buscaban. En la user story clásica decimos: Como <Persona> , quiero < Acción >, por lo que < Resultado esperado >. La acción produce el resultado esperado para el usuario. Pero puede ocurrir que los usuarios no están motivados por las acciones.
¿Qué sucede si la situación que resuelve su producto define el producto mejor que los atributos del cliente? Las historias de usuario son entonces la herramienta incorrecta para el trabajo. Si lo único que tienen en común tus usuarios es el trabajo a realizar en una situacion con el producto, ("job to be done", de ahi el nombre job story), entonces utilizar el user persona puede ser peligroso. Solo introducirá suposiciones implícitas y ambigüedad a su equipo de desarrollo. La persona genera ruido sin proporcionar información.
Por lo tanto, la sintaxis de una job story es:
Cuando [situación] quiero [motivación] para poder [resultado esperado]
La mirada se centra en la situación en la que las personas encuentran un problema que a resolver, la motivación para resolverlo y resultado esperado.
Una job story se centra en la situacion del usuario y no las caracteristicas del mismo.
Veámoslo con dos ejemplos:
Estás ocupado pintando una pared y te quedas sin pintura.
Estás ocupado pintando las paredes de la cocina y casi te estás quedando sin pintura. Mañana llega tu nueva cocina y si no consigues pintura nueva pronto no podrás terminar.
El contexto de la situación ayuda a diseñar la mejor solución. En la primera situación, una solución sería reservar tu pintura online y recogerla en la tienda. No es necesario darse prisa. En la segunda situación, desea realizar un pedido en línea para recibir la pintura en 1 hora. Esto significa que puede seguir trabajando mientras la pintura está en camino y terminar a tiempo.
Comentarios finales
Las historias de usuario otorgan una fácil comprensión del problema desde la mirada del usuario final. No puede discutirse su amplia popularidad en Producto debido a su efectividad en el desarrollo de software. Sin embargo una organización puede abrirse al uso de otras técnicas, siempre éstas:
Ayuden a promover la comprension de los PBIs por parte de todo el equipo Scrum y los stakeholders
Expresen en forma clara el problema y el nivel de detalle que exigen debe ajustarse a la incertidumbre del desarrollo de productos. Los elementos que se encuentran más lejos en el futuro deberían requerir menos detalles que los elementos que están a punto de incorporarse a un Sprint;
Fomenten la comunicación entre el equipo Scrum y los stakeholders;
Un Product Backlog cumple su objetivo cuando contiene una combinación de elementos. Algunos items serán tareas técnicas (por ejemplo, ‘Instalar un nuevo servidor web’ o ‘Crear un programa de respaldo para la base de datos de producción’), mientras que otros serán funcionales (por ejemplo, ‘Los suscriptores pueden almacenar elementos en su lista de lectura para que puedan leerlos en un momento posterior ‘). Las historias de usuario son una excelente manera de capturar los requisitos funcionales si fluyen naturalmente, y su formulación no se siente forzada ni tarea burocrática “si siempre se hizo asi, ¿para qué cambiar?”. Conocer y aplicar nuevos enfoques en nuestra organización nos ayudarán a crear mejores productos, promoviendo de esta manera la agilidad en nuestros equipos y obteniendo mejores resultados en la entrega de valor al usuario final.
