Un Product Backlog de 380 elementos y un criterio de orden que es «quien grita más fuerte»
La nueva Product Owner de una aseguradora hereda un Product Backlog de 380 elementos en una hoja de cálculo. No hay orden explícito: el criterio real ha sido quién grita más fuerte en la reunión de los martes, a la que asisten 22 personas de negocio. El elemento en primera posición es «migrar la base de datos a PostgreSQL», sin descripción de valor ni criterio de aceptación. El refinamiento se hace en sesiones de tres horas con quince participantes y nunca se llega más allá del elemento 12. En paralelo, un comercial añade cada semana entre 8 y 12 peticiones nuevas, algunas etiquetadas como «urgente» y con una fecha contractual detrás. El equipo entrega unos 30 puntos por Sprint, mientras la hoja crece a un ritmo estimado de 40 puntos por Sprint. El director de negocio pregunta cuándo estará «todo» y ha ofrecido contratar a dos personas más si con eso se llega antes.
1. ¿Cómo establecerías un criterio de ordenación defendible ante el negocio, y por qué no basta con puntuar «valor» en una escala de 1 a 10?
Read the worked answer
Por qué el valor 1-10 no basta. Una escala abstracta sin definición compartida produce números incomparables: cada área puntúa su petición como 9 porque no hay consecuencia por exagerar, y el resultado es la misma lista ordenada por poder político, solo que con apariencia de objetividad. Además, el valor no captura el coste de retraso ni el aprendizaje: un elemento barato que desbloquea decisiones puede valer más que un 10 caro.
Criterios que sí se pueden defender:
- Coste de retraso (impacto de no tenerlo este trimestre), no valor absoluto.
- Riesgo y aprendizaje: elementos que reducen incertidumbre técnica, regulatoria o de negocio suben.
- Dependencias y habilitadores: trabajo técnico explícito, con el valor que desbloquea declarado. Eso resuelve el caso PostgreSQL: o se formula como habilitador con un beneficio medible y una fecha límite, o baja.
- Tamaño relativo, para comparar lotes pequeños con grandes.
Mecánica: una matriz simple (impacto, confianza, esfuerzo, dependencia) para conversar, no para decidir automáticamente. La PO ordena; la matriz ordena la discusión. Y el criterio se publica: cualquier persona debe poder entender por qué su elemento está donde está y qué lo haría subir.
Sobre contratar dos personas: responder con datos. Si el backlog crece a 40 puntos por Sprint y se entregan 30, añadir capacidad no reduce la lista si la entrada no se gobierna; primero se corta la entrada, después se habla de capacidad.
2. Diseña un plan de saneamiento del backlog para las tres próximas sesiones de refinamiento, con reglas de decisión explícitas.
Read the worked answer
Regla previa: cerrar la entrada antes de limpiar. Mientras entren 8-12 peticiones semanales, cualquier limpieza se deshace en un mes. Se acuerda una única puerta de entrada (formulario con problema, impacto y quién lo pide) y un compromiso de respuesta en cinco días hábiles.
Sesión 1 (90 min, 6 personas): deduplicar y cerrar. Criterio de cierre automático y comunicado: sin movimiento ni fecha contractual en 90 días, o duplicado de otro elemento. Estimación realista: el 30-40% del backlog cae. Se avisa a los solicitantes antes, con opción de reabrir con justificación.
Sesión 2: agrupar por resultado, no por petición. Convertir los 380 en 15-25 temas ligados a objetivos de negocio. Los temas permiten decir que no sin decir que no a una persona concreta.
Sesión 3: primeros 20 elementos listos. Solo esos. Cada uno con descripción del problema, criterio de aceptación y una pregunta abierta.
Cambios de formato permanentes: refinamiento de 60-90 minutos máximo, cinco o seis asistentes con poder de decisión, y una regla dura: no se refina lo que no se va a construir en las próximas dos Sprints. Las sesiones de tres horas con quince personas producen agotamiento, no claridad.
Comunicación al director: no habrá una fecha para «todo», habrá una fecha para el primer conjunto de resultados y un ritmo de entrada controlado.
3. Un comercial añade una petición urgente a mitad de Sprint, con penalización contractual si no está en 10 días. ¿Qué opciones tienes y cuál recomiendas?
Read the worked answer
El error de base es que la fecha se negocie sin el equipo. Aun así, el problema es real y hay que dar una respuesta, no una lección de Scrum.
Opción 1: intercambio de alcance. La PO saca del Sprint un elemento de tamaño comparable. Se protege el Sprint Goal y la fecha. Requiere que la PO tenga autoridad real y que el equipo estime rápido (una hora, no un día).
Opción 2: añadir al backlog y dar una previsión. Se calcula con datos de las últimas Sprints y se responde con una fecha probable y su incertidumbre. Es la opción honesta si la penalización no es catastrófica.
Opción 3: cancelar el Sprint y re-planificar. Solo si el Sprint Goal queda inválido: es decir, si lo urgente hace que el objetivo actual deje de tener sentido. Si el objetivo sigue siendo válido, cancelar es sobreactuar.
Recomendación: Opción 2 combinada con Opción 1 cuando la penalización sea superior al coste del intercambio.
Además, la conversación de fondo con negocio: el problema no es esta petición, es que comerciales firman fechas sin pasar por la PO. Proponer una política de intake con un SLA de respuesta de 48 horas y una regla clara: la fecha la da la PO con la previsión del equipo, no el comercial en el contrato. Sin esa política, la situación se repetirá cada mes y el equipo pagará el coste en interrupciones y en calidad.