La historia que todos aprobaron y nadie pudo probar
Durante la Planificación del Sprint, un Equipo Scrum tomó una historia que decía, simplemente: «Los usuarios pueden restablecer su contraseña». Todos asintieron. El Product Owner estaba contento, los desarrolladores la estimaron y entró en el Sprint Backlog. Tres días después estaba «terminada», y de inmediato fue objeto de disputa. El Product Owner esperaba un enlace por correo con caducidad; los desarrolladores habían construido un flujo de pregunta de seguridad. Ambas eran lecturas defendibles de una frase vaga. Es una situación anonimizada pero muy corriente, y la causa raíz es casi siempre la misma: el elemento no tenía criterios de aceptación.
Qué son realmente los criterios de aceptación
Los criterios de aceptación son las condiciones específicas y comprobables que un elemento del Product Backlog debe cumplir para que el Product Owner lo considere completo. No son la Definición de Terminado: la Guía Scrum describe la Definición de Terminado como el estándar de calidad compartido que se aplica a cada Incremento (pruebas superadas, código revisado, desplegable). Los criterios de aceptación son propios de un elemento: describen lo que esta historia, en concreto, debe hacer. Un equipo necesita ambos. «Terminado» es el listón que supera cada elemento; los criterios de aceptación dicen si este elemento hizo lo correcto.
Reescribir la historia de la contraseña con criterios lo cambia todo:
Dado que un usuario registrado solicita un restablecimiento, cuando envía su correo, entonces se envía un enlace de restablecimiento a esa dirección.
El enlace de restablecimiento caduca 30 minutos después de su emisión.
Un enlace caducado o ya usado muestra un mensaje claro y ofrece reenviarlo.
Tras un restablecimiento correcto, la contraseña anterior del usuario deja de funcionar.
Ahora no hay nada que discutir al final del Sprint. La conversación que habría sido una disputa tensa sobre una versión terminada ocurrió, en cambio, durante el refinamiento, de forma barata, antes de escribir una línea de código.
Hábitos que mantienen útiles los criterios
Escríbelos antes de que el elemento esté listo para el sprint. Los criterios de aceptación pertenecen al refinamiento del Product Backlog, no a la demo. Una historia sin ellos no está lista para planificarse.
Haz comprobable cada criterio. Si no puedes imaginar la comprobación que demuestra si es verdadero o falso, es un deseo, no un criterio. «Rápido» es un deseo; «responde en menos de dos segundos» es un criterio.
Que traten de resultados, no de implementación. Enuncia lo que el usuario debe poder hacer y deja a los desarrolladores margen para decidir cómo. Los criterios acotan el resultado, no el diseño.
Mantén el conjunto pequeño. Tres a seis condiciones nítidas valen más que quince vagas. Si una historia necesita una docena de criterios, probablemente sean dos historias.
Por qué esto importa más en un equipo distribuido
Cuando todos compartían una sala, una historia a medio definir podía sobrevivir a base de preguntas rápidas de aclaración de mesa a mesa. Con los equipos trabajando en remoto, ese canal de reparación informal es más débil y más lento. Unos criterios de aceptación escritos y comprobables portan el entendimiento compartido que antes daban las conversaciones de pasillo. No son burocracia: son el seguro más barato que tiene un Equipo Scrum contra construir bien lo equivocado.
Si tus equipos terminan una y otra vez trabajo que no acierta con la intención, la asesoría de entrega de programas y proyectos de XNM puede ayudarte a afinar cómo defines y aceptas el trabajo.