Historias de usuario aportan valor, no funcionalidad

“Cuéntame un cuento y verás que contento, me voy a la cama y tengo dulces sueños”. Esta famosa canción de Celtas Cortos me ha acompañado media vida. Los cuentos y las historias son fáciles de transmitir, perduran en el tiempo, y se suelen memorizar con facilidad. Piénsalo, seguro que te acuerdas del cuento de Caperucita Roja pero os cuesta recordar ese requisito que desarrollaste hace 2 años. El motivo es sencillo, las historias son fáciles de recordar y eso es muy bueno para que a la hora de desarrollar software no se nos escapen detalles.

Vamos a hacer una pequeña introducción a las Historias de Usuario desmitificando algunos errores que todos hemos cometido alguna vez:

En Scrum sólo hay Historias de Usuario

Lo primero que debemos desmitificar es que en Scrum, el Product Backlog está compuesto por Historias de Usuario. El Product Backlog está compuesto por elementos que describen nuestro producto, y uno de ellos son las Historias de Usuario. Son una técnica más de toma de requisitos, con unas características concretas y ventajas para ciertas situaciones pero no trates de modelarlo todo con Historias de Usuario.

Las Historias de Usuario describen cualquier cosa

Una Historia de Usuario trata de describir la interacción de un usuario con un sistema y su comportamiento. El formato de historia trata de clarificar esas interacciones. ¡Pero no sirve para todo! Un ejemplo que viví hace tiempo en un equipo que tenía la siguiente “historia”: “Como usuario quiero SONAR para…”.  Un usuario no quiere Sonar para nada, Sonar es una herramienta técnica que nos ayuda a mantener la calidad en el código. Por tanto, no describas eso como historia, directamente escríbelo como un requisito “Instalar SonarQube versión XX.XX”.

El motivo por el que forzamos las Historias de Usuario para todo es porque creemos que así hacemos mejor Scrum y como hemos dicho, no es obligatorio. 

Historias del Sistema

Las Historias de Usuario suelen describir comportamientos de personas, si es cierto, que hoy en día hay tareas automáticas que realizan los sistemas y los equipos suelen tener dentro de su gama de roles detectados el “sistema”. Por ejemplo “El Sistema por la noche hará un informe de todas las entradas del día y enviará un email a los administradores con el resumen”. Tener historias que describen el comportamiento del Sistema no es malo pero no es bueno abusar de ello.

Una Historia de Usuario se debe escribir con “Cómo Rol Quiero Algo Para Motivo”

Este es el error más común que todos hemos cometido mil veces. El formato “como-quiero-para” es sólo una manera de afrontar las historias pero no es obligatorio dicho formato. En el libro de Mike Cohn “User Story Applied” te habla durante 300 páginas sobre las historias y no aparece este formato.

Las Historias solo tienen como características la triple C que creó Ron Jeffries que son: Card, Conversation y Confirmation. Básicamente debe poderse describir en el tamaño de una tarjeta (Card), tiene que haber una conversación entre el cliente (en el caso de Scrum el Product Owner) y las personas que van a desarrollarlo y tienen que tener unos criterios que digan cuándo está finalizada.

Con qué esté escriba ya vale.

No es cierto, parte de la cultura de las Historias de Usuario es que tiene que haber una conversación. Por eso en Scrum existe la Sprint Planning. Las Historias de Usuario deben poderse hablar y debatir sino se pierde gran parte de su potencial. Las Historias de Usuario se crearon con el fin de mantener una conversación sobre lo que hay que hacer. Sin esa conversación, un desarrollador acabará desarrollando lo que interpreta que dice el papel (al que no se le puede preguntar nada).

Un ejemplo gracioso para explicar esto es la palabra Buffalo en inglés que tiene tres acepciones: Intimidar (aunque esta se usa poco), la ciudad de Búfalo y el animal.

Teóricamente “Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo” es una frase correcta gramaticalmente. Si queremos aclararla sería así: “The buffalo from Buffalo who are buffaloed by buffalo from Buffalo, buffalo (verb) other buffalo from Buffalo.” (El búfalo de Búfalo que está siendo intimidado por un búfalo de Búfalo, intimida a otro búfalo de Búfalo).  

Si nos damos cuenta, la escritura tiene interpretaciones y requiere de aclaración. Sin embargo, es muy útil. Pensemos en un equipo de 7 personas que tienen Sprints de 3 semana (21 días). Estamos hablando de más de 140 días de trabajo). ¿Cuántos PBIs se harán en ese tiempo? La escritura nos ayuda a recordar esos detalles que hemos trabajado en la conversación.

Una técnica que me enseñaron hace tiempo consiste en hacer lo siguiente. El Product Owner trae a la Sprint Planning los elementos del Product Backlog escritos y uno a uno los lee tal cual están escritos (sin matizaciones). Tras la lectura el Development Team indica si se ha enterado o no, en caso de que hagan falta aclaraciones estas se añaden a la descripción. Es una manera de evitar que hablemos una cosa pero aparezca escrito algo diferente y luego nos equivoquemos.

Talleres de US

Hay varias maneras de escribir talleres de Historias de Usuario, una de mis favoritas la propone Jeff Patton en su libro “User Story Mapping”. En este taller el objetivo es obtener Historias de Usuario para nuestro Product Backlog (aquí Jeff además trataba de incluirlas en su herramienta de User Story Mapping).

En este taller lo primero es seleccionar a las personas que normalmente suele ser el Product Owner y, además, personas con conocimientos técnicos en QA, Análisis Funcionales, UX y técnicos. No más de 6 personas para que sea lo más ágil posible. A partir de ahí se hace una definición de las historias con preguntas: Quién, Qué y Por qué y después se trabajan los criterios. Lo curioso de este taller es que se trabajan aspectos como ¿Qué hace el usuario cuando falla esta funcionalidad? ¿Cómo lo hace ahora? Este tipo de preguntas son poco habituales y ayuda muchísimo a pensar al equipo y a ponernos en la piel de nuestro usuario.

Una Historia de Usuario es una descripción funcional

Este es el error más común entre las personas. Las Historias de Usuario deben aportar valor. Cuando se habla de que las buenas historias son INVEST, uno de los parámetros es “Valuable” que significa que aporte valor. Esto quiere decir que cada una por sí sola debería de aportarnos algo y debemos de hablar de eso. ¿Qué le aporta esto a mi usuario? ¿Qué problema le resuelve? ¿Pagaría por tener esto? Este tipo de cuestiones son las más importantes a tratar y muchas veces se escapan del debate porque nos centramos demasiado en la funcionalidad y no tanto en el valor esperado.

Hay quien, incluso, trata de definir el valor aportado por una funcionalidad o métrica por historia. Me parece un ejercicio muy complicado pero si lo consigues, tremendamente útil. Es la mejor manera de poder tomar decisiones futura en base a lo que tus Historias construidas y liberadas están generando realmente.

Por ejemplo, una vez desarrollamos una web para una aseguradora donde íbamos a abordar varios tipos de seguro a la vez. Una de las funcionalidades era muy complicada y nuestro Product Owner nos insistía en que lo quería para todos los seguros. Nosotros le explicamos que mejor añadirlo en uno solo y estudiar el % de usuarios que lo usarían y descubrir la respuesta a la pregunta ¿Estamos ante algo que no tiene nadie porque es muy innovador o es algo que no tiene la competencia porque el usuario no lo valora? Esta pregunta es muy poderosa, sin embargo el criterio tradicional es hacerlo para todo (en modo big bang) porque es lo que hay que hacer, mientras que el criterio en Agile es descubrir si el valor que he teorizado es real cuando lo pongo delante de un usuario (inspeccionar y adaptar).

Esto es un pequeño resumen de lo que son Historias de Usuario. Si queréis aprender más cuidado de los blogs donde leáis “como-quiero-para” que, insisto, son solo una manera de hacerlo. Podéis aprender más tanto del libro de Jeff Patton como del libro “User Story Applied” de Mike Cohn.