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 través de estos tres elementos.

Rellenar los espacios en blanco sin inventárselos

Cada ranura presenta un fallo de encendido habitual, y cada uno de estos fallos se puede comprobar:

• [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 sus propios términos. «Quiero restablecer mi contraseña» pertenece al usuario; «Quiero un microservicio de restablecimiento de contraseña» pertenece 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.

El razonamiento completo que sustenta este 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 casos prácticos, tanto positivos como negativos.

Una ficha de historia «copiar y pegar»

La frase por sí sola no basta para iniciar un sprint. A continuación se muestra el modelo completo de la ficha que conviene adoptar como estándar, con la descripción, los criterios, los límites y el tamaño añadido al final:

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 esta única línea lo evita. El tamaño se indica en último lugar: una cifra escrita en la tarjeta antes de que el equipo la debata se convierte en un punto de referencia, lo cual constituye el primero de los errores clásicos del «planning poker».

Variantes de la plantilla

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

Variante	Forma	Recúrralo cuando
Clásico (Connextra)	Como [cargo], deseo [objetivo], para que [beneficio]	La configuración predeterminada para el trabajo de cara al usuario
Historia laboral	Cuando se da [situación], deseo [motivación], para poder [resultado]	El momento desencadenante explica más que la imagen pública (la misma persona desea cosas diferentes en un tren que 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 pretender 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 aplica 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 eliminados 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 la lista de verificación por defecto; recurra al método «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 extensa suele indicar que la historia debería dividirse, y los criterios le muestran los puntos de separación. Para obtener información detallada (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: una planta, plantilla para realizar una estimación

A continuación se muestra el recorrido que sigue 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 me lo piense mejor.

Paso 2: la conversación, plasmada en forma de criterios. Durante 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 le permite 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 estimació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 el 5.

Fíjese en el orden: primero los criterios y, después, los puntos. Una historia estimada antes de que existan sus criterios da lugar a rangos amplios e irresolubles que entorpecen las sesiones de determinación del tamaño. El equipo acaba votando sobre diferentes historias 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 verificació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 al perfil de usuario 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 viaja 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 raíz de 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: aquí encontrará toda la información al respecto.
• ¿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 realizar una calibración.
• 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 entrar en el sprint.
• ¿Qué son los «story points»? La unidad en la que se cuantifica la tarjeta una vez finalizada.