Los pull criteria o criterios de extracción son las condiciones que deben cumplirse para que una tarjeta pueda avanzar de una columna a la siguiente en un sistema Kanban. Definirlos correctamente es fundamental para mejorar el flujo de valor y la calidad del trabajo.
¿Qué son los pull criteria?
Los pull criteria son las reglas explícitas que definen cuándo el trabajo puede "ser jalado" hacia la siguiente fase del proceso. A diferencia de sistemas push donde el trabajo se empuja independientemente de la capacidad, Kanban utiliza pull para sincronizar el flujo con la demanda real.
Ejemplos de pull criteria:
- "La historia de usuario tiene criterios de aceptación completos antes de entrar en desarrollo."
- "El código ha pasado revisión de pares antes de pasar a pruebas."
- "Las pruebas automatizadas están en verde antes del despliegue."
Beneficios de definir pull criteria
Unos pull criteria bien definidos aportan múltiples beneficios al sistema:
- Calidad consistente: el trabajo cumple estándares mínimos antes de avanzar.
- Reducción de retrabajo: los defectos se detectan antes en el flujo.
- Transparencia: todos los miembros del equipo conocen las expectativas.
- Mejora continua: los pull criteria evolucionan con el aprendizaje del equipo.
Cómo definir buenos pull criteria
Para que los pull criteria sean efectivos deben ser:
- Específicos: describir condiciones concretas y verificables.
- Acordados: definidos colaborativamente por el equipo.
- Visibles: publicados en el tablero o en un lugar accesible.
- Mantenibles: revisados y actualizados regularmente.
Pull criteria y flujo de valor
Los pull criteria contribuyen directamente a mejorar el flujo de valor:
- Reducen la variabilidad del proceso al establecer condiciones de entrada/salida claras.
- Disminuyen el trabajo en progreso al evitar que trabajo incompleto avance.
- Mejoran la predictibilidad al crear transiciones más consistentes.
- Facilitan la identificación de cuellos de botella y problemas de proceso.
Evolucionar los pull criteria
Los pull criteria no son estáticos. Deben evolucionar con el equipo mediante:
- Revisión regular en cadence meetings o retrospectivas.
- Análisis de los bloqueos y defectos recurrentes.
- Incorporación de aprendizajes de incidentes de calidad.
- Adaptación a los cambios en el contexto del equipo y del producto.
Formación relacionada en ITNOVE
- Professional Scrum with Kanban (PSK) — Scrum.org · PSK