Gestión de producto y backlog
Aquí se evalúa si sabes convertir una visión de producto en un backlog ordenado y comprensible, y si distingues gestión de producto de gestión de tareas.
Del Product Goal al Sprint
El Product Goal describe el estado futuro del producto y da dirección al backlog, que es emergente: nunca está "terminado". El refinamiento es continuo y descompone ítems en piezas pequeñas, valiosas y verificables; no es un evento formal, aunque muchos equipos reservan una fracción del Sprint para él.
Ordenar con criterio
El PO ordena por valor, riesgo, coste de retraso y dependencias, no por quién grita más. Herramientas útiles: historias de usuario con INVEST, criterios de aceptación explícitos, corte vertical para entregar valor de extremo a extremo, y priorización por coste de retraso frente a tamaño (WSJF), MoSCoW o valor frente a esfuerzo. La decisión final es del PO, informada por el equipo y los datos.
Ejemplo razonado
Dos ítems: A tiene coste de retraso alto y esfuerzo alto; B tiene coste de retraso alto y esfuerzo bajo. Con WSJF, B puntúa más alto y va primero, porque maximiza valor entregado por unidad de tiempo. Ordenar "lo más fácil primero" sin considerar el coste de retraso posterga lo urgente; ordenar solo por "lo que pide dirección" ignora el impacto.
Errores que cuestan puntos
Mantener un backlog como lista de deseos sin orden ni transparencia; confundir historia de usuario con tarea técnica; aceptar nuevos ítems sin reordenar ni comunicar el efecto; usar la velocidad como única medida de valor; y presentar un roadmap como compromiso contractual fijo.