PMI PMP: Agile, Scrum y Entrega Híbrida — Guía de estudio

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Forma parte de la PMP — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de PMI, o realiza tests cronometrados en ExamRoll.io.

Roles, Ceremonias y Artefactos de Scrum

Scrum opera con una estructura de roles deliberadamente pequeña porque la difusión de la responsabilidad es uno de los principales modos de fallo en las entregas complejas. El Product Owner es el dueño del qué y el porqué: define el valor, prioriza el backlog y tiene la autoridad para aceptar o rechazar los incrementos. El Scrum Master es el dueño de qué tan bien se ejecuta el proceso: es un líder servicial que elimina impedimentos, asesora sobre prácticas ágiles y protege al equipo de interrupciones. Los Developers (el equipo de entrega completo, no solo los programadores) son los dueños del cómo: se autoorganizan para convertir los elementos del backlog en un incremento funcional en cada sprint.

Estos roles deben ser ocupados por personas reales y comprometidas. Un Product Owner poco comprometido o ausente es uno de los patrones más destructivos en la entrega ágil: sin su priorización y aceptación en tiempo real, las revisiones del sprint se convierten en reuniones de estado en lugar de eventos de validación de valor, los ciclos de retroalimentación se alargan y el equipo corre el riesgo de construir el producto equivocado. Cuando nos enfrentamos a un PO ausente, la acción correcta es escalar el problema al patrocinador y restablecer el rol, no que el Scrum Master tome las decisiones de forma permanente.

Las ceremonias principales forman un ciclo de retroalimentación cerrado:

Los artefactos —Product Backlog, Sprint Backlog e Incremento— tienen cada uno un compromiso asociado: el Objetivo del Producto (Product Goal), el Objetivo del Sprint (Sprint Goal) y la Definición de Hecho (Definition of Done), respectivamente. Estos compromisos son lo que evita que Scrum degenere en un “cascada iterativa”.

Gestión del Backlog e Historias de Usuario

El product backlog es una lista viva y ordenada, no un documento de especificaciones congelado al inicio del proyecto. El Product Owner lo mantiene en colaboración con el equipo, refinando los elementos para que la parte superior del backlog sea pequeña, bien entendida y lista para ser seleccionada. Una cadencia común es dedicar del 5 al 10 % de la capacidad del equipo al refinamiento del backlog en cada sprint.

Las historias de usuario siguen el patrón conocido: Como [persona], quiero [capacidad], para que [beneficio]. La cláusula del beneficio importa tanto como la capacidad; es lo que permite al equipo proponer soluciones alternativas y lo que permite al PO decidir si todavía vale la pena hacer la historia cuando las prioridades cambian.

Los criterios de aceptación son las condiciones observables y comprobables bajo las cuales el PO aceptará la historia. Se diferencian de la Definición de Hecho (DoD): los criterios de aceptación son específicos de la historia (¿la pantalla de inicio de sesión se bloquea después de cinco intentos fallidos?), mientras que el DoD es universal para cada historia (¿fue revisado el código, probado, documentado, desplegado en el entorno de staging?).

Cuando un stakeholder presenta un nuevo requisito a mitad del proyecto —incluso uno que se parezca a un trabajo anterior— el PO no debe simplemente soltar una fecha. La respuesta correcta es capturar la solicitud como un elemento candidato para el backlog, trabajar con el equipo para estimar su tamaño (quizás usando historias de referencia como anclas para la estimación relativa) y luego colocarlo en el backlog según su valor en relación con los elementos existentes. La similitud previa acelera la estimación del tamaño, pero no evita la conversación sobre la priorización.

DoR, DoD y Planificación de la Iteración

La Definición de Preparado (Definition of Ready o DoR) es una puerta de entrada a un sprint. Una historia está lista cuando es lo suficientemente pequeña como para completarse dentro de un sprint, tiene criterios de aceptación claros, se han identificado sus dependencias conocidas y es entendida por el equipo. Hacer cumplir el DoR evita que el equipo seleccione trabajo a medio hacer que se estancará a mitad del sprint por preguntas sin respuesta.

La Definición de Hecho (Definition of Done o DoD) es una puerta de salida. Es la lista de verificación compartida e innegociable que transforma un “terminamos de codificar” en “esto es un incremento potencialmente entregable”. Un DoD robusto generalmente incluye la superación de pruebas automatizadas, la revisión del código, escaneos de seguridad limpios, documentación actualizada y —críticamente— el cumplimiento de requisitos no funcionales como el rendimiento y la observabilidad. Involucrar a los equipos de operaciones y QA en la definición del DoD es lo que previene el patrón en el que un incremento “funciona” en la revisión del sprint pero colapsa bajo carga real en producción. Si el equipo de operaciones plantea una preocupación sobre el rendimiento después de un sprint y los datos ya existen en los logs, la respuesta madura es llevar esa preocupación al refinamiento, agregar umbrales de rendimiento al DoD y crear elementos en el backlog para abordar la brecha, no descartarla como “fuera del alcance”.

MVP, Planificación de Lanzamientos y Entrega Incremental

El Producto Mínimo Viable (Minimum Viable Product o MVP) es la porción coherente más pequeña que permite al equipo probar una suposición clave con usuarios reales. Su propósito es el aprendizaje, no simplemente la entrega. La planificación de lanzamientos se superpone a esto: dado un roadmap de un MVP seguido de lanzamientos incrementales, el equipo pronostica qué capacidades llegarán en cada lanzamiento utilizando la velocidad como una guía aproximada.

La entrega incremental es lo que le da a la organización opcionalidad: la capacidad de cambiar de dirección basándose en evidencia en lugar de opiniones. Esperar a un lanzamiento “completo” antes de mostrar algo a los usuarios es el antipatrón que las metodologías ágiles están diseñadas específicamente para prevenir.

Estimación, Puntos de Historia y Velocidad

Los puntos de historia miden el esfuerzo relativo, la complejidad y la incertidumbre, no la duración. Una historia de cinco puntos representa aproximadamente cinco veces el esfuerzo de una historia de un punto para ese equipo específico. La velocidad (puntos completados por sprint) surge entonces empíricamente a lo largo de varios sprints y se utiliza para pronosticar rangos, no para establecer compromisos de calendario.

Tratar los puntos de historia como días fijos es una trampa grave por varias razones. Primero, destruye la abstracción: si 1 punto = 1 día, el equipo simplemente estimará en días e inflará las estimaciones para cumplir con las fechas límite. Segundo, elimina la señal de incertidumbre: una historia de 13 puntos no es solo “larga”, es arriesgada, y ese riesgo debería desencadenar su descomposición. Tercero, permite que la gerencia use los números como un arma (“dijeron 40 puntos, ¿por qué solo terminaron 32?”), lo que impulsa un comportamiento de protección o “sandbagging”. El uso correcto es: tendencia de la velocidad + tamaño del backlog → pronóstico probabilístico de lanzamiento, comunicado como un rango.

Gestión de Impedimentos, Interrupciones y Flujo

El trabajo más tangible del Scrum Master es la eliminación de impedimentos. Cuando un miembro del equipo tiene dificultades en silencio —quizás por orgullo o por ser nuevo para plantearlo— el líder del equipo debe intervenir directamente, entender el impedimento y ayudar a resolverlo o escalarlo. Ignorar el propósito del standup diario es lo que permite que este patrón se agrave; la asistencia inconsistente al standup crea silos de conocimiento, oculta bloqueadores y permite que pequeños problemas se conviertan en riesgos para el cronograma. La asistencia no es negociable precisamente porque el valor de la ceremonia reside en la sincronización, no en el reporte de estado.

Las interrupciones ad-hoc —la solicitud “urgente” que omite el backlog— son igualmente corrosivas. Erosionan el objetivo del sprint, invalidan el pronóstico y enseñan a los stakeholders que el proceso puede ser eludido. El manejo correcto es dirigir las nuevas solicitudes a través del PO, quien decide si justifican una cancelación del sprint (raro) o si pertenecen a un sprint futuro (lo habitual).

Para equipos híbridos donde las pruebas u otra disciplina se convierten en un cuello de botella, la visualización del flujo mediante tableros Kanban y gráficos burndown/burnup expone la restricción. Si el equipo identifica una herramienta que podría desbloquear las pruebas, el gestor del proyecto no debe aprobarla o rechazarla unilateralmente; debe evaluar la propuesta de forma colaborativa, verificar la gobernanza organizacional (adquisiciones, seguridad), consultar al PO sobre el impacto en el backlog y luego decidir. La aprobación reflexiva omite la debida diligencia; la negación reflexiva ignora la experiencia del equipo.

Retrospectivas y Mejora Continua

Las retrospectivas cierran el ciclo. Una buena retrospectiva produce una o dos acciones de mejora concretas y con un responsable asignado, no una sesión de desahogo. Incluir a operaciones y QA en las retrospectivas desde el principio previene los clásicos fallos en las transferencias, donde los equipos optimizan para las demos de fin de sprint pero no para la realidad de producción. La mejora continua es el mecanismo que mantiene la honestidad de la velocidad, el significado del DoD y el alto compromiso del equipo a lo largo de la vida del producto.

Problema Práctico: Escenario de Caso de Uso

Escenario: Priya Nair es la Scrum Master del equipo de la billetera móvil “LumenPay” en una empresa fintech. El equipo trabaja en sprints de dos semanas y está compuesto por seis desarrolladores, un ingeniero de QA y un diseñador de UX. Durante los últimos tres sprints, el Product Owner, Marcus Reeves, solo ha asistido a una sesión de planificación de sprint y a ninguna revisión de sprint, citando conflictos de responsabilidades como jefe de Alianzas Minoristas (Retail Partnerships). Los stakeholders de Cumplimiento (Compliance) y Operaciones de Fraude (Fraud Ops) han comenzado a enviar correos electrónicos directamente a los desarrolladores con solicitudes de prioridad contradictorias, y el equipo ha arrastrado 34 de 82 puntos de historia en los dos últimos sprints. La patrocinadora, la VP de Producto Anita Chen, está empezando a cuestionar la velocidad del equipo.

Desafío: Priya debe restaurar la participación del Product Owner y detener la fragmentación del backlog sin sobrepasar su rol de líder servicial tomando decisiones de producto por sí misma.

Enfoque Recomendado:

1. Documentar los impactos específicos de la ausencia del PO durante los últimos tres sprints —puntos arrastrados, criterios de aceptación ambiguos, elementos del backlog sin resolver y el número de solicitudes directas de stakeholders que eluden al PO— para construir un caso basado en hechos.
2. Tener primero una reunión uno a uno con Marcus, compartiendo los datos y preguntándole directamente si puede comprometer las 10-15 horas semanales que requiere el rol, o si el rol necesita ser reasignado o dividido.
3. Escalar formalmente a Anita Chen con la evidencia documentada, presentando dos opciones: reasignar el rol de PO a alguien con capacidad, o negociar una reducción en las responsabilidades de Marcus en Alianzas Minoristas.
4. Orientar al equipo de desarrollo para que redirija todas las solicitudes entrantes de los stakeholders al backlog del producto en lugar de aceptarlas ad hoc, y reforzar que solo el PO puede repriorizar.
5. Una vez que se confirme un PO comprometido, realizar un taller de refinamiento del backlog para reajustar las prioridades, limpiar los criterios de aceptación y restablecer el objetivo del sprint para la siguiente iteración.
6. Establecer un acuerdo de trabajo que especifique la asistencia del PO a la planificación, la revisión y al menos a dos sesiones de refinamiento por sprint.

Por qué Funciona Esto: Escalar la vacancia al patrocinador preserva la integridad del rol: el Scrum Master no debe convertirse en un Product Owner sustituto, porque eso enmascara permanentemente el problema organizacional y compromete la priorización basada en el valor. Basar la escalada en métricas concretas mantiene la conversación centrada en los resultados de la entrega en lugar de en las personalidades, y redirigir el tráfico de los stakeholders a través del backlog restaura la disciplina de una única fuente de verdad de la que depende Scrum.

← Liderazgo de Equipos y Gestión de Recursos · Todos los dominios · Alcance →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →