Plantilla de historia de usuario y criterios de aceptación

La plantilla de la historia de usuario consiste en una frase con tres espacios en blanco:

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

Cópiela, utilícela, pero tenga claro para qué sirve: la plantilla es un punto de partida para una conversación, no un formulario que haya que rellenar. Una frase completada es el punto de partida para el perfeccionamiento. Lo que hace que la historia sea viable es lo que se añade a continuación: los criterios de aceptación que convierten una intención acordada en una prueba de «aprobado/suspenso», y la estimación que la convierte en un trabajo planificable. Este capítulo recorre una historia a lo largo de estas tres etapas.

Rellenar los espacios en blanco sin inventárselos

Cada ranura presenta un fallo de encendido habitual, y cada fallo de encendido puede comprobarse:

• [rol] — una persona concreta, nunca «un usuario». Si no pudiera identificar a esta persona en sus estadísticas o en su cola de asistencia, el rol no es más que un adorno. Prueba: ¿podría un diseñador tomar una decisión diferente debido al rol que ha elegido?
• [objetivo] — lo que hace la persona, en su propio lenguaje. «Quiero restablecer mi contraseña» corresponde al usuario; «Quiero un microservicio de restablecimiento de contraseña» corresponde al diagrama de arquitectura. Prueba: ¿diría realmente la persona esta frase?
• [beneficio] — el argumento a favor de programar el trabajo. Prueba: elimine la cláusula. Si no se pierde nada, es que aún no se ha identificado el beneficio.

La explicación detallada del formato —incluidas las tres «C» y la lista de verificación INVEST que debe cumplir una historia de usuario completa— se encuentra en ¿Qué es una historia de usuario?. En Ejemplos de historias de usuario se recogen dieciséis ejemplos prácticos, tanto buenos como malos.

Una ficha de historia «copiar y pegar»

La frase por sí sola no basta para incluirla en un sprint. A continuación se muestra el formato completo de la ficha que conviene utilizar como norma: historia, criterios, límites y, por último, el tamaño:

Story
  As a [role], I want [goal], so that [benefit].

Acceptance criteria (3–5, each pass/fail)
  - [ ] …
  - [ ] …
  - [ ] …

Out of scope
  - What this story deliberately does NOT cover.

Notes & dependencies
  - Designs, decisions, other teams, open questions.

Size: [added by the team, after the conversation — never before]

En esa tarjeta hay dos decisiones deliberadas. «Fuera del alcance» es un elemento fundamental: la mayoría de las discusiones sobre estimaciones se producen cuando dos personas evalúan alcances diferentes, y una sola línea aquí lo evita. El tamaño se indica en último lugar: una cifra anotada en la tarjeta antes de que el equipo la debata se convierte en un punto de referencia, lo cual constituye el primero de los clásicos errores del planning poker.

Variantes de la plantilla

La plantilla clásica es la opción predeterminada adecuada, aunque no es la única forma que funciona.

Variante	Forma	Recúrralo cuando
Clásico (Connextra)	Como [cargo], quiero [objetivo], para que [beneficio]	La configuración predeterminada para el trabajo de cara al usuario
Historia laboral	Cuando se da [situación], quiero [motivación], para poder [resultado]	El momento desencadenante explica más que la imagen que proyecta: la misma persona, en un tren, desea cosas diferentes a las que desea cuando está sentada ante un escritorio
Las ventajas, ante todo	Con el fin de [beneficio], en mi calidad de [cargo], deseo [objetivo]	El equipo sigue redactando beneficios circulares; al colocar la cláusula en primer lugar, resulta imposible saltársela.
Exposición sencilla del problema	Una frase que describa el problema, otra que describa el resultado, además de los criterios de «cuándo se considera finalizado»	Trabajo técnico y de plataforma en el que la única figura honesta sería el propio equipo

La última línea es más importante de lo que parece. Algunas entradas de la lista de tareas pendientes no incluyen a ningún usuario en la frase, y fingir lo contrario da lugar a frases de relleno como «como desarrollador, quiero que se actualice el marco de trabajo». La disciplina de la plantilla —una razón explícita más criterios comprobables— se traslada a ese trabajo; la estructura de la frase, en cambio, no tiene por qué hacerlo.

Criterios de aceptación: la confirmación que figura en la tarjeta

Los criterios de aceptación son las condiciones de aprobación o rechazo de la historia, que se redactan antes de comenzar el trabajo. En la ficha, cumplen dos funciones: recogen lo que realmente se acordó en la reunión de refinamiento y definen la meta a la que se orientará la estimación. Existen dos formatos que abarcan prácticamente todas las historias:

Una lista de comprobación sencilla, para condiciones independientes:

• El contenido del carrito se conserva durante 30 días, independientemente de las sesiones.
• Un cliente habitual puede ver su carrito desde cualquier dispositivo en el que haya iniciado sesión.
• Un carrito vaciado permanece vacío (los artículos retirados no se recuperan).

Dado/Cuando/Entonces, para comportamientos que dependen del estado:

• Si un cliente tiene un carrito guardado, cuando un artículo se agota, entonces dicho artículo aparece en el carrito en gris y con la etiqueta «agotado», en lugar de eliminarse sin previo aviso.

Utilice por defecto la lista de comprobación; recurra al formato «Dado que/Cuando/Entonces» cuando la condición previa implique un trabajo real. Limite la lista a entre tres y cinco entradas; una lista más larga suele indicar que la historia debería dividirse, y los criterios le muestran los puntos de corte. Para obtener información completa (criterios frente a requisitos, criterios frente a la definición de «terminado», quién los redacta), consulte el capítulo sobre criterios de aceptación.

Ejemplo práctico: un piso, plantilla para realizar una estimación

A continuación se muestra el desarrollo de una historia real, utilizando la tarjeta anterior.

Paso 1: la historia. El responsable del producto escribe:

Como es la primera vez que compro, deseo realizar el pago sin crear una cuenta, para poder finalizar mi compra antes de que cambie de opinión.

Paso 2: la conversación, plasmada en forma de criterios. En el refinamiento del backlog, el equipo saca a la luz los matices que la frase no transmite y los anota:

• Un comprador puede finalizar la compra indicando únicamente su dirección de correo electrónico y los datos de envío, sin necesidad de contraseña.
• El correo electrónico de confirmación del pedido ofrece la posibilidad de crear una cuenta con un solo clic (el pedido ya está adjunto).
• El servicio de atención al cliente puede localizar un pedido de un cliente sin cuenta mediante el número de pedido y la dirección de correo electrónico.
• El proceso de pago como invitado sigue los mismos controles antifraude que el proceso de pago con cuenta.

Fuera del alcance: la conversión de los pedidos históricos de los clientes cuando se crea una cuenta posteriormente.

Paso 3: la comprobación de que está lista. Cuatro criterios, una exclusión explícita, ninguna dependencia sin confirmar: la historia cumple con la definición de «lista» y pasa al equipo para su evaluación.

Paso 4: la estimación. El equipo vota en una ronda de planning poker. Se sacan las cartas 3, 5, 5 y 8. El 8 se explica así: el criterio de verificación de fraudes implica modificar la integración con el proveedor de pagos, algo que nadie más había tenido en cuenta a la hora de calcular el coste. Ahí es donde los criterios cumplen su verdadera función: el debate gira en torno al alcance, no a quién tiene razón en cuanto a la cifra. El equipo vuelve a votar y se pone de acuerdo en 5.

Fíjese en el orden: primero los criterios y luego los puntos. Una historia estimada antes de que existan sus criterios da lugar a rangos amplios e irresolubles que entorpecen las sesiones de estimación del tamaño: el equipo está votando sobre historias diferentes que, casualmente, comparten un mismo título.

Preguntas frecuentes

¿En qué consiste la plantilla de historia de usuario?

«Como [rol], quiero [objetivo], para que [beneficio]». El rol identifica a quién va dirigido el valor, el objetivo describe la capacidad en términos propios de esa persona y el beneficio es la razón por la que el trabajo merece un lugar en la lista de tareas pendientes. La plantilla es un punto de partida para una conversación, no un formulario que haya que rellenar: el proceso de refinamiento comienza al completar los espacios en blanco.

¿Cómo se redactan los criterios de aceptación de una historia de usuario?

Redacte entre tres y cinco condiciones comprobables que indiquen, mediante «aprobado» o «suspendido», si la historia ha cumplido con lo acordado. Utilice una lista de comprobación sencilla cuando las condiciones sean independientes, y el formato «Dado que/Cuando/Entonces» cuando el comportamiento dependa del estado. Cada criterio debe poder ser comprobado por un evaluador que no haya asistido a la reunión de refinamiento.

¿Deberían los criterios de aceptación seguir el formato «Dado que/Cuando/Entonces» o consistir en una lista de comprobación?

Adapte el formato al comportamiento. El patrón «Dado que/Cuando/Entonces» resulta útil cuando el resultado depende de un estado inicial, ya que le obliga a especificar la precondición, el desencadenante y el resultado. Una lista de verificación es más rápida de leer y más difícil de rellenar con contenido superfluo cuando la historia se reduce simplemente a «estas cuatro cosas deben cumplirse». La mayoría de las historias solo necesitan la lista de verificación.

¿Qué es una «historia de trabajo»?

Una variante que sustituye a la persona por una situación: «Cuando [situación], quiero [motivación], para poder [resultado]». Las «historias de trabajo» proceden de la escuela de los «tareas por realizar» y funcionan bien cuando el momento desencadenante explica la necesidad mejor que lo hace un perfil de usuario: la misma persona desea cosas diferentes cuando está en su escritorio y cuando va en tren.

¿Es necesario que cada elemento de la lista de tareas pendientes siga la plantilla de la historia de usuario?

No. La plantilla describe el valor para el usuario, y aplicarla a trabajos de plataforma, errores conocidos o picos de investigación da lugar a frases que añaden formalidad sin aportar información. Mantenga las dos características que siempre son aplicables —una razón bien definida y criterios de aceptación comprobables— y deje que la estructura de la frase se adapte al trabajo.

Lecturas relacionadas

• Estimación ágil: la guía completa — el centro de referencia para todo lo relacionado con este tema.
• ¿Qué es una historia de usuario? — El razonamiento que subyace a la plantilla: las tres «C» y el principio INVEST.
• Ejemplos de historias de usuario — dieciséis historias comentadas con las que comparar.
• Criterios de aceptación: cómo redactarlos — el capítulo completo sobre la fase de confirmación.
• Definición de «listo» — la etapa que debe superar una historia basada en una plantilla para poder incorporarse al sprint.
• ¿Qué son los puntos de historia? — la unidad en la que se mide el tamaño de la tarjeta una vez finalizada.