¿Qué es una historia de usuario?

Una historia de usuario es una descripción breve y en lenguaje sencillo de un cambio, narrada desde la perspectiva de la persona que se beneficia de él: «Como cliente habitual, deseo iniciar sesión con mi correo electrónico para poder consultar mi historial de pedidos». Se trata, deliberadamente, de algo distinto a una especificación. La ficha encierra la promesa de entablar un diálogo, y los detalles se concretan cuando el equipo perfecciona la historia, redacta sus criterios de aceptación y determina su alcance.

Todo lo demás en esta guía gira en torno a las historias. Son lo que se evalúa en planning poker, a lo que se asignan los puntos de historia y lo que se divide cuando la estimación no converge. Un equipo que redacte historias deficientes realizará estimaciones erróneas, independientemente de lo bien que se desarrolle la sesión, ya que el problema surge precisamente en los datos de partida.

El formato: función, objetivo, ventaja

La forma clásica se remonta a Connextra, un equipo de XP de Londres, hacia el año 2001:

Como [función], quiero [objetivo], para que [beneficio].

Hay tres ranuras, y cada una cumple una función.

• El rol indica quién recibe el valor. «Como usuario» es el error más habitual en este formato: una historia que podría referirse a cualquier persona es una historia con la que, en realidad, nadie ha consultado. Indique la persona concreta: el cliente habitual, el desarrollador de integraciones.
• El objetivo es la capacidad desde el punto de vista del usuario, que describe lo que hace la persona en lugar de cómo está construido el sistema. «Quiero restablecer mi contraseña» es un objetivo. «Quiero un microservicio para restablecer la contraseña» es una decisión de diseño que adopta ese formato.
• La justificación es la cláusula que los equipos eliminan en primer lugar, y es la que hace que la tarjeta ocupe su lugar en la lista de tareas pendientes. El «para que» es el argumento de la historia que justifica su inclusión en la planificación. Si nadie puede terminarla, el trabajo carece de fundamento, y escribir la cláusula es la forma de descubrirlo antes de que comience el sprint, en lugar de después.

Tarjeta, conversación, confirmación

Ron Jeffries resumió el funcionamiento de las historias en tres «C», y el orden en que aparecen es importante.

La tarjeta es un símbolo: una o dos frases, breves a propósito. Su tamaño es una característica: físicamente no puede contener un requisito completo, lo que obliga a que se produzca la siguiente C.

La conversación es donde realmente reside el requisito. El equipo y el responsable de producto analizan la historia en profundidad durante el refinamiento del backlog: los casos extremos y lo que queda explícitamente fuera del alcance. Los equipos que se saltan este paso y tratan la tarjeta como si fuera el requisito en sí obtienen lo peor de ambos mundos: un documento demasiado escueto como para basarse en él a la hora de desarrollar, y la ausencia de conversación porque «ya está escrito».

La confirmación son los criterios de aceptación: las condiciones de «aprobado/suspenso» que determinan si el trabajo final cumple con lo acordado en la conversación. El capítulo sobre la plantilla de historias de usuario muestra los dos formatos que funcionan, y el capítulo sobre criterios de aceptación aborda su redacción en profundidad.

La lista de comprobación de INVEST

La lista de verificación de Bill Wake de 2003 sigue siendo la forma más rápida de comprobar si una historia está lista para ser desarrollada. Una buena historia es:

• Independiente: se puede programar por sí sola, sin necesidad de incluir otras tres historias en el sprint.
• Negociable: la ficha invita a entablar una conversación; el alcance aún puede variar. Una historia en la que todos los detalles están fijos no es más que un requisito disfrazado de historia.
• Valioso: la cláusula con «para que» resiste ante un «¿por qué?» sincero.
• Estimable: el equipo puede cuantificarlo. Una historia cuyo tamaño nadie puede determinar conlleva una incógnita; realice un spike para determinarlo.
• Pequeño: cabe en un sprint y aún sobra espacio. Si no es así, divídalo.
• Comprobable: puede redactar criterios de aceptación que se aprueben o se rechacen. «La página parece más rápida» no cumple este criterio; «los resultados se cargan en menos de un segundo» sí lo cumple.

«Estimable» y «pequeña» son los criterios en los que las historias se relacionan con el resto de esta guía. Una amplia dispersión de votos en el «planning poker» suele ser un fallo de la fase de INVEST que sale a la luz tardíamente: la historia era negociable en aspectos que nadie había tenido en cuenta, o era demasiado amplia como para que alguien pudiera abarcarla en su totalidad.

Qué no es una historia de usuario

No es una tarea. Una historia ofrece algo que el usuario puede ver; una tarea es un paso que da el equipo para llegar hasta ahí. «Iniciar sesión con el correo electrónico» es una historia. «Configurar el almacén de sesiones» es una de sus tareas. El capítulo sobre épicas, historias y tareas aborda la jerarquía y explica por qué los puntos solo deben asignarse al nivel de las historias.

No es un documento de requisitos. Un requisito debe estar completo antes de que comience el trabajo. Una historia debe ser suficiente para iniciar la conversación y nada más. Juzgar las historias según los criterios de los requisitos («¡es demasiado imprecisa!») es pasar por alto el diseño: la imprecisión deja un margen para el criterio del equipo.

No es una promesa de implementación. La historia establece el resultado; el equipo decide cómo llevarlo a cabo. Cuando una historia se presenta con la solución ya decidida, la parte negociable de INVEST ya ha desaparecido.

Cuando las historias de usuario no son la herramienta adecuada

El formato tiene sus limitaciones, y fingir lo contrario le resta credibilidad ante las personas que tienen que redactar las frases más complicadas. En algunas construcciones no aparece el sujeto en la oración:

• Trabajo en profundidad en la plataforma. «Como desarrollador, quiero actualizar el marco de trabajo, para que el marco de trabajo quede actualizado» no aporta nada que no figure ya en el título del ticket. Redáctelo como un trabajo técnico sencillo con un resultado concreto: qué fallará o se ralentizará si esto no se lleva a cabo, y qué resultará más sencillo cuando se haga.
• Errores cuya causa se conoce. Un informe de defecto (comportamiento esperado, comportamiento real, pasos para reproducirlo) constituye un formato más adecuado que una historia adaptada a posteriori. En el capítulo sobre puntos de historia se explica cuándo se asignan puntos a los errores.
• Picos de investigación. Un pico consiste en una pregunta y un intervalo de tiempo, y su resultado es el conocimiento. Forzar su encaje en el esquema «función-objetivo-beneficio» oculta lo único que importa: lo que el equipo necesita aprender.
• Tareas de cumplimiento normativo. No se puede negociar el alcance con un organismo regulador. Un requisito es un requisito; anótelo como tal.

Lo que tienen en común todos estos casos es la disciplina, no la estructura de la frase: una razón clara por la que el trabajo es importante y una definición verificable de «terminado». Si se mantienen estos elementos, el formato habrá cumplido su función incluso en aquellos casos en los que no sea aplicable.

Donde las historias se unen a la estimación

Una historia es la unidad de estimación. Una vez redactada, sigue el siguiente proceso: el equipo la analiza, la valora en puntos de historia mediante planning poker, la compara con la definición de «listo» y la divide si la votación no llega a un consenso. Una historia bien estructurada agiliza cada uno de esos pasos, lo cual constituye la razón práctica por la que merece la pena prestar atención al formato.

Para ver cómo se aplica el formato, el capítulo sobre ejemplos de historias de usuario presenta dieciséis historias comentadas, tanto buenas como malas. Para redactar la suya propia, comience por la plantilla.

Preguntas frecuentes

¿Qué es una historia de usuario?

Una historia de usuario es una descripción breve y en lenguaje sencillo de un cambio, narrada desde la perspectiva de la persona que se beneficia de él: «Como cliente habitual, deseo iniciar sesión con mi correo electrónico para poder consultar mi historial de pedidos». Se trata, deliberadamente, de algo distinto a una especificación. La ficha sirve como punto de partida para una conversación, y los detalles se concretan cuando el equipo perfecciona y evalúa el alcance del trabajo.

¿En qué consiste el formato de la historia de usuario?

El formato clásico es «rol-objetivo-beneficio»: «Como [rol], quiero [objetivo], para que [beneficio]». El rol indica quién obtiene el valor, el objetivo describe la capacidad en términos del usuario y el beneficio es el argumento que justifica la programación del trabajo. Si nadie puede completar la cláusula «para que», la historia no tiene razón de ser en la lista de tareas pendientes.

¿Cuáles son las tres «C» de las historias de usuario?

Tarjeta, conversación, confirmación. La tarjeta es un recordatorio, deliberadamente demasiado breve para contener el requisito. La conversación es donde realmente cobra vida el requisito, a medida que se va perfeccionando junto con el equipo. La confirmación son los criterios de aceptación que determinan, mediante «aprobado» o «suspendido», si el trabajo final cumple con lo acordado.

¿Qué significa el acrónimo INVEST?

Independiente, negociable, valiosa, cuantificable, pequeña, comprobable. Se trata de la lista de verificación de Bill Wake para determinar si una historia está lista para ser trabajada. En la práctica, los tres últimos criterios son los que más peso tienen: una historia que el equipo no pueda cuantificar, que no quepa en un sprint o que ninguna prueba pueda confirmar es una historia que aún no está lista.

¿En qué casos no se deben utilizar las historias de usuario?

Cuando el formato aporta formalidad en lugar de claridad. El trabajo en profundidad en la plataforma, las correcciones de errores con una causa conocida, los requisitos de cumplimiento normativo y los proyectos de investigación puntuales se adaptan mejor a formatos propios. Mantenga la cláusula de beneficios y los criterios de aceptación; omita la fórmula «como desarrollador, quiero» cuando no haya ningún usuario en la frase.

Lecturas relacionadas

• Estimación ágil: la guía completa. El centro de referencia para todo lo relacionado con este tema.
• Ejemplos de historias de usuario: dieciséis historias comentadas, incluidas aquellas que no funcionan y las razones por las que no lo hacen.
• Plantilla de historia de usuario y criterios de aceptación: la plantilla, sus variantes y un ejemplo práctico que abarca hasta la estimación.
• Épico vs. historia vs. tarea: dónde se sitúa la historia en la jerarquía y a qué nivel se hace referencia.
• División de historias de usuario: qué hacer cuando una historia no supera la «prueba de lo pequeño».