Historias de Usuario: qué son, reglas y consejos.
Alonso Alvarez
- Agilidad Empresarial
- Artículo
Tabla de contenidos
Qué son las Historias de Usuario
Las Historias de Usuario son representaciones de requisitos, elaboradas en una o dos frases y recogidas en un lenguaje común y entendible por el usuario. También conocidas como User Stories o simplemente US se han convertido en un estándar a la hora de definir requisitos. Aunque su popularidad viene de la mano de Scrum, hay que recordar que NO son un elemento estandarizado recogido en la Guía Scrum. En muchas organizaciones incluso se habla de Historias de Usuario como sinónimo de requisito, olvidando sus fundamentos (de la misma forma hay quien llama “MVP” a una entrega, o “PO” a un jefe de proyecto clásico sin cambiar sus funciones).
Las Historias de Usuario aparecen en XP (1999) y se popularizan definitivamente con Mike Cohn (en “User Stories Applied: For Agile Software Development”, 2004) que fija el patrón para definirlas, en buena parte responsable de su popularidad por su aparente simplicidad. Este patrón se estructura en tres partes:
- Como: persona que expresa una necesidad.
- Quiero/Necesito: la necesidad requerida.
- Para: valor obtenido, contexto de la necesidad.
No vamos a extendernos aquí en el porqué de una Historia de Usuario, si es mejor o peor que otros mecanismos o la forma correcta de definirlas y todos los antipatrones y malos usos posibles (desde la Historia de Usuario-novela, hasta la que no tiene…usuario).
En su lugar, vamos a revisar unas pocas reglas nemotécnicas que ayudarán a crear buenas Historias de Usuario, adecuadas para su propósito que es, entre otros, alcanzar la calidad extremo a extremo. Es decir, desde el principio, desde la propia definición de requisitos. No olvidemos que los requisitos son la materia prima sobre la que se asienta todo el proceso posterior. No querremos desarrollar nuestro trabajo sobre bases defectuosas o sin calidad.
La Regla de las 3 C’s
Una regla sencilla y simple y con más historia. Toda Historia de Usuario debe cumplir estos tres criterios:
- Card 😮 ser suficientemente breve como para que su definición entre en una tarjeta. Martin Fowler incluso menciona las medidas ideales. El patrón de definición de una US es suficientemente simple como para evitar la necesidad de extenderse innecesariamente.
- Conversación, como consecuencia de la anterior. Una US es una oportunidad para el diálogo entre quien expresa la necesidad y quien la satisface (en Scrum, entre el PO y el equipo de Desarrollo). Una Historia excesivamente detallada crea una falsa sensación de completitud (“está todo en la definición”) y evita una conversación muy necesaria para alinear a los implicados.
- Confirmación, al mismo tiempo, en su brevedad, la Historia de Usuario debe contener los elementos necesarios para determinar que se ha entregado el valor buscado por la necesidad. Y si no los tiene, la conversación los hará aflorar en forma de Criterios de Aceptación.
La Regla INVEST
La serie de criterios básicos para construir Historias de Usuario de calidad, que son el fundamento necesario para realizar productos de calidad. Esta regla definida por Bill Wake recomienda que cada US sea:
- Independiente: o con la mínima dependencia entre distintas Historias de Usuario. Esto facilita poder llevarlas a cabo en cualquier orden ya que toda dependencia es condicionante, y además tiende a convertirse en un riesgo.
- Negociable: lo que quiere decir que los detalles de la construcción emergen de una conversación (una de las 3 Cs) entre quien expresa la necesidad y quien la lleva a cabo.
- Valiosa: o con valor. Es decir, que el resultado de la Historias de Usuario aporta valor a sus usuarios. En este sentido, hay que ser conscientes de que el concepto de valor puede ser muy amplio.
- Estimable: es decir, que se cuenta con información suficiente como para poder conjeturar el esfuerzo necesario para llevar a cabo la Historia de Usuario.
- Pequeña (Small en inglés), que se refiere a que una Historia de Usuario no debe requerir más de una cantidad determinada de tiempo para ser construida. En equipos que aplican Scrum es habitual usar la convención de que una Historia debe poder ser llevada a cabo en el transcurso de un Sprint. Si no, es necesario dividirla. Fragmentar USs grandes en componentes más pequeños es una acción delicada para la que se puede contar con varias técnicas.
- Probable o Testable, es decir, que la Historia contenga información que haga posible validar que cumple su cometido a través de pruebas o test. Esto requiere muchas veces incorporar información adicional en forma de Criterios de Aceptación, que acotan y aclaran el alcance de lo que se quiere hacer.
Los criterios INVEST son uno de los elementos decisivos a la hora de determinar la calidad de los requisitos, que no olvidemos son los fundamentos sobre los que se construye todo producto o servicio.
Las regla de las cuatro R’s
Menos conocido, este modelo describe las fases por las que una necesidad se convierte en historia de usuario y finalmente en valor entregado. Ser conscientes de las etapas es una forma de entender la evolución necesaria que debe seguir todo requisito y de las acciones y agentes implicados en cada paso. Las Rs son:
- Raw, la idea “cruda”, todavía un poco nebulosa que aún no se ha acabado de aterrizar.
- Rough, aún es una idea “basta” pero donde ya podemos identificar interesados, valor, razones, primeros criterios de aceptación.
- Refine, cuando ya ha sido suficientemente trabajada como para acercarse a una realidad. No sólo se ha completado la información necesaria, si no que la US ha sido priorizada y estimada. Ya está a punto.
- Ready, todo el trabajo previo ya está hecho y puede convertirse en una realidad. Es el paso previo para formar parte del incremento de producto.
Hay versiones alternativas con un orden ligeramente diferente.
La regla DEEP
Por último, y aunque se refiere al contenido de un backlog (del Product Backlog de Scrum en particular), dado que las Historias de Usuario terminan formando parte de uno de ellos, este criterio también se aplica a ellas. Las siglas de DEEP se refieren a:
- Detallado (apropiadamente), es decir, que el nivel de detalle será el conveniente en cada circunstancia. Una US en estado “Raw” requiere mucho menos detalle que una “Ready” por ejemplo. Tampoco tiene sentido invertir esfuerzo prematuramente si, por ejemplo, los requisitos pasan cribas y selecciones.
- Estimada, también apropiadamente, ya que a lo largo de su evolución la estimación puede ser desde muy gruesa a más afinada.
- Emergente, lo que se refiere a la posibilidad de que los elementos del backlog (como las USs) aparezcan en cualquier momento, no como parte de una etapa dedicada únicamente a la definición y diseño.
- Priorizado, el backlog debe seguir algún tipo de orden, lo que afecta a las USs que contenga y que para ello contarán con información suficiente.
Para terminar con las Historias de Usuario
Elemento básico en XP y Scrum, y popularizado a otros modos de trabajo, las Historias de Usuario son un instrumento muy útil si se construyen, gestionan y trabajan adecuadamente. Estos acrónimos y reglas son herramientas que ayudan en ese proceso.
Debido a se usan cada vez más, fuera incluso de marcos de trabajo ágiles, hemos procurado en la medida de lo posible evitar ligarlas únicamente a Scrum y, sobre todo, a proyectos relacionados con el software. Ni las US ni las técnicas ágiles están únicamente ligados a ese mundo, aunque fue allí donde vieron la luz.
Sobre el autor
