Siete comprobaciones antes de empezar
Utiliza esta lista en el refinamiento. Una respuesta negativa abre una conversación; no descarta automáticamente el ticket.
1. Objetivo
¿Qué problema resolvemos, para quién y cómo reconoceremos el resultado? Explica el valor antes de describir la implementación.
2. Alcance
¿Qué pantalla, servicio o flujo está incluido? ¿Qué queda fuera? Separa cambios independientes cuando requieren decisiones distintas.
3. Comportamiento esperado
¿Qué hace la persona, qué muestra el sistema y qué cuenta como éxito? En un error, registra tanto el comportamiento real como el esperado.
4. Roles y permisos
¿Quién puede realizar la acción? Comprueba los permisos existentes. No inventes un rol nuevo porque falte un dato en el ticket.
5. Casos límite y errores
Prioriza los casos que pueden cambiar la solución: en una exportación, por ejemplo, el resultado vacío y una petición fallida. Aclara qué verá el usuario, si podrá reintentar y si existe éxito parcial.
6. Dependencias
¿Están disponibles API, diseño, contenido, datos y accesos? Enlaza la fuente de referencia y asigna una persona responsable a cada dependencia pendiente.
7. Criterios de aceptación
¿Se puede comprobar si el trabajo está terminado? Escribe condiciones observables a partir de requisitos confirmados. La guía de criterios de aceptación explica cómo evitar los supuestos.
¿Bloqueo o pregunta normal?
Un bloqueo es una decisión cuya respuesta puede alterar sustancialmente la solución. Antes de diseñar un pago hay que saber si es único o recurrente. La etiqueta final de un botón quizá pueda decidirse mientras avanza la lógica; aun así, registra quién la decidirá y cuándo.
El límite depende de la tarea. La comparación de Definition of Ready y criterios de aceptación explica la decisión de empezar. Cuando cierres las lagunas importantes, estima la tarea. La herramienta de preparación de tareas ayuda a detectar decisiones abiertas antes del refinamiento.