Capítulo 11. Alcance, requisitos, trabajo pendiente priorizado y entregables

Justificación: La repriorización del backlog es el mecanismo natural de gestión del alcance en proyectos ágiles. No es scope creep porque el Product Owner tiene autoridad para repriorizar el trabajo pendiente. El proceso formal de control integrado de cambios aplica en contextos predictivos o para componentes con línea base aprobada, no para la gestión dinámica del backlog. La directora de proyectos debe reconocer cuándo el proceso de adaptación es legítimo.

Justificación: Un backlog con ítems mal definidos y sin priorizar es un riesgo de gestión: el equipo pierde tiempo en cada sprint buscando claridad en lugar de entregar valor. La solución estructural es establecer sesiones regulares de refinamiento del backlog (backlog refinement) para garantizar que siempre haya una cantidad suficiente de ítems bien definidos, estimados y priorizados para los próximos sprints. Esta es la práctica ágil estándar para ese problema.

Justificación: Ante scope creep detectado —trabajo no autorizado ejecutado en un componente con línea base aprobada— la primera acción del director de proyectos es cuantificar el impacto y formalizar la situación a través del proceso de control de cambios. Esto permite decidir con información: ¿se incorpora la mejora a la línea base con ajuste de cronograma o costo? ¿O se descarta? Ambas decisiones requieren datos del esfuerzo invertido.

Justificación: Cuando un entregable cumple los criterios de aceptación pero el cliente lo rechaza, el problema es de expectativas, no de calidad. El director de proyectos debe: (1) revisar con el cliente cuáles criterios específicos considera que no se cumplen —esto puede revelar una brecha en la definición original— y (2) gestionar la brecha entre criterios acordados y expectativas actuales mediante una conversación que alinee ambas partes. No debe aceptar el rechazo sin análisis ni escalar sin haber intentado la resolución.

Justificación: Aplicando las fórmulas corregidas de la segunda impresión del PMBOK 8: Arrastre de alcance (%) = (Entregables no planificados / Total de entregables) × 100 = 6/(40+6) × 100 = 6/46 × 100 ≈ 13%. Sin embargo, si el denominador es el total de la línea base original (40): 6/40 × 100 = 15%. La formulación correcta usa el total de entregables actuales o el total de la línea base según el contexto. La opción B usa el denominador de la línea base (40) para arrastre = 15%, y estabilidad = 90/120 = 75%. Nota: el examen puede presentar la fórmula con ambos denominadores posibles; lo crítico es no invertir numerador y denominador.

Justificación: El director de proyectos tiene un rol facilitador en la interfaz entre el equipo técnico y el Product Manager. La deuda técnica tiene un costo de retraso que no siempre está visible en el WSJF calculado originalmente. Hacer ese costo visible —con datos— permite que el Product Manager tome una decisión informada. Si el WSJF se recalcula incluyendo el impacto de la deuda técnica, la priorización resultante puede ser diferente. El director de proyectos no debe tomar la decisión por ninguna de las partes.

Justificación: La Definition of Done es un contrato interno del equipo que define cuándo un ítem está completo. Si los ítems cumplen la DoD pero el cliente los rechaza repetidamente, la señal más probable es que la DoD está desactualizada respecto de las expectativas del cliente. La retroactiva es el espacio natural para revisar y actualizar acuerdos de proceso. Involucrar al cliente en esa conversación asegura que la DoD actualizada refleje sus expectativas reales.

Justificación: La secuencia correcta de la gestión del alcance en proyectos predictivos sigue el orden lógico del grupo de procesos de planificación: primero se recopilan los requisitos (se entiende qué necesita el cliente), luego se define el alcance (se elabora el enunciado del alcance), luego se crea la EDT (se descompone el alcance en entregables manejables), luego se valida el alcance con el cliente (se obtiene aceptación formal de los entregables), y finalmente se controla el alcance durante toda la ejecución.

Justificación: En un enfoque híbrido, los componentes predictivos tienen línea base aprobada y están protegidos por el proceso de control integrado de cambios. Un requisito emergente del componente ágil que afecta al componente predictivo debe gestionarse formalmente: documentar el requisito, evaluar el impacto en los paquetes de trabajo de la línea base y seguir el proceso de control de cambios. Tratar la interfaz entre componentes con rigor es la competencia central de la gestión híbrida.

Justificación: Cuando el backlog acumula Must Have sin capacidad para ejecutarlos, el director de proyectos debe hacer dos cosas: facilitar la revisión de si los nuevos ítems realmente califican como Must Have (MoSCoW requiere criterio riguroso: «sin esto el proyecto fracasa») y mostrar los datos reales de capacidad para que la decisión sea informada. No es su rol rechazar ni aceptar unilateralmente, sino facilitar la toma de decisión con información.

Justificación: La EDT es una jerarquía de entregables y sub entregables, no una lista de actividades. «Coordinar con proveedores» y «revisar planos» son actividades del cronograma, no entregables del proyecto. Los entregables se expresan como resultados: «informe de factibilidad», «planos aprobados», «contrato firmado con proveedor». Este error conceptual es muy frecuente y el examen lo evalúa directamente.

Justificación: MoSCoW sirve para priorizar ítems del backlog según valor y urgencia —ideal para acordar prioridades entre múltiples interesados (a→3). La EDT descompone entregables estables en paquetes de trabajo para planificar el cronograma (b→1). La matriz de trazabilidad de requisitos vincula requisitos con entregables y objetivos para verificar cobertura (c→4). Los criterios de aceptación definen las condiciones específicas que un entregable debe cumplir para ser aceptado —cuando el cliente rechaza, se revisa cuál criterio no se cumple (d→2).

Justificación: Una solicitud de cambio fuera de la línea base de un contrato de precio fijo requiere el proceso formal de control de cambios, con evaluación de impacto en todas las dimensiones (alcance, cronograma, costo, riesgo) y presentación de opciones al cliente. No se puede incorporar el módulo sin ajuste contractual, ni rechazarlo sin análisis. El director de proyectos documenta, evalúa y presenta opciones.

Justificación: Un backlog con ítems viejos, sin estimación ni criterio de valor claro, acumula «deuda de producto»: ruido que dificulta la priorización real y genera frustración en el Product Owner porque el equipo entrega velocidad pero no el valor correcto. La solución es una sesión de limpieza del backlog (backlog grooming/pruning) donde se descarten los ítems que no tienen valor demostrable o se reprioricen los que sí lo tienen.

Justificación: Ante scope creep detectado, la primera acción es documentar y cuantificar para poder tomar una decisión informada. ¿Se incorpora la mejora a la línea base con ajuste de cronograma o se descarta? Ambas opciones requieren una solicitud de cambio formal. La conversación informal del sponsor no autoriza el inicio de trabajo fuera de la línea base.

Justificación: Aplicando las fórmulas corregidas: Arrastre = 4/(35+4) = 4/39 ≈ 10,3% (denominador = total actual de entregables). Estabilidad = 105/150 = 70% (denominador = total inicial de requisitos). Los 18 requisitos incorporados por cambios aprobados modificaron el estado de los requisitos originales —por eso no cuentan como 'sin cambios'— pero fueron gestionados formalmente y no son scope creep. Nota: el denominador del arrastre puede ser el total de la línea base o el total actualizado según cómo lo plantee el enunciado; lo crítico es no invertir numerador y denominador.

Justificación: Requisitos contradictorios en el backlog deben resolverse antes de ejecutarlos, no durante. El mecanismo correcto es una sesión con los interesados afectados —área clínica, área legal y Product Owner— para identificar cuál es el requisito válido, actualizar los criterios de aceptación de ambas historias y garantizar coherencia antes de iniciar el desarrollo. No se debe tomar la decisión de forma unilateral.

Justificación: En proyectos híbridos, las interfaces entre componentes son puntos de riesgo. Cuando un requisito del componente ágil afecta a la línea base del componente predictivo, el proceso correcto es analizar el impacto conjuntamente y, si se decide proceder, seguir el control formal de cambios para el componente predictivo. Ninguna de las dos partes puede imponer su lógica a la otra.

Justificación: El alcance del proyecto describe el trabajo necesario para producir el resultado. Las actividades de diseño, desarrollo, pruebas, capacitación y puesta en producción son el trabajo del proyecto. El alcance del producto, en cambio, son las características de la aplicación: funcionalidad de seguimiento, integración con pasarela de pagos, etc.

Justificación: Ante una solicitud masiva de nuevas funcionalidades de un sponsor, el proceso correcto no es aceptar ni rechazar, sino involucrar al Product Owner, analizar las funcionalidades con criterio de valor/esfuerzo y agregar al backlog solo las que superen el umbral de valor definido. El backlog no es una lista de deseos: requiere una priorización rigurosa.

Justificación: Requisitos contradictorios en el alcance aprobado de un proyecto predictivo son un problema que debe resolverse formalmente: involucrar a los interesados clave para identificar la contradicción, acordar la solución y actualizar el enunciado del alcance mediante el proceso de control de cambios. Implementar los más simples o escalar sin análisis no resuelve el problema.

Justificación: La ausencia del Product Owner es un impedimento que el director de proyectos debe gestionar, no reemplazar ni escalar directamente. La primera acción es entender las razones de la ausencia, hacer visible el impacto en el producto y acordar una modalidad sostenible de participación. Asumir el rol de Product Owner mezcla responsabilidades y reduce la accountability.

Justificación: El proceso formal de control de cambios aplica a todos los cambios, independientemente del tamaño. No existe un umbral informal que justifique procesar cambios menores sin documentación. Además, el director de proyectos tiene la responsabilidad de explicar a los interesados cómo funciona el proceso y orientarlos en cómo presentar sus solicitudes correctamente.

Justificación: En proyectos híbridos, el director de proyectos debe gestionar las interfaces con criterio. Antes de bloquear el sprint ágil o iniciar formalmente el proceso de cambio de la línea base predictiva, debe analizar si existe una solución alternativa temporal que permita avanzar al componente ágil sin modificar la línea base. Esto es pensamiento sistémico: buscar opciones antes de escalar o bloquear.

Pregunta 25a — Respuesta correcta: B

Justificación: El trabajo del equipo de riesgo crediticio es scope creep. Independientemente del valor técnico del algoritmo, fue ejecutado fuera del proceso de priorización acordado con el Product Owner. El criterio PMP es claro: si el trabajo no fue autorizado por el mecanismo correcto (en este caso, la priorización del backlog por el Product Owner), es trabajo no autorizado. El valor del resultado no cambia la naturaleza del proceso.

Pregunta 25b — Respuesta correcta: C

Justificación: Un hallazgo de compliance legal que afecta la operabilidad del producto tiene prioridad máxima. Pablo debe comunicarlo de inmediato a todos los interesados relevantes, cuantificar el impacto en el sprint actual y las iteraciones siguientes, y repriorizar antes de comenzar el sprint 6. No puede continuar con la planificación original si sabe que dos ítems Must Have generan riesgo legal.

Pregunta 25c — Respuesta correcta: A

Justificación: La causa raíz del problema del sprint 5 es la desconexión entre el equipo técnico y el Product Owner sobre qué trabajo tiene valor y prioridad. La medida estructural es garantizar esa conexión en sesiones de refinamiento del backlog antes de cada sprint. Esto no elimina la autonomía técnica del equipo, sino que la canaliza hacia el valor correcto.