¿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 tarjeta encierra la promesa de entablar una conversación, 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, beneficio

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

Como [función], deseo [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 cualquiera es una historia con la que, en realidad, nadie ha consultado. Indique a 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.
• El beneficio es la cláusula que los equipos descartan 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 para que se programe. 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 es importante.

La tarjeta es una ficha: 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 ficha como si fuera el requisito en sí mismo 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 en profundidad cómo redactarlos.

La lista de comprobación 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 empezar a trabajar en ella. 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 modificarse. 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» se sostiene ante un «¿por qué?» sincero.
• Estimable: el equipo puede cuantificarlo. Una historia cuya magnitud nadie puede determinar conlleva una incógnita; realice un spike para averiguarla.
• Pequeño: cabe en un sprint y aún sobra espacio. Si no es así, divídalo.
• Comprobable: se pueden redactar criterios de aceptación que den como resultado «aprobado» o «suspendido». «La página parece más rápida» da como resultado «suspendido»; «los resultados se cargan en menos de un segundo» da como resultado «aprobado».

«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 en la fase de INVEST que sale a la luz tarde: la historia era negociable de formas que nadie tuvo 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 a ello. «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 la historia.

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

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

Cuando las historias de usuario no son la herramienta adecuada

El formato tiene sus limitaciones, y fingir lo contrario hace que se pierda credibilidad ante las personas que tienen que redactar las frases más complicadas. En algunas oraciones no aparece el sujeto:

• Trabajo en profundidad en la plataforma. «Como desarrollador, quiero actualizar el marco de trabajo, para que este quede actualizado» no aporta nada que no figure ya en el título del ticket. Redáctelo como un trabajo técnico concreto con un resultado específico: qué fallará o se ralentizará si 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) es 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. Enmarcarlo a la fuerza 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 forma de la frase: una razón clara por la que el trabajo es importante y una definición verificable de lo que significa «terminado». Si se mantienen esos 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 debate, la valora en puntos de historia mediante el 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 de 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 tarjeta 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 motivos para figurar 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 pequeña para contener el requisito. La conversación es donde realmente se desarrolla el requisito, a medida que se va perfeccionando junto con el equipo. La confirmación son los criterios de aceptación que determinan, si se aprueba o se suspende, si el trabajo final cumple con lo acordado.

¿Qué significa el acrónimo INVEST?

Independiente, negociable, valiosa, estimable, 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 estimar, 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 tienen todos ellos formas más adecuadas en sí mismos. 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 incluye 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».