Quiz: Simulacro Scrum final (formación de personal)


Simulacro Scrum finalOnline version Curso de preparación - Scrum Master Professional Certification – SMPC® \| Certiprof by Cindy Mariana ARIZA RODRIGUEZ 1 Un gerente de TI adopta agilidad eliminando toda la documentación, actas y Jira, afirmando que solo importa programar y entregar. Tres meses después, el equipo repite errores y los nuevos integrantes desconocen decisiones de arquitectura. Según el Manifiesto Ágil, ¿cuál es el análisis más preciso? a El gerente malinterpretó el valor "software funcionando sobre documentación exhaustiva": el valor prioriza, no elimina; la falta de registro de decisiones es justamente el desperdicio que el equipo ahora paga con errores repetidos b El gerente interpretó correctamente el manifiesto: la agilidad significa eliminar toda documentación y herramientas formales c El problema no tiene relación con el Manifiesto Ágil, sino con la rotación de personal del equipo d El equipo debió usar Scrum en lugar de prácticas ágiles genéricas para evitar este problema 2 Una organización financiera adopta agilidad, pero mantiene contratos de alcance fijo por requisitos legales. El equipo afirma que esto contradice el Manifiesto Ágil. El líder de PMO responde que los contratos no se eliminan; cuando existe conflicto, debe priorizarse la colaboración con el cliente sobre seguir estrictamente el contrato. ¿Es correcta esta interpretación? a No, porque el Manifiesto Ágil prohíbe expresamente cualquier tipo de contrato de alcance fijo b Sí, es correcta: el valor no elimina los contratos, establece que cuando haya tensión entre cumplir la letra del contrato y atender lo que genera valor real al cliente, la colaboración guía la decisión c No, porque sin importar el contexto, los contratos legales siempre deben tener prioridad sobre cualquier valor ágil d Es parcialmente correcta, pero solo aplica a proyectos de software, no a proyectos financieros 3 Un equipo entrega software cada 2 semanas durante 8 meses, pero cada entrega genera defectos críticos, aumenta la deuda técnica y provoca agotamiento por trabajo en fines de semana. Según los 12 principios del Manifiesto Ágil, el Scrum Master concluye que se priorizó un principio mientras se descuidaron gravemente otros dos. ¿Cuáles? a El principio de simplicidad y el de individuos motivados, que no tienen relación con calidad técnica b El principio de conversación cara a cara y el de arquitecturas emergentes de equipos auto-organizados c La atención continua a la excelencia técnica y el desarrollo sostenible a ritmo constante — ambos sacrificados por cumplir la cadencia de entregas a cualquier costo d Ninguno; cumplir las entregas frecuentes es suficiente para considerarse un equipo ágil exitoso 4 Durante una sesión de planeación estratégica, el director de un área de innovación presenta la Declaración de Interdependencia (DOI) como "la versión actualizada y oficial del Manifiesto Ágil que lo reemplaza", y propone descontinuar el uso del Manifiesto en la organización. Un Scrum Master experimentado interviene. ¿Cuál es la corrección más precisa que debería hacer? a Confirmar que el director tiene razón, ya que la DOI es cronológicamente posterior y por tanto sustituye al Manifiesto b Indicar que ninguno de los dos documentos es relevante una vez que la organización ya implementó Scrum como framework c Aclarar que la DOI y el Manifiesto son exactamente el mismo documento con nombres distintos según la región geográfica d Aclarar que la DOI no reemplaza ni actualiza al Manifiesto: son documentos complementarios de distinto nivel — el Manifiesto define valores de desarrollo de software, mientras que la DOI aporta 6 valores de gestión de proyectos ágiles en general 5 Un equipo de manufactura elimina la capacitación cruzada y reduce a cero el inventario de repuestos críticos porque considera que no agregan valor al cliente. Tras una falla, la producción se detiene 4 días y nadie puede operar la máquina de respaldo. Según Lean, ¿qué error conceptual cometió el equipo? a Ninguno; eliminar inventario y capacitación cruzada es exactamente lo que dicta el pensamiento Lean sin excepciones b El problema fue exclusivamente de mantenimiento de máquinas y no tiene relación con los principios Lean c El error fue no haber implementado Scrum en lugar de Lean para la manufactura d Confundieron "desperdicio" con cualquier costo o inversión visible, sin distinguir entre desperdicio real (lo que no aporta valor) e inversión necesaria para sostener flujo y capacidad de respuesta — el pensamiento Lean también exige respetar al equipo y sostener el flujo, no solo cortar costos 6 Un Scrum Master nuevo en la organización encuentra que el equipo anterior documentó un "Manual de Procesos Scrum" de 40 páginas que detalla exactamente qué debe decir cada Developer en el Daily, qué plantilla usar para cada historia de usuario, y un checklist obligatorio de 25 puntos antes de cualquier despliegue. El equipo afirma: "Esto nos ha dado consistencia y todos sabemos qué esperar." ¿Cómo evalúa esta situación un Scrum Master que comprende la teoría de Scrum? a Es una práctica recomendada, ya que más documentación siempre mejora la adherencia a Scrum b Es completamente inválido, ya que Scrum prohíbe cualquier tipo de documentación de proceso, sin excepciones c Puede contradecir Scrum: el marco es deliberadamente incompleto y se basa en la inteligencia del equipo. Las plantillas no son el problema, salvo que sustituyan la adaptación y el criterio del equipo. d Es irrelevante para la teoría de Scrum, ya que estos asuntos pertenecen únicamente a la gestión de calidad 7 Después de 6 sprints, un equipo afirma que Scrum no funciona porque los problemas de calidad continúan. Un Agile Coach observa que el Sprint Review se realiza sin stakeholders, el Daily es un reporte al Scrum Master y la Retrospectiva suele cancelarse. Según la teoría de Scrum, ¿cuál es el diagnóstico correcto? a Scrum efectivamente no es un framework adecuado para este equipo y deberían volver a un enfoque tradicional b El equipo no está aplicando Scrum realmente: fallan la transparencia, inspección y adaptación, por lo que sus pilares empíricos están rotos. El problema no es Scrum, sino su mala implementación. c El problema es que 6 sprints es insuficiente tiempo para ver resultados, se necesitan al menos 20 sprints d El problema radica únicamente en la falta de habilidades técnicas de los desarrolladores 8 Un Product Owner argumenta: "El empirismo de Scrum significa que no debemos planear nada por adelantado, solo reaccionar a lo que sucede sprint a sprint." Un Scrum Master responde que esta es una mala interpretación. ¿Cuál es la explicación correcta del empirismo según la Guía Scrum 2020? a El empirismo establece que el conocimiento proviene de la experiencia y de la toma de decisiones basada en lo observado — esto no prohíbe planear, sino que exige que los planes se ajusten constantemente según lo que se aprende, en lugar de seguirse rígidamente sin importar la nueva información b El PO tiene razón: el empirismo elimina toda forma de planeación anticipada c El empirismo solo aplica a proyectos de menos de 3 meses de duración d El empirismo es sinónimo exacto de la adaptación, uno de los tres pilares 9 Una organización tiene dos equipos: el Equipo A inspecciona su trabajo cada día en el Daily pero nunca ajusta su plan basándose en lo que descubre (siguen el plan original sin importar lo que aprenden). El Equipo B ajusta constantemente su trabajo, pero nunca hace visibles sus avances o bloqueos a nadie fuera del equipo. Según los 3 pilares empíricos, ¿qué le falta a cada equipo respectivamente? a Al Equipo A le falta adaptación (inspeccionan pero no ajustan); al Equipo B le falta transparencia (ajustan pero no hacen visible su trabajo, lo cual además vicia su propia inspección) b Al Equipo A le falta transparencia; al Equipo B le falta inspección c A ambos equipos les falta lo mismo: coraje, uno de los 5 valores de Scrum d Ninguno de los dos tiene ningún problema, ya que cada equipo puede priorizar libremente los pilares que más le convengan 10 Un equipo decide que, dado que "Scrum es deliberadamente incompleto y se basa en la inteligencia colectiva del equipo", pueden eliminar el Sprint Planning por completo, ya que "el equipo ya sabe qué hacer y discutirlo formalmente es una pérdida de tiempo". Después de 2 sprints sin Planning, el equipo reporta confusión sobre las prioridades reales y trabajo duplicado entre Developers. ¿Qué malinterpretación del marco de Scrum cometió el equipo? a Ninguna; eliminar eventos formales es exactamente lo que "deliberadamente incompleto" significa según la Guía Scrum b Confundieron que Scrum sea incompleto con que sus eventos sean opcionales. Scrum no define cómo hacer el trabajo, pero sus eventos, incluido el Sprint Planning, son esenciales para la transparencia, inspección y adaptación. c El problema es que el equipo necesitaba más Developers, no más eventos formales d No hay ningún malentendido; la confusión y el trabajo duplicado se debían a falta de experiencia técnica, no a la ausencia del evento 11 Durante un Sprint, una Developer descubre que una decisión técnica que ella propuso dos semanas atrás está causando un problema de rendimiento grave en producción. Tiene dos opciones: corregirlo discretamente sin mencionar el origen del problema, o comunicarlo abiertamente al equipo y al Product Owner, asumiendo que esto podría afectar la percepción de su desempeño técnico. Decide comunicarlo abiertamente de inmediato. ¿Qué combinación de valores de Scrum demuestra principalmente esta decisión? a Foco y Respeto, porque mantiene la atención en el Sprint Goal b Compromiso únicamente, ya que se compromete a arreglar el problema c Apertura (comunicar el problema y su origen sin ocultar información) y Coraje (asumir el riesgo personal de admitir el error) d Ninguno de los 5 valores aplica a decisiones individuales, solo a decisiones de equipo 12 Un Scrum Master observa que su equipo cumple perfectamente el Foco (siempre trabajan en el Sprint Backlog) y el Compromiso (siempre logran el Sprint Goal), pero en las Retrospectivas nadie menciona jamás un problema, una preocupación o un desacuerdo — todo se describe como "perfecto". Aplicando los 5 valores de Scrum, ¿qué interpretación es más precisa? a El equipo es un ejemplo perfecto de los 5 valores de Scrum funcionando en conjunto b Los valores de Scrum no se aplican a la dinámica de las Retrospectivas, solo a los eventos de ejecución del Sprint c Esto demuestra un Compromiso excepcionalmente alto que compensa la ausencia de los otros valores d Es probable que falten Apertura y Coraje: un equipo sin nunca un desacuerdo o preocupación visible probablemente está ocultando información o evitando temas incómodos, lo cual mina la base de confianza que los pilares empíricos requieren para funcionar 13 En el Sprint Planning, un Developer junior expresa dudas sobre si el equipo podrá completar el alcance propuesto, pero el resto del equipo, con más experiencia, insiste en que "siempre se puede" y avanza sin discutir más el punto. El Developer junior no insiste y el equipo termina fallando el Sprint Goal. En la Retrospectiva, ¿qué valores de Scrum deberían haberse aplicado mejor, y por parte de quién? a El problema fue exclusivamente del Scrum Master, por no asignar las tareas correctamente entre el equipo b Solo el Developer junior tuvo una falla de valores; el resto del equipo actuó correctamente al mantener la confianza en sus capacidades c Ningún valor de Scrum es relevante aquí, ya que se trata de una diferencia de experiencia técnica, no de valores d El equipo experimentado necesitaba más Respeto hacia la perspectiva del Developer junior como persona capaz, y el junior necesitaba más Coraje para insistir en su preocupación pese a la presión del grupo 14 Una organización mide el desempeño individual de los Developers comparando cuántos puntos de historia completa cada uno por Sprint, y usa este ranking para decisiones de bonificación. Un Scrum Master nota que, desde que se implementó esta métrica, los Developers han dejado de ayudarse entre sí y compiten por tomar las historias "más fáciles". ¿Qué valores de Scrum está erosionando directamente esta práctica organizacional? a Ninguno, ya que la medición de desempeño individual es independiente de los valores de Scrum b Únicamente Foco, porque distrae al equipo del Sprint Goal c Compromiso (con el equipo y sus objetivos compartidos, no solo metas individuales) y Respeto (verse mutuamente como compañeros capaces con quienes colaborar, no como competidores) d Apertura únicamente, porque genera secretismo sobre el desempeño individual 15 El Product Owner de un equipo cambia constantemente de opinión sobre las prioridades del Product Backlog sin explicar el razonamiento detrás de los cambios, y se molesta visiblemente cuando los Developers preguntan el porqué. Los Developers han aprendido a "no preguntar" y simplemente ejecutan lo que se les indica. ¿Qué valor de Scrum está ausente en esta dinámica, y de qué lado? a Falta únicamente Compromiso por parte del PO, ya que cambia de opinión con frecuencia b Falta Apertura por parte del PO (no comparte el razonamiento de sus decisiones) y probablemente Coraje por parte de los Developers (han dejado de cuestionar pese a tener dudas legítimas) c No falta ningún valor, ya que el PO tiene la autoridad exclusiva de decidir el orden del Product Backlog sin justificación d Falta Respeto exclusivamente por parte de los Developers, por no obedecer sin cuestionar al PO 16 Una organización con 14 Developers en un solo equipo Scrum decide que, para mantener "un solo equipo cohesionado centrado en el Product Goal", no van a dividirse en equipos más pequeños, sino que simplemente nombrarán 2 Scrum Masters para gestionar la coordinación. El Daily dura 35 minutos y varios Developers reportan que casi nunca hablan directamente con la mitad de sus compañeros. ¿Qué recomienda la Guía Scrum 2020 en este caso, y por qué falla la solución de la organización? a La Guía Scrum recomienda equipos de 10 o menos integrantes para facilitar la comunicación. Con 14 Developers, conviene dividir en equipos Scrum que compartan Product Goal, Product Backlog y Product Owner; agregar más Scrum Masters no soluciona el problema. b La solución es correcta: agregar más Scrum Masters es la forma recomendada de escalar un equipo grande sin dividirlo c El problema no tiene relación con el tamaño del equipo, sino con la duración del Daily, que debería reducirse a 15 minutos sin importar el tamaño d Un Scrum Team puede tener cualquier número de Developers sin límite, siempre que tenga suficientes Scrum Masters proporcionalmente 17 Un Product Owner está de vacaciones por dos semanas durante un Sprint activo. Antes de salir, le pide a un Developer senior del equipo que "tome decisiones de prioridad del Product Backlog en mi nombre" sin coordinarlo con nadie más, y que informe los cambios al volver. El Developer así lo hace. Al regresar el PO, ¿qué aspecto de la teoría de Scrum fue potencialmente vulnerado, y cuál no? a El Product Owner puede delegar tareas del Product Backlog, pero mantiene la responsabilidad de las decisiones. La delegación no rompe la regla de una sola persona; el riesgo fue la falta de transparencia durante la ausencia del PO. b Fue completamente inválido, ya que el Product Owner es una persona y nunca puede delegar ninguna parte de su trabajo c No hubo ningún problema en absoluto, ya que cualquier Developer puede asumir el rol de PO temporalmente sin restricciones d El único problema fue que el Developer no era un Scrum Master, que es el único rol autorizado para tomar decisiones del Product Backlog en ausencia del PO 18 Un Scrum Master, frustrado porque el equipo no avanza al ritmo esperado, comienza a asignar personalmente las tareas del Sprint Backlog cada mañana después del Daily, diciendo "así nos asegura que cada uno sabe exactamente qué hacer y avanzamos más rápido". El equipo, inicialmente, sí mejora su velocidad de entrega durante 2 sprints, pero luego comienza a depender completamente del SM para saber qué hacer, y deja de proponer ideas propias. ¿Cómo se explica esta paradoja según la teoría de Scrum? a No hay paradoja: el Scrum Master actuó correctamente al optimizar el flujo de trabajo del equipo de forma directa b La mejora inicial de velocidad ocultó el daño estructural: asignar tareas es un antipatrón porque viola la autogestión, y aunque genere ganancias de corto plazo, erosiona la capacidad del equipo de pensar y decidir por sí mismo, generando dependencia en lugar de madurez como equipo autogestionado c La paradoja se explica porque el equipo simplemente no tenía suficiente experiencia técnica desde el inicio d Esto demuestra que la autogestión es un concepto teórico que no funciona en la práctica real 19 Una empresa de consultoría tiene un equipo Scrum compuesto por 5 personas: un Scrum Master, un Product Owner, y 3 personas etiquetadas formalmente como "Backend Developer", "Frontend Developer" y "QA Tester". Cuando surge una tarea de pruebas durante un Sprint con alta carga de trabajo de desarrollo, el equipo decide que solo el "QA Tester" puede ejecutarla, ya que "no es su función" que los otros prueben. La tarea no se completa a tiempo. ¿Qué principio de Scrum Team está siendo violado? a Ninguno; cada Developer debe limitarse estrictamente a su especialidad técnica formal, según la Guía Scrum b El principio violado es la autogestión, ya que el QA Tester debió negarse a hacer la tarea c El principio de multifuncionalidad: los Developers como conjunto deben tener todas las habilidades necesarias para crear valor, compartiendo o adquiriendo habilidades según se necesite — limitarse rígidamente a etiquetas de especialidad contradice esto y generó el incumplimiento del Sprint d No es un problema de Scrum, es simplemente una limitación de recursos humanos de la organización 20 En una organización, un Scrum Master reporta jerárquicamente al gerente de los Developers de su equipo, y ese mismo gerente realiza las evaluaciones de desempeño anuales de todos, incluyendo del propio Scrum Master. El SM ha notado que evita señalar impedimentos relacionados con decisiones de ese gerente, "para no generar tensión". ¿Qué tensión estructural revela este escenario respecto al rol del Scrum Master? a No hay tensión alguna, ya que la estructura jerárquica de reporte no tiene relación con la efectividad del rol de Scrum Master b Esta es una práctica recomendada, ya que asegura alineación entre el Scrum Master y la gerencia c La solución correcta sería que el Scrum Master renuncie inmediatamente a su rol en esa organización d Existe una tensión entre el liderazgo servicial del Scrum Master y su dependencia jerárquica. Al evitar señalar impedimentos por temor a afectar su relación con la gerencia, deja de cumplir su función de facilitar la eliminación de obstáculos. 21 Un equipo realiza su Daily Scrum de la siguiente manera: cada Developer, en orden alfabético, le informa al Scrum Master qué hizo ayer, qué hará hoy y qué impedimentos tiene; el SM toma notas en una hoja de cálculo; el evento dura 22 minutos porque "hay mucho que reportar". Identifica TODOS los elementos de este escenario que contradicen la teoría del Daily Scrum según la Guía Scrum 2020. a Solo la duración de 22 minutos es un problema, ya que excede el timebox de 15 minutos b El único problema es que las preguntas de ayer/hoy/impedimentos ya no son obligatorias desde la versión 2020 de la Guía Scrum, por lo que no deberían usarse en absoluto c No hay ningún problema, ya que cada equipo puede definir libremente su propio formato de Daily Scrum sin restricciones de la Guía Scrum d Hay tres problemas: el Daily se convirtió en un reporte al Scrum Master en lugar de una inspección entre Developers; supera los 15 minutos y no evidencia un plan accionable para avanzar hacia el Sprint Goal. 22 Durante el Sprint Planning de un Sprint de 2 semanas, el equipo dedica 6 horas completas discutiendo el "por qué" (Sprint Goal) y el "qué" (selección del backlog), pero termina la sesión sin haber discutido el "cómo" se realizará el trabajo, asumiendo que "eso se resuelve en la marcha durante los Dailies". ¿Es esta una práctica válida según la Guía Scrum 2020? a No, es inválida en cualquier circunstancia, ya que los tres temas del Sprint Planning son obligatorios y deben completarse siempre en la misma sesión b Sí, es completamente válida, ya que el cómo nunca forma parte del Sprint Backlog, solo el qué y el por qué c Depende del contexto: Scrum no impone un formato rígido, pero omitir el “cómo” deja incompleto el Sprint Backlog, ya que incluye el objetivo, los elementos seleccionados y el plan para entregarlos. d Sí, es válida, porque el Daily Scrum reemplaza por completo la necesidad de planificar el cómo durante el Sprint Planning 23 Un Product Owner, presionado por un stakeholder importante, decide cancelar un Sprint a mitad de camino porque el stakeholder "ya no quiere ese producto, quiere otro completamente distinto", sin haber consultado al equipo sobre alternativas de ajuste de alcance dentro del Sprint actual. El Scrum Master cuestiona la decisión. ¿Quién tiene la autoridad correcta según la Guía Scrum, y qué matiz adicional debería considerarse? a Solo el Scrum Master tiene la autoridad de cancelar un Sprint, por lo que la decisión del PO es inválida por completo b El Product Owner es quien puede cancelar el Sprint si el Sprint Goal queda obsoleto. Sin embargo, por el impacto de la decisión, debe evaluarse si antes era posible ajustar el alcance dentro del Sprint. c Ningún rol individual tiene autoridad para cancelar un Sprint; debe ser una decisión consensuada por todo el Scrum Team y los stakeholders d El equipo de Developers tiene la autoridad de cancelar el Sprint, ya que son quienes ejecutan el trabajo 24 Un equipo realiza la Sprint Review con 12 stakeholders. El Product Owner solo muestra diapositivas con capturas del Incremento, sin demostración del producto funcionando ni espacio para discutir próximos pasos. Al finalizar, indica que la revisión está completada. Según la Guía Scrum, ¿qué elementos esenciales de la Sprint Review fueron omitidos? a La Review se volvió una presentación, no una sesión colaborativa. Faltó inspeccionar el Incremento funcionando, discutir próximos pasos y ajustar el Product Backlog según lo aprendido. b Ninguno; presentar capturas de pantalla es una forma válida y suficiente de cumplir el propósito de la Sprint Review c El único problema fue no incluir suficientes stakeholders; 12 es insuficiente para una Review válida d El evento fue válido porque cumplió su único requisito: informar a los stakeholders sobre el avance del Sprint 25 Un equipo lleva 5 Sprints consecutivos identificando en cada Retrospectiva el mismo problema: "la comunicación con el equipo de infraestructura es lenta y bloquea nuestro trabajo". Cada vez generan una acción de mejora, pero ninguna se implementa realmente porque "siempre hay algo más urgente en el Sprint siguiente". ¿Qué fallo estructural revela esta situación respecto al propósito de la Sprint Retrospective? a La Retrospectiva se volvió un ritual sin impacto: repetir el mismo problema sin implementar mejoras contradice su propósito de aumentar la calidad y efectividad, abordando acciones prioritarias lo antes posible. b Ninguno; es normal y esperado que algunos problemas persistan por varios sprints sin resolverse mientras se prioriza el trabajo del Sprint c El problema es exclusivamente del equipo de infraestructura, no del equipo Scrum que ejecuta la Retrospectiva d La solución correcta es eliminar la Retrospectiva, ya que claramente no está funcionando para este equipo 26 Un equipo completa el desarrollo de una funcionalidad durante el Sprint, y aunque no se ha realizado ninguna prueba de seguridad (la cual forma parte de su Definition of Done acordada), el Product Owner decide presentarla en la Sprint Review como "un avance preliminar" para obtener feedback de los stakeholders, aclarando que "no está totalmente terminada pero quiere mostrar dirección". ¿Es esta práctica coherente con la Guía Scrum 2020? a Sí, es válida, porque mostrar avances preliminares en la Sprint Review siempre es una buena práctica de transparencia b No es coherente: si un elemento no cumple la Definition of Done, no puede considerarse parte del Incremento ni siquiera presentarse en la Sprint Review — debe volver al Product Backlog para consideración futura, independientemente de la intención de obtener feedback temprano c Es válida solo si los stakeholders están de acuerdo explícitamente en ver trabajo incompleto d Es válida porque la Definition of Done solo aplica al final del proyecto completo, no a cada Sprint individual 27 Un Product Owner mantiene un Product Backlog con 230 elementos, de los cuales solo los primeros 8 están refinados con suficiente detalle para ser seleccionados en el próximo Sprint Planning; los restantes 222 son ideas generales sin estimar ni detallar. Un stakeholder se queja de que el backlog "está desorganizado e incompleto". ¿Cómo se evalúa esta situación según la teoría de los artefactos de Scrum? a El stakeholder tiene razón: un Product Backlog bien gestionado debe tener todos sus elementos completamente detallados y estimados en todo momento b Es un error grave, ya que el Product Backlog nunca debería tener más de 20 elementos en total c Esto es coherente con la naturaleza del Product Backlog como lista emergente: solo los elementos que serán seleccionados próximamente requieren suficiente refinamiento para considerarse "listos"; el refinamiento es una actividad continua, no un estado final requerido para todo el backlog de una vez d El problema real es que el PO debería haber delegado completamente la gestión del backlog a los Developers 28 Una historia de usuario dice: "Como administrador, quiero un botón en el sistema, para que el sistema funcione mejor." El equipo logra estimarla (le asignan 3 puntos de historia) y la incluyen en el Sprint. A mitad del Sprint, surge una discusión profunda sobre qué debía hacer exactamente el botón, ya que nadie recuerda los detalles acordados. Evaluando esta historia contra los criterios INVEST y las 3 C's, ¿cuál es el diagnóstico más completo? a La historia es válida porque logró ser estimada, lo cual cumple el criterio Estimable de INVEST y es suficiente b No hay ningún problema con la historia; la confusión se debe únicamente a una falla de memoria del equipo, no a la calidad de la historia en sí c El único problema es que la historia debió escribirse con más palabras técnicas específicas d Aunque fue estimada, la historia puede fallar en Valuable y Testable: no define un valor claro ni criterios de aceptación. La falta de conversación y acuerdos previos explica la confusión durante el Sprint. 29 Un equipo decide que, para "ahorrar tiempo", el Sprint Goal y el Product Goal serán literalmente el mismo enunciado en cada Sprint: "Mejorar el producto." Cuando un nuevo Developer se incorpora y pregunta cuál es la diferencia entre ambos en su equipo, nadie sabe responder con claridad. ¿Qué problema conceptual revela esta práctica? a Ninguno; usar el mismo enunciado para ambos compromisos es una simplificación válida y recomendada para ahorrar tiempo de planeación b Es una práctica correcta siempre que el equipo esté de acuerdo internamente, sin importar la claridad para nuevos miembros c El único problema es de comunicación con el nuevo Developer, no de la práctica en sí misma d Confunde compromisos con distintos horizontes: el Product Goal guía el producto a largo plazo, mientras el Sprint Goal define el propósito de un Sprint específico. Usar el mismo enunciado elimina el foco que cada uno debe aportar. 30 Durante un Sprint, los Developers descubren que, para completar un elemento del Product Backlog seleccionado, necesitan realizar un trabajo técnico adicional no anticipado (una refactorización) que no estaba en el plan original del Sprint Backlog. Deciden incluirla sin consultar al Product Owner, ya que consideran que es "una decisión puramente técnica de cómo hacer el trabajo". ¿Es esto coherente con la teoría de los artefactos de Scrum? a No, es inválido: cualquier cambio al Sprint Backlog requiere aprobación explícita del Product Owner antes de implementarse b Es inválido porque cualquier trabajo no planeado en el Sprint Planning original debe esperar al siguiente Sprint, sin excepciones c Es coherente: el Sprint Backlog pertenece a los Developers y puede actualizarse durante el Sprint. Los ajustes técnicos sobre cómo cumplir la Definition of Done son responsabilidad del equipo, sin requerir aprobación externa. d Es válido únicamente si el Scrum Master autoriza el cambio antes de que los Developers procedan 31 Una organización con 6 equipos Scrum trabajando sobre el mismo producto decide implementar Nexus. Sin embargo, mantienen Product Backlogs separados para cada equipo, cada uno con su propio Product Owner, y solo se reúnen una vez al mes para "compartir avances". Evaluando esta implementación contra los principios de escalado de Scrum, ¿qué inconsistencia central se observa? a Ninguna; Nexus permite explícitamente que cada equipo mantenga su propio Product Backlog y Product Owner de forma independiente b Contradice el escalado de Scrum: equipos que trabajan en un mismo producto deben compartir Product Goal, Product Backlog y Product Owner. Separarlos genera silos que Nexus busca evitar. c El único problema es la frecuencia de reunión, que debería ser semanal en lugar de mensual d Es una implementación correcta porque cada equipo conserva su autonomía total de decisión 32 Un equipo usa un tablero Kanban para visualizar su Sprint Backlog, con columnas "Por hacer", "En progreso" y "Hecho", y un límite de WIP (trabajo en progreso) de 3 tareas simultáneas. Un consultor externo les dice: "Ya no están haciendo Scrum, están haciendo Kanban." ¿Es correcta esta afirmación? a No es correcta: Kanban puede complementar Scrum. Un tablero visual y límites de WIP no eliminan los eventos, artefactos ni roles de Scrum; solo ayudan a gestionar el flujo de trabajo. b Sí, es correcta: usar cualquier elemento visual de Kanban automáticamente convierte la práctica del equipo en Kanban puro, excluyendo Scrum c Es parcialmente correcta solo si el equipo elimina el Daily Scrum, ya que Kanban lo reemplaza completamente d Es correcta únicamente si el equipo también elimina el Sprint como evento contenedor 33 En una sesión de Scrum de Scrums entre 4 equipos, el representante de cada equipo es designado permanentemente por el gerente de programa como "el Tech Lead de cada equipo", sin posibilidad de rotación, y se les indica que deben "reportar el estado" en lugar de "coordinar impedimentos". ¿Qué elementos de esta implementación contradicen las prácticas recomendadas del Scrum de Scrums? a Dos elementos: la designación permanente y jerárquica del representante (en lugar de poder rotar entre cualquier miembro del equipo) y el cambio de propósito hacia "reportar estado" en lugar de coordinar dependencias e impedimentos entre equipos, lo cual desvirtúalanaturaleza colaborativa del evento b Ninguno; el Tech Lead es siempre el representante correcto y obligatorio para el Scrum de Scrums en cualquier organización c El único problema es la frecuencia con la que se reúnen los representantes d Es una implementación perfectamente alineada con las mejores prácticas de escalado de Scrum 34 Un equipo descubre que su Daily Scrum, con timebox de 15 minutos, frecuentemente termina en 6 u 8 minutos porque "no hay mucho que discutir". El Scrum Master, preocupado de que esto "no parece suficientemente riguroso", instruye al equipo a extender la conversación llenando el tiempo restante con discusiones técnicas detalladas que normalmente se resolverían fuera del evento. ¿Es correcta esta instrucción según el concepto de timeboxing? a Sí, es correcta: todo timebox debe usarse en su totalidad, ya que de lo contrario el evento no se está aprovechando adecuadamente b No es correcta: el timebox es un límite máximo, no un tiempo obligatorio. Si el Daily cumple su propósito en menos tiempo, es válido; forzar discusiones adicionales reduce la eficiencia. c Es correcta solo si el equipo está de acuerdo voluntariamente en extender la conversación d Es incorrecta únicamente porque las discusiones técnicas detalladas deberían ocurrir en el Sprint Planning, no en ningún otro momento 35 Una organización que evalúa frameworks de escalado describe sus necesidades así: tienen 4 equipos trabajando en el mismo producto, valoran fuertemente mantenerse lo más cerca posible de la Scrum Guide original con mínimas adiciones, y quieren evitar la complejidad de múltiples niveles de planificación que requieren otros frameworks más extensos. Basándote en las características distintivas de los frameworks de escalado estudiados, ¿cuál encaja mejor con esta descripción y por qué? a SAFe, porque es el framework más completo y ofrece más niveles de planificación que garantizan cobertura total b LeSS, porque es el único framework que permite tener más de un Product Owner por producto c Nexus, porque está diseñado explícitamente como la extensión más cercana a la Scrum Guide, añadiendo elementos mínimos como el Nexus Integration Team y un Sprint Backlog compartido, sin introducir múltiples niveles adicionales de planificación organizacional d Scrum de Scrums, porque es un framework completo de escalado equivalente a Nexus o LeSS en alcance y estructura 36 Un Scrum Master observa que dos Developers mantienen un desacuerdo técnico sobre arquitectura que afecta decisiones desde hace 3 Sprints. En lugar de decidir por ellos, facilita una sesión con preguntas para que analicen opciones y lleguen a un acuerdo. ¿Qué roles del Scrum Master aplica y por qué es mejor que decidir directamente? a Únicamente el rol de gestor de impedimentos, ya que cualquier desacuerdo del equipo se clasifica automáticamente como impedimento que el SM debe resolver directamente b Ninguno de los roles del SM aplica a desacuerdos técnicos, que deben resolverse exclusivamente entre los Developers sin ninguna intervención c El rol de líder servicial únicamente, que se limita a escuchar sin ninguna intervención activa d Aplica como coach y facilitador: guía la conversación sin imponer la solución, ayudando al equipo a desarrollar su capacidad de resolver conflictos y evitar dependencia del Scrum Master. 37 Durante 4 Sprints consecutivos, un equipo no logra completar el Sprint Backlog seleccionado. El Scrum Master, analizando la causa raíz, descubre que el verdadero impedimento es que el departamento de seguridad de la información tarda en promedio 8 días hábiles en aprobar cualquier cambio de configuración, un cuello de botella externo al equipo y a la organización inmediata del SM. ¿Cuál es la acción más alineada con el rol de "agente de cambio" del Scrum Master en este caso? a Aceptar que este impedimento está fuera de su alcance y enfocarse únicamente en ayudar al equipo a planificar Sprints más pequeños alrededor del cuello de botella, sin intentar resolverlo b Ignorar el impedimento ya que la función del SM se limita estrictamente al equipo, sin ninguna responsabilidad hacia la organización en general c Pedir al Product Owner que elimine de la lista de prioridades cualquier elemento que requiera aprobación de seguridad, evitando el problema en lugar de resolverlo d Actuar como agente de cambio, ayudando a la organización a comprender el impacto del impedimento y promoviendo mejoras con seguridad para lograr un proceso más ágil y empírico. 38 Un Scrum Master nuevo en su rol observa que, en su ausencia por una emergencia médica de una semana, el equipo realizó su Daily Scrum, avanzó en el Sprint Backlog sin contratiempos, y resolvió un impedimento menor por sí mismo coordinando directamente con otro equipo. Al regresar, el SM se siente "innecesario" y preocupado por su valor en el equipo. ¿Cómo debería interpretar esta situación a la luz de la teoría del liderazgo servicial? a Su preocupación está justificada: si el equipo funciona bien sin él, significa que su rol no aporta valor real y debería considerar que la organización elimine la posición b Esto demuestra que el equipo nunca necesitó un Scrum Master desde el principio c Es una señal de éxito: el liderazgo servicial busca desarrollar la autogestión del equipo. Que pueda avanzar y resolver impedimentos sin depender del Scrum Master demuestra madurez, no falta de valor del rol. d El SM debería sentirse preocupado porque esto significa que el equipo violó la regla de que solo el Scrum Master puede facilitar el Daily Scrum 39 Un Product Owner le pide al Scrum Master que "presione" a los Developers para que acepten más elementos del Product Backlog en el próximo Sprint de los que ellos mismos consideran viables, argumentando que "hay una fecha límite del negocio que debe cumplirse". ¿Cuál es la respuesta más alineada con la teoría de Scrum por parte del SM? a Aceptar la solicitud y presionar al equipo, ya que el Scrum Master debe priorizar las necesidades del negocio comunicadas por el Product Owner por encima de la autogestión del equipo b Explicar al PO que los Developers deciden cuánto trabajo es viable en el Sprint Planning según su capacidad y Definition of Done. El SM debe facilitar una conversación sobre opciones reales, sin imponer presión que afecte la autogestión. c Negarse a cualquier conversación sobre el tema, ya que las fechas límite del negocio no son responsabilidad del Scrum Master en ningún sentido d Delegar la decisión completamente al Product Owner, ya que tiene autoridad total sobre cuánto trabajo debe realizar el equipo en cada Sprint 40 Una organización está adoptando Scrum por primera vez. El Scrum Master de uno de los equipos pasa la mayor parte de su tiempo dentro de su propio equipo, pero rara vez interactúa con otros Scrum Masters de la organización o con la gerencia general sobre cómo está progresando la adopción de Scrum a nivel organizacional. ¿Qué dimensión del servicio del Scrum Master, según la Guía Scrum 2020, está siendo menos atendida, y qué riesgo genera esto? a e descuida el servicio a la organización: el Scrum Master también debe apoyar la adopción de Scrum, compartir aprendizajes y ayudar a remover impedimentos organizacionales. Sin esto, los problemas sistémicos pueden permanecer sin resolver. b Ninguna dimensión está desatendida; el Scrum Master debe enfocarse exclusivamente en su propio equipo sin ninguna responsabilidad hacia la organización más amplia c Se está desatendiendo únicamente el servicio al Product Owner, ya que es la única relación formalmente obligatoria del SM d El problema no tiene relación con ninguna de las tres dimensiones de servicio del SM descritas en la Guía Scrum Explicación 1 El valor de software funcionando sobre documentación NO elimina el registro de decisiones — especialmente arquitectónicas—, solo prioriza la entrega funcional. Eliminar TODA documentación generó exactamente el desperdicio que el pensamiento Lean busca evitar. 2 Como con los otros 3 valores del Manifiesto, este no elimina su contraparte (los contratos), sino que establece una prioridad relativa cuando hay tensión entre ambos. 3 Los 12 principios no son independientes entre sí. Entregar software con frecuencia sin atención a la excelencia técnica ni desarrollo sostenible produce exactamente este patrón: deuda técnica, defectos y agotamiento. 4 Ningún documento reemplaza al otro. El Manifiesto se enfoca en valores de desarrollo de software; la DOI complementa con valores de gestión de proyectos ágiles a un nivel más amplio. 5 El pensamiento Lean distingue entre desperdicio real y elementos que sostienen la capacidad de respuesta y resiliencia del sistema, como capacitación cruzada e inventario de seguridad para piezas críticas. 6 El marco es deliberadamente incompleto y se basa en la inteligencia colectiva, no en instrucciones detalladas — pero el problema no es tener apoyos, es que sustituyan la adaptación y el pensamiento del equipo. 7 El equipo no tiene transparencia real, ni inspección genuina, ni adaptación —los tres pilares empíricos están rotos simultáneamente. No es que Scrum no funcione, es que lo que ejecutan no es Scrum. 8 El Product Goal, el Sprint Goal y el Sprint Backlog SON planes — lo que el empirismo exige es que estos planes se actualicen constantemente con base en lo aprendido, no que se elimine la planeación. 9 El Equipo A inspecciona pero no actúa sobre lo que descubre: le falta adaptación. El Equipo B ajusta sin transparencia hacia afuera, lo cual vicia su propia inspección. 10 Lo que Scrum deja abierto es CÓMO se hace el trabajo; los eventos, artefactos y roles SON las partes mínimas que el marco sí define explícitamente. Eliminarlos es dejar de practicar Scrum. 11 La Apertura implica ser transparente sobre el trabajo y los desafíos —incluyendo errores propios—, y el Coraje es la valentía de hacer lo correcto incluso cuando es incómodo personalmente. 12 Un equipo real tendrá fricciones y desacuerdos genuinos. Su ausencia total en la Retrospectiva sugiere falta de Apertura y de Coraje, lo que erosiona la confianza que sostiene a los pilares empíricos. 13 El Respeto implica ver a cada miembro del equipo —incluyendo a los más junior— como personas capaces cuya perspectiva merece consideración real. El Coraje del junior para sostener su punto también falló. 14 Una métrica de ranking individual incentiva comportamientos opuestos al Compromiso compartido del equipo y al Respeto (verse como compañeros capaces, no rivales). 15 Comunicar el razonamiento de las decisiones es parte de mantener la transparencia y la confianza del equipo (Apertura). Del lado de los Developers, dejar de preguntar refleja pérdida de Coraje. 16 La Guía Scrum recomienda 10 o menos por capacidad de comunicación; con 14, debería considerarse reorganización en varios equipos compartiendo Product Goal, Backlog y PO — no añadir capas de gestión. 17 El PO puede delegar el trabajo del backlog manteniéndose responsable; eso no rompe la regla de "una sola persona". El riesgo real es la falta de transparencia durante el proceso, no la delegación en sí. 18 Asignar tareas centralizadamente genera una ganancia aparente de eficiencia inicial, pero sustituye el desarrollo de la capacidad de autogestión del equipo, generando dependencia en lugar de madurez. 19 Los equipos son multifuncionales: sus miembros en conjunto tienen las habilidades necesarias para crear valor, compartiéndolas o adquiriéndolas según sea necesario. 20 El liderazgo servicial requiere poder señalar y remover impedimentos, incluyendo los que provienen de decisiones gerenciales. La estructura de evaluación crea un incentivo real para evitar esa función. 21 Las 3 preguntas ya no son obligatorias, no deberían usarse en absoluto — Aplica correctamente un dato real (las preguntas dejaron de ser prescriptivas en 2020) pero saca una conclusión incorrecta: no usarlas no es obligatorio per se, el verdadero problema del escenario es la dirección del reporte y la falta de plan accionable, no el uso de las preguntas en sí. 22 El Sprint Backlog se compone del Sprint Goal, los elementos seleccionados y el plan para entregarlos (cómo). Omitir completamente el "cómo" deja el artefacto incompleto desde el inicio. 23 El PO es la única persona con autoridad para cancelar el Sprint, y la causa válida (Sprint Goal obsoleto) parece cumplirse; pero vale la pena cuestionar si se exploraron alternativas de ajuste antes de cancelar. 24 La Sprint Review es una sesión de trabajo, no una presentación unidireccional. Este escenario reproduce el antipatrón: sin colaboración sobre qué hacer después ni ajuste del Product Backlog basado en lo aprendido. 25 Las mejoras más impactantes identificadas en la Retrospectiva deben abordarse lo antes posible, incluso incorporándose al Sprint Backlog del siguiente Sprint. Repetir el mismo problema 5 veces sin acción real vacía el evento de su propósito. 26 Trabajo que no cumple la Definition of Done no puede presentarse en la Sprint Review, sin excepciones basadas en la intención. Debe volver al Product Backlog. 27 El Product Backlog es una lista emergente — nunca está "completa" ni todos sus elementos necesitan el mismo nivel de detalle simultáneamente. El refinamiento es continuo, no un estado final. 28 La ausencia de valor claro (Valuable) y de criterios de aceptación (Testable, vinculado a Confirmation) explica tanto la estimación poco confiable como la confusión posterior — son síntomas del mismo problema raíz. 29 El Product Goal da dirección de largo plazo; el Sprint Goal da foco específico a un Sprint particular. Un enunciado genérico usado para ambos elimina la capacidad de foco que cada uno debe aportar. 30 El Sprint Backlog es un plan por y para los Developers, que se actualiza a lo largo del Sprint. Las decisiones sobre el "cómo" lograr la Definition of Done son responsabilidad de los Developers, sin aprobación externa. 31 Cuando varios equipos trabajan sobre el mismo producto, deben compartir el mismo Product Goal, Product Backlog y Product Owner. Backlogs y POs separados recrean los silos que el escalado busca evitar. 32 Kanban es complementario, una técnica de visualización de flujo que puede usarse dentro del marco de Scrum sin sustituirlo. El equipo conserva Sprint, eventos, artefactos y roles. 33 El Scrum de Scrums no requiere un rol fijo como representante; puede rotar entre cualquier miembro. Su propósito es coordinar dependencias e impedimentos, no convertirse en una cadena de reporte jerárquico. 34 El timebox es un techo máximo, no una meta a llenar. Un Daily Scrum eficiente que cumple su propósito en menos tiempo del máximo permitido es exactamente lo que se espera. 35 Nexus se describe como el framework de escalado más cercano a la Scrum Guide original, con adiciones mínimas — coincide con los criterios de cercanía a la guía y mínima complejidad adicional de la organización. 36 El SM actúa como coach y facilitador: no impone la decisión, sino que guía el proceso para que el equipo construya su propia respuesta, coherente con el objetivo de volverse innecesario para este tipo de situaciones. 37 El SM sirve a la organización ayudando a comprender y promulgar un enfoque empírico para el trabajo complejo, y eliminando barreras entre partes interesadas y equipos — exactamente lo que este escenario sistémico exige. 38 El liderazgo servicial busca ayudar al equipo a desarrollar autogestión real. Un equipo capaz de sostener sus eventos sin el SM demuestra que el trabajo de habilitación está funcionando, no que sea redundante. 39 La selección de cuánto trabajo es viable en un Sprint es decisión de los Developers. La respuesta correcta del SM es facilitar una conversación honesta sobre las opciones reales, protegiendo la autogestión del equipo. 40 La Guía Scrum describe tres dimensiones de servicio del SM: al equipo, al Product Owner y a la organización. Enfocarse exclusivamente en el equipo propio deja huérfana la tercera dimensión.

1

Un gerente de TI adopta agilidad eliminando toda la documentación, actas y Jira, afirmando que solo importa programar y entregar. Tres meses después, el equipo repite errores y los nuevos integrantes desconocen decisiones de arquitectura. Según el Manifiesto Ágil, ¿cuál es el análisis más preciso?

a

El gerente malinterpretó el valor "software funcionando sobre documentación exhaustiva": el valor prioriza, no elimina; la falta de registro de decisiones es justamente el desperdicio que el equipo ahora paga con errores repetidos

b

El gerente interpretó correctamente el manifiesto: la agilidad significa eliminar toda documentación y herramientas formales

c

El problema no tiene relación con el Manifiesto Ágil, sino con la rotación de personal del equipo

d

El equipo debió usar Scrum en lugar de prácticas ágiles genéricas para evitar este problema

2

Una organización financiera adopta agilidad, pero mantiene contratos de alcance fijo por requisitos legales. El equipo afirma que esto contradice el Manifiesto Ágil. El líder de PMO responde que los contratos no se eliminan; cuando existe conflicto, debe priorizarse la colaboración con el cliente sobre seguir estrictamente el contrato. ¿Es correcta esta interpretación?

a

No, porque el Manifiesto Ágil prohíbe expresamente cualquier tipo de contrato de alcance fijo

b

Sí, es correcta: el valor no elimina los contratos, establece que cuando haya tensión entre cumplir la letra del contrato y atender lo que genera valor real al cliente, la colaboración guía la decisión

c

No, porque sin importar el contexto, los contratos legales siempre deben tener prioridad sobre cualquier valor ágil

d

Es parcialmente correcta, pero solo aplica a proyectos de software, no a proyectos financieros

3

Un equipo entrega software cada 2 semanas durante 8 meses, pero cada entrega genera defectos críticos, aumenta la deuda técnica y provoca agotamiento por trabajo en fines de semana. Según los 12 principios del Manifiesto Ágil, el Scrum Master concluye que se priorizó un principio mientras se descuidaron gravemente otros dos. ¿Cuáles?

a

El principio de simplicidad y el de individuos motivados, que no tienen relación con calidad técnica

b

El principio de conversación cara a cara y el de arquitecturas emergentes de equipos auto-organizados

c

La atención continua a la excelencia técnica y el desarrollo sostenible a ritmo constante — ambos sacrificados por cumplir la cadencia de entregas a cualquier costo

d

Ninguno; cumplir las entregas frecuentes es suficiente para considerarse un equipo ágil exitoso

4

Durante una sesión de planeación estratégica, el director de un área de innovación presenta la Declaración de Interdependencia (DOI) como "la versión actualizada y oficial del Manifiesto Ágil que lo reemplaza", y propone descontinuar el uso del Manifiesto en la organización. Un Scrum Master experimentado interviene. ¿Cuál es la corrección más precisa que debería hacer?

a

Confirmar que el director tiene razón, ya que la DOI es cronológicamente posterior y por tanto sustituye al Manifiesto

b

Indicar que ninguno de los dos documentos es relevante una vez que la organización ya implementó Scrum como framework

c

Aclarar que la DOI y el Manifiesto son exactamente el mismo documento con nombres distintos según la región geográfica

d

Aclarar que la DOI no reemplaza ni actualiza al Manifiesto: son documentos complementarios de distinto nivel — el Manifiesto define valores de desarrollo de software, mientras que la DOI aporta 6 valores de gestión de proyectos ágiles en general

5

Un equipo de manufactura elimina la capacitación cruzada y reduce a cero el inventario de repuestos críticos porque considera que no agregan valor al cliente. Tras una falla, la producción se detiene 4 días y nadie puede operar la máquina de respaldo. Según Lean, ¿qué error conceptual cometió el equipo?

a

Ninguno; eliminar inventario y capacitación cruzada es exactamente lo que dicta el pensamiento Lean sin excepciones

b

El problema fue exclusivamente de mantenimiento de máquinas y no tiene relación con los principios Lean

c

El error fue no haber implementado Scrum en lugar de Lean para la manufactura

d

Confundieron "desperdicio" con cualquier costo o inversión visible, sin distinguir entre desperdicio real (lo que no aporta valor) e inversión necesaria para sostener flujo y capacidad de respuesta — el pensamiento Lean también exige respetar al equipo y sostener el flujo, no solo cortar costos

6

Un Scrum Master nuevo en la organización encuentra que el equipo anterior documentó un "Manual de Procesos Scrum" de 40 páginas que detalla exactamente qué debe decir cada Developer en el Daily, qué plantilla usar para cada historia de usuario, y un checklist obligatorio de 25 puntos antes de cualquier despliegue. El equipo afirma: "Esto nos ha dado consistencia y todos sabemos qué esperar." ¿Cómo evalúa esta situación un Scrum Master que comprende la teoría de Scrum?

a

Es una práctica recomendada, ya que más documentación siempre mejora la adherencia a Scrum

b

Es completamente inválido, ya que Scrum prohíbe cualquier tipo de documentación de proceso, sin excepciones

c

Puede contradecir Scrum: el marco es deliberadamente incompleto y se basa en la inteligencia del equipo. Las plantillas no son el problema, salvo que sustituyan la adaptación y el criterio del equipo.

d

Es irrelevante para la teoría de Scrum, ya que estos asuntos pertenecen únicamente a la gestión de calidad

7

Después de 6 sprints, un equipo afirma que Scrum no funciona porque los problemas de calidad continúan. Un Agile Coach observa que el Sprint Review se realiza sin stakeholders, el Daily es un reporte al Scrum Master y la Retrospectiva suele cancelarse. Según la teoría de Scrum, ¿cuál es el diagnóstico correcto?

a

Scrum efectivamente no es un framework adecuado para este equipo y deberían volver a un enfoque tradicional

b

El equipo no está aplicando Scrum realmente: fallan la transparencia, inspección y adaptación, por lo que sus pilares empíricos están rotos. El problema no es Scrum, sino su mala implementación.

c

El problema es que 6 sprints es insuficiente tiempo para ver resultados, se necesitan al menos 20 sprints

d

El problema radica únicamente en la falta de habilidades técnicas de los desarrolladores

8

Un Product Owner argumenta: "El empirismo de Scrum significa que no debemos planear nada por adelantado, solo reaccionar a lo que sucede sprint a sprint." Un Scrum Master responde que esta es una mala interpretación. ¿Cuál es la explicación correcta del empirismo según la Guía Scrum 2020?

a

El empirismo establece que el conocimiento proviene de la experiencia y de la toma de decisiones basada en lo observado — esto no prohíbe planear, sino que exige que los planes se ajusten constantemente según lo que se aprende, en lugar de seguirse rígidamente sin importar la nueva información

b

El PO tiene razón: el empirismo elimina toda forma de planeación anticipada

c

El empirismo solo aplica a proyectos de menos de 3 meses de duración

d

El empirismo es sinónimo exacto de la adaptación, uno de los tres pilares

9

Una organización tiene dos equipos: el Equipo A inspecciona su trabajo cada día en el Daily pero nunca ajusta su plan basándose en lo que descubre (siguen el plan original sin importar lo que aprenden). El Equipo B ajusta constantemente su trabajo, pero nunca hace visibles sus avances o bloqueos a nadie fuera del equipo. Según los 3 pilares empíricos, ¿qué le falta a cada equipo respectivamente?

a

Al Equipo A le falta adaptación (inspeccionan pero no ajustan); al Equipo B le falta transparencia (ajustan pero no hacen visible su trabajo, lo cual además vicia su propia inspección)

b

Al Equipo A le falta transparencia; al Equipo B le falta inspección

c

A ambos equipos les falta lo mismo: coraje, uno de los 5 valores de Scrum

d

Ninguno de los dos tiene ningún problema, ya que cada equipo puede priorizar libremente los pilares que más le convengan

10

Un equipo decide que, dado que "Scrum es deliberadamente incompleto y se basa en la inteligencia colectiva del equipo", pueden eliminar el Sprint Planning por completo, ya que "el equipo ya sabe qué hacer y discutirlo formalmente es una pérdida de tiempo". Después de 2 sprints sin Planning, el equipo reporta confusión sobre las prioridades reales y trabajo duplicado entre Developers. ¿Qué malinterpretación del marco de Scrum cometió el equipo?

a

Ninguna; eliminar eventos formales es exactamente lo que "deliberadamente incompleto" significa según la Guía Scrum

b

Confundieron que Scrum sea incompleto con que sus eventos sean opcionales. Scrum no define cómo hacer el trabajo, pero sus eventos, incluido el Sprint Planning, son esenciales para la transparencia, inspección y adaptación.

c

El problema es que el equipo necesitaba más Developers, no más eventos formales

d

No hay ningún malentendido; la confusión y el trabajo duplicado se debían a falta de experiencia técnica, no a la ausencia del evento

11

Durante un Sprint, una Developer descubre que una decisión técnica que ella propuso dos semanas atrás está causando un problema de rendimiento grave en producción. Tiene dos opciones: corregirlo discretamente sin mencionar el origen del problema, o comunicarlo abiertamente al equipo y al Product Owner, asumiendo que esto podría afectar la percepción de su desempeño técnico. Decide comunicarlo abiertamente de inmediato. ¿Qué combinación de valores de Scrum demuestra principalmente esta decisión?

a

Foco y Respeto, porque mantiene la atención en el Sprint Goal

b

Compromiso únicamente, ya que se compromete a arreglar el problema

c

Apertura (comunicar el problema y su origen sin ocultar información) y Coraje (asumir el riesgo personal de admitir el error)

d

Ninguno de los 5 valores aplica a decisiones individuales, solo a decisiones de equipo

12

Un Scrum Master observa que su equipo cumple perfectamente el Foco (siempre trabajan en el Sprint Backlog) y el Compromiso (siempre logran el Sprint Goal), pero en las Retrospectivas nadie menciona jamás un problema, una preocupación o un desacuerdo — todo se describe como "perfecto". Aplicando los 5 valores de Scrum, ¿qué interpretación es más precisa?

a

El equipo es un ejemplo perfecto de los 5 valores de Scrum funcionando en conjunto

b

Los valores de Scrum no se aplican a la dinámica de las Retrospectivas, solo a los eventos de ejecución del Sprint

c

Esto demuestra un Compromiso excepcionalmente alto que compensa la ausencia de los otros valores

d

Es probable que falten Apertura y Coraje: un equipo sin nunca un desacuerdo o preocupación visible probablemente está ocultando información o evitando temas incómodos, lo cual mina la base de confianza que los pilares empíricos requieren para funcionar

13

En el Sprint Planning, un Developer junior expresa dudas sobre si el equipo podrá completar el alcance propuesto, pero el resto del equipo, con más experiencia, insiste en que "siempre se puede" y avanza sin discutir más el punto. El Developer junior no insiste y el equipo termina fallando el Sprint Goal. En la Retrospectiva, ¿qué valores de Scrum deberían haberse aplicado mejor, y por parte de quién?

a

El problema fue exclusivamente del Scrum Master, por no asignar las tareas correctamente entre el equipo

b

Solo el Developer junior tuvo una falla de valores; el resto del equipo actuó correctamente al mantener la confianza en sus capacidades

c

Ningún valor de Scrum es relevante aquí, ya que se trata de una diferencia de experiencia técnica, no de valores

d

El equipo experimentado necesitaba más Respeto hacia la perspectiva del Developer junior como persona capaz, y el junior necesitaba más Coraje para insistir en su preocupación pese a la presión del grupo

14

Una organización mide el desempeño individual de los Developers comparando cuántos puntos de historia completa cada uno por Sprint, y usa este ranking para decisiones de bonificación. Un Scrum Master nota que, desde que se implementó esta métrica, los Developers han dejado de ayudarse entre sí y compiten por tomar las historias "más fáciles". ¿Qué valores de Scrum está erosionando directamente esta práctica organizacional?

a

Ninguno, ya que la medición de desempeño individual es independiente de los valores de Scrum

b

Únicamente Foco, porque distrae al equipo del Sprint Goal

c

Compromiso (con el equipo y sus objetivos compartidos, no solo metas individuales) y Respeto (verse mutuamente como compañeros capaces con quienes colaborar, no como competidores)

d

Apertura únicamente, porque genera secretismo sobre el desempeño individual

15

El Product Owner de un equipo cambia constantemente de opinión sobre las prioridades del Product Backlog sin explicar el razonamiento detrás de los cambios, y se molesta visiblemente cuando los Developers preguntan el porqué. Los Developers han aprendido a "no preguntar" y simplemente ejecutan lo que se les indica. ¿Qué valor de Scrum está ausente en esta dinámica, y de qué lado?

a

Falta únicamente Compromiso por parte del PO, ya que cambia de opinión con frecuencia

b

Falta Apertura por parte del PO (no comparte el razonamiento de sus decisiones) y probablemente Coraje por parte de los Developers (han dejado de cuestionar pese a tener dudas legítimas)

c

No falta ningún valor, ya que el PO tiene la autoridad exclusiva de decidir el orden del Product Backlog sin justificación

d

Falta Respeto exclusivamente por parte de los Developers, por no obedecer sin cuestionar al PO

16

Una organización con 14 Developers en un solo equipo Scrum decide que, para mantener "un solo equipo cohesionado centrado en el Product Goal", no van a dividirse en equipos más pequeños, sino que simplemente nombrarán 2 Scrum Masters para gestionar la coordinación. El Daily dura 35 minutos y varios Developers reportan que casi nunca hablan directamente con la mitad de sus compañeros. ¿Qué recomienda la Guía Scrum 2020 en este caso, y por qué falla la solución de la organización?

a

La Guía Scrum recomienda equipos de 10 o menos integrantes para facilitar la comunicación. Con 14 Developers, conviene dividir en equipos Scrum que compartan Product Goal, Product Backlog y Product Owner; agregar más Scrum Masters no soluciona el problema.

b

La solución es correcta: agregar más Scrum Masters es la forma recomendada de escalar un equipo grande sin dividirlo

c

El problema no tiene relación con el tamaño del equipo, sino con la duración del Daily, que debería reducirse a 15 minutos sin importar el tamaño

d

Un Scrum Team puede tener cualquier número de Developers sin límite, siempre que tenga suficientes Scrum Masters proporcionalmente

17

Un Product Owner está de vacaciones por dos semanas durante un Sprint activo. Antes de salir, le pide a un Developer senior del equipo que "tome decisiones de prioridad del Product Backlog en mi nombre" sin coordinarlo con nadie más, y que informe los cambios al volver. El Developer así lo hace. Al regresar el PO, ¿qué aspecto de la teoría de Scrum fue potencialmente vulnerado, y cuál no?

a

El Product Owner puede delegar tareas del Product Backlog, pero mantiene la responsabilidad de las decisiones. La delegación no rompe la regla de una sola persona; el riesgo fue la falta de transparencia durante la ausencia del PO.

b

Fue completamente inválido, ya que el Product Owner es una persona y nunca puede delegar ninguna parte de su trabajo

c

No hubo ningún problema en absoluto, ya que cualquier Developer puede asumir el rol de PO temporalmente sin restricciones

d

El único problema fue que el Developer no era un Scrum Master, que es el único rol autorizado para tomar decisiones del Product Backlog en ausencia del PO

18

Un Scrum Master, frustrado porque el equipo no avanza al ritmo esperado, comienza a asignar personalmente las tareas del Sprint Backlog cada mañana después del Daily, diciendo "así nos asegura que cada uno sabe exactamente qué hacer y avanzamos más rápido". El equipo, inicialmente, sí mejora su velocidad de entrega durante 2 sprints, pero luego comienza a depender completamente del SM para saber qué hacer, y deja de proponer ideas propias. ¿Cómo se explica esta paradoja según la teoría de Scrum?

a

No hay paradoja: el Scrum Master actuó correctamente al optimizar el flujo de trabajo del equipo de forma directa

b

La mejora inicial de velocidad ocultó el daño estructural: asignar tareas es un antipatrón porque viola la autogestión, y aunque genere ganancias de corto plazo, erosiona la capacidad del equipo de pensar y decidir por sí mismo, generando dependencia en lugar de madurez como equipo autogestionado

c

La paradoja se explica porque el equipo simplemente no tenía suficiente experiencia técnica desde el inicio

d

Esto demuestra que la autogestión es un concepto teórico que no funciona en la práctica real

19

Una empresa de consultoría tiene un equipo Scrum compuesto por 5 personas: un Scrum Master, un Product Owner, y 3 personas etiquetadas formalmente como "Backend Developer", "Frontend Developer" y "QA Tester". Cuando surge una tarea de pruebas durante un Sprint con alta carga de trabajo de desarrollo, el equipo decide que solo el "QA Tester" puede ejecutarla, ya que "no es su función" que los otros prueben. La tarea no se completa a tiempo. ¿Qué principio de Scrum Team está siendo violado?

a

Ninguno; cada Developer debe limitarse estrictamente a su especialidad técnica formal, según la Guía Scrum

b

El principio violado es la autogestión, ya que el QA Tester debió negarse a hacer la tarea

c

El principio de multifuncionalidad: los Developers como conjunto deben tener todas las habilidades necesarias para crear valor, compartiendo o adquiriendo habilidades según se necesite — limitarse rígidamente a etiquetas de especialidad contradice esto y generó el incumplimiento del Sprint

d

No es un problema de Scrum, es simplemente una limitación de recursos humanos de la organización

20

En una organización, un Scrum Master reporta jerárquicamente al gerente de los Developers de su equipo, y ese mismo gerente realiza las evaluaciones de desempeño anuales de todos, incluyendo del propio Scrum Master. El SM ha notado que evita señalar impedimentos relacionados con decisiones de ese gerente, "para no generar tensión". ¿Qué tensión estructural revela este escenario respecto al rol del Scrum Master?

a

No hay tensión alguna, ya que la estructura jerárquica de reporte no tiene relación con la efectividad del rol de Scrum Master

b

Esta es una práctica recomendada, ya que asegura alineación entre el Scrum Master y la gerencia

c

La solución correcta sería que el Scrum Master renuncie inmediatamente a su rol en esa organización

d

Existe una tensión entre el liderazgo servicial del Scrum Master y su dependencia jerárquica. Al evitar señalar impedimentos por temor a afectar su relación con la gerencia, deja de cumplir su función de facilitar la eliminación de obstáculos.

21

Un equipo realiza su Daily Scrum de la siguiente manera: cada Developer, en orden alfabético, le informa al Scrum Master qué hizo ayer, qué hará hoy y qué impedimentos tiene; el SM toma notas en una hoja de cálculo; el evento dura 22 minutos porque "hay mucho que reportar". Identifica TODOS los elementos de este escenario que contradicen la teoría del Daily Scrum según la Guía Scrum 2020.

a

Solo la duración de 22 minutos es un problema, ya que excede el timebox de 15 minutos

b

El único problema es que las preguntas de ayer/hoy/impedimentos ya no son obligatorias desde la versión 2020 de la Guía Scrum, por lo que no deberían usarse en absoluto

c

No hay ningún problema, ya que cada equipo puede definir libremente su propio formato de Daily Scrum sin restricciones de la Guía Scrum

d

Hay tres problemas: el Daily se convirtió en un reporte al Scrum Master en lugar de una inspección entre Developers; supera los 15 minutos y no evidencia un plan accionable para avanzar hacia el Sprint Goal.

22

Durante el Sprint Planning de un Sprint de 2 semanas, el equipo dedica 6 horas completas discutiendo el "por qué" (Sprint Goal) y el "qué" (selección del backlog), pero termina la sesión sin haber discutido el "cómo" se realizará el trabajo, asumiendo que "eso se resuelve en la marcha durante los Dailies". ¿Es esta una práctica válida según la Guía Scrum 2020?

a

No, es inválida en cualquier circunstancia, ya que los tres temas del Sprint Planning son obligatorios y deben completarse siempre en la misma sesión

b

Sí, es completamente válida, ya que el cómo nunca forma parte del Sprint Backlog, solo el qué y el por qué

c

Depende del contexto: Scrum no impone un formato rígido, pero omitir el “cómo” deja incompleto el Sprint Backlog, ya que incluye el objetivo, los elementos seleccionados y el plan para entregarlos.

d

Sí, es válida, porque el Daily Scrum reemplaza por completo la necesidad de planificar el cómo durante el Sprint Planning

23

Un Product Owner, presionado por un stakeholder importante, decide cancelar un Sprint a mitad de camino porque el stakeholder "ya no quiere ese producto, quiere otro completamente distinto", sin haber consultado al equipo sobre alternativas de ajuste de alcance dentro del Sprint actual. El Scrum Master cuestiona la decisión. ¿Quién tiene la autoridad correcta según la Guía Scrum, y qué matiz adicional debería considerarse?

a

Solo el Scrum Master tiene la autoridad de cancelar un Sprint, por lo que la decisión del PO es inválida por completo

b

El Product Owner es quien puede cancelar el Sprint si el Sprint Goal queda obsoleto. Sin embargo, por el impacto de la decisión, debe evaluarse si antes era posible ajustar el alcance dentro del Sprint.

c

Ningún rol individual tiene autoridad para cancelar un Sprint; debe ser una decisión consensuada por todo el Scrum Team y los stakeholders

d

El equipo de Developers tiene la autoridad de cancelar el Sprint, ya que son quienes ejecutan el trabajo

24

Un equipo realiza la Sprint Review con 12 stakeholders. El Product Owner solo muestra diapositivas con capturas del Incremento, sin demostración del producto funcionando ni espacio para discutir próximos pasos. Al finalizar, indica que la revisión está completada. Según la Guía Scrum, ¿qué elementos esenciales de la Sprint Review fueron omitidos?

a

La Review se volvió una presentación, no una sesión colaborativa. Faltó inspeccionar el Incremento funcionando, discutir próximos pasos y ajustar el Product Backlog según lo aprendido.

b

Ninguno; presentar capturas de pantalla es una forma válida y suficiente de cumplir el propósito de la Sprint Review

c

El único problema fue no incluir suficientes stakeholders; 12 es insuficiente para una Review válida

d

El evento fue válido porque cumplió su único requisito: informar a los stakeholders sobre el avance del Sprint

25

Un equipo lleva 5 Sprints consecutivos identificando en cada Retrospectiva el mismo problema: "la comunicación con el equipo de infraestructura es lenta y bloquea nuestro trabajo". Cada vez generan una acción de mejora, pero ninguna se implementa realmente porque "siempre hay algo más urgente en el Sprint siguiente". ¿Qué fallo estructural revela esta situación respecto al propósito de la Sprint Retrospective?

a

La Retrospectiva se volvió un ritual sin impacto: repetir el mismo problema sin implementar mejoras contradice su propósito de aumentar la calidad y efectividad, abordando acciones prioritarias lo antes posible.

b

Ninguno; es normal y esperado que algunos problemas persistan por varios sprints sin resolverse mientras se prioriza el trabajo del Sprint

c

El problema es exclusivamente del equipo de infraestructura, no del equipo Scrum que ejecuta la Retrospectiva

d

La solución correcta es eliminar la Retrospectiva, ya que claramente no está funcionando para este equipo

26

Un equipo completa el desarrollo de una funcionalidad durante el Sprint, y aunque no se ha realizado ninguna prueba de seguridad (la cual forma parte de su Definition of Done acordada), el Product Owner decide presentarla en la Sprint Review como "un avance preliminar" para obtener feedback de los stakeholders, aclarando que "no está totalmente terminada pero quiere mostrar dirección". ¿Es esta práctica coherente con la Guía Scrum 2020?

a

Sí, es válida, porque mostrar avances preliminares en la Sprint Review siempre es una buena práctica de transparencia

b

No es coherente: si un elemento no cumple la Definition of Done, no puede considerarse parte del Incremento ni siquiera presentarse en la Sprint Review — debe volver al Product Backlog para consideración futura, independientemente de la intención de obtener feedback temprano

c

Es válida solo si los stakeholders están de acuerdo explícitamente en ver trabajo incompleto

d

Es válida porque la Definition of Done solo aplica al final del proyecto completo, no a cada Sprint individual

27

Un Product Owner mantiene un Product Backlog con 230 elementos, de los cuales solo los primeros 8 están refinados con suficiente detalle para ser seleccionados en el próximo Sprint Planning; los restantes 222 son ideas generales sin estimar ni detallar. Un stakeholder se queja de que el backlog "está desorganizado e incompleto". ¿Cómo se evalúa esta situación según la teoría de los artefactos de Scrum?

a

El stakeholder tiene razón: un Product Backlog bien gestionado debe tener todos sus elementos completamente detallados y estimados en todo momento

b

Es un error grave, ya que el Product Backlog nunca debería tener más de 20 elementos en total

c

Esto es coherente con la naturaleza del Product Backlog como lista emergente: solo los elementos que serán seleccionados próximamente requieren suficiente refinamiento para considerarse "listos"; el refinamiento es una actividad continua, no un estado final requerido para todo el backlog de una vez

d

El problema real es que el PO debería haber delegado completamente la gestión del backlog a los Developers

28

Una historia de usuario dice: "Como administrador, quiero un botón en el sistema, para que el sistema funcione mejor." El equipo logra estimarla (le asignan 3 puntos de historia) y la incluyen en el Sprint. A mitad del Sprint, surge una discusión profunda sobre qué debía hacer exactamente el botón, ya que nadie recuerda los detalles acordados. Evaluando esta historia contra los criterios INVEST y las 3 C's, ¿cuál es el diagnóstico más completo?

a

La historia es válida porque logró ser estimada, lo cual cumple el criterio Estimable de INVEST y es suficiente

b

No hay ningún problema con la historia; la confusión se debe únicamente a una falla de memoria del equipo, no a la calidad de la historia en sí

c

El único problema es que la historia debió escribirse con más palabras técnicas específicas

d

Aunque fue estimada, la historia puede fallar en Valuable y Testable: no define un valor claro ni criterios de aceptación. La falta de conversación y acuerdos previos explica la confusión durante el Sprint.

29

Un equipo decide que, para "ahorrar tiempo", el Sprint Goal y el Product Goal serán literalmente el mismo enunciado en cada Sprint: "Mejorar el producto." Cuando un nuevo Developer se incorpora y pregunta cuál es la diferencia entre ambos en su equipo, nadie sabe responder con claridad. ¿Qué problema conceptual revela esta práctica?

a

Ninguno; usar el mismo enunciado para ambos compromisos es una simplificación válida y recomendada para ahorrar tiempo de planeación

b

Es una práctica correcta siempre que el equipo esté de acuerdo internamente, sin importar la claridad para nuevos miembros

c

El único problema es de comunicación con el nuevo Developer, no de la práctica en sí misma

d

Confunde compromisos con distintos horizontes: el Product Goal guía el producto a largo plazo, mientras el Sprint Goal define el propósito de un Sprint específico. Usar el mismo enunciado elimina el foco que cada uno debe aportar.

30

Durante un Sprint, los Developers descubren que, para completar un elemento del Product Backlog seleccionado, necesitan realizar un trabajo técnico adicional no anticipado (una refactorización) que no estaba en el plan original del Sprint Backlog. Deciden incluirla sin consultar al Product Owner, ya que consideran que es "una decisión puramente técnica de cómo hacer el trabajo". ¿Es esto coherente con la teoría de los artefactos de Scrum?

a

No, es inválido: cualquier cambio al Sprint Backlog requiere aprobación explícita del Product Owner antes de implementarse

b

Es inválido porque cualquier trabajo no planeado en el Sprint Planning original debe esperar al siguiente Sprint, sin excepciones

c

Es coherente: el Sprint Backlog pertenece a los Developers y puede actualizarse durante el Sprint. Los ajustes técnicos sobre cómo cumplir la Definition of Done son responsabilidad del equipo, sin requerir aprobación externa.

d

Es válido únicamente si el Scrum Master autoriza el cambio antes de que los Developers procedan

31

Una organización con 6 equipos Scrum trabajando sobre el mismo producto decide implementar Nexus. Sin embargo, mantienen Product Backlogs separados para cada equipo, cada uno con su propio Product Owner, y solo se reúnen una vez al mes para "compartir avances". Evaluando esta implementación contra los principios de escalado de Scrum, ¿qué inconsistencia central se observa?

a

Ninguna; Nexus permite explícitamente que cada equipo mantenga su propio Product Backlog y Product Owner de forma independiente

b

Contradice el escalado de Scrum: equipos que trabajan en un mismo producto deben compartir Product Goal, Product Backlog y Product Owner. Separarlos genera silos que Nexus busca evitar.

c

El único problema es la frecuencia de reunión, que debería ser semanal en lugar de mensual

d

Es una implementación correcta porque cada equipo conserva su autonomía total de decisión

32

Un equipo usa un tablero Kanban para visualizar su Sprint Backlog, con columnas "Por hacer", "En progreso" y "Hecho", y un límite de WIP (trabajo en progreso) de 3 tareas simultáneas. Un consultor externo les dice: "Ya no están haciendo Scrum, están haciendo Kanban." ¿Es correcta esta afirmación?

a

No es correcta: Kanban puede complementar Scrum. Un tablero visual y límites de WIP no eliminan los eventos, artefactos ni roles de Scrum; solo ayudan a gestionar el flujo de trabajo.

b

Sí, es correcta: usar cualquier elemento visual de Kanban automáticamente convierte la práctica del equipo en Kanban puro, excluyendo Scrum

c

Es parcialmente correcta solo si el equipo elimina el Daily Scrum, ya que Kanban lo reemplaza completamente

d

Es correcta únicamente si el equipo también elimina el Sprint como evento contenedor

33

En una sesión de Scrum de Scrums entre 4 equipos, el representante de cada equipo es designado permanentemente por el gerente de programa como "el Tech Lead de cada equipo", sin posibilidad de rotación, y se les indica que deben "reportar el estado" en lugar de "coordinar impedimentos". ¿Qué elementos de esta implementación contradicen las prácticas recomendadas del Scrum de Scrums?

a

Dos elementos: la designación permanente y jerárquica del representante (en lugar de poder rotar entre cualquier miembro del equipo) y el cambio de propósito hacia "reportar estado" en lugar de coordinar dependencias e impedimentos entre equipos, lo cual desvirtúalanaturaleza colaborativa del evento

b

Ninguno; el Tech Lead es siempre el representante correcto y obligatorio para el Scrum de Scrums en cualquier organización

c

El único problema es la frecuencia con la que se reúnen los representantes

d

Es una implementación perfectamente alineada con las mejores prácticas de escalado de Scrum

34

Un equipo descubre que su Daily Scrum, con timebox de 15 minutos, frecuentemente termina en 6 u 8 minutos porque "no hay mucho que discutir". El Scrum Master, preocupado de que esto "no parece suficientemente riguroso", instruye al equipo a extender la conversación llenando el tiempo restante con discusiones técnicas detalladas que normalmente se resolverían fuera del evento. ¿Es correcta esta instrucción según el concepto de timeboxing?

a

Sí, es correcta: todo timebox debe usarse en su totalidad, ya que de lo contrario el evento no se está aprovechando adecuadamente

b

No es correcta: el timebox es un límite máximo, no un tiempo obligatorio. Si el Daily cumple su propósito en menos tiempo, es válido; forzar discusiones adicionales reduce la eficiencia.

c

Es correcta solo si el equipo está de acuerdo voluntariamente en extender la conversación

d

Es incorrecta únicamente porque las discusiones técnicas detalladas deberían ocurrir en el Sprint Planning, no en ningún otro momento

35

Una organización que evalúa frameworks de escalado describe sus necesidades así: tienen 4 equipos trabajando en el mismo producto, valoran fuertemente mantenerse lo más cerca posible de la Scrum Guide original con mínimas adiciones, y quieren evitar la complejidad de múltiples niveles de planificación que requieren otros frameworks más extensos. Basándote en las características distintivas de los frameworks de escalado estudiados, ¿cuál encaja mejor con esta descripción y por qué?

a

SAFe, porque es el framework más completo y ofrece más niveles de planificación que garantizan cobertura total

b

LeSS, porque es el único framework que permite tener más de un Product Owner por producto

c

Nexus, porque está diseñado explícitamente como la extensión más cercana a la Scrum Guide, añadiendo elementos mínimos como el Nexus Integration Team y un Sprint Backlog compartido, sin introducir múltiples niveles adicionales de planificación organizacional

d

Scrum de Scrums, porque es un framework completo de escalado equivalente a Nexus o LeSS en alcance y estructura

36

Un Scrum Master observa que dos Developers mantienen un desacuerdo técnico sobre arquitectura que afecta decisiones desde hace 3 Sprints. En lugar de decidir por ellos, facilita una sesión con preguntas para que analicen opciones y lleguen a un acuerdo. ¿Qué roles del Scrum Master aplica y por qué es mejor que decidir directamente?

a

Únicamente el rol de gestor de impedimentos, ya que cualquier desacuerdo del equipo se clasifica automáticamente como impedimento que el SM debe resolver directamente

b

Ninguno de los roles del SM aplica a desacuerdos técnicos, que deben resolverse exclusivamente entre los Developers sin ninguna intervención

c

El rol de líder servicial únicamente, que se limita a escuchar sin ninguna intervención activa

d

Aplica como coach y facilitador: guía la conversación sin imponer la solución, ayudando al equipo a desarrollar su capacidad de resolver conflictos y evitar dependencia del Scrum Master.

37

Durante 4 Sprints consecutivos, un equipo no logra completar el Sprint Backlog seleccionado. El Scrum Master, analizando la causa raíz, descubre que el verdadero impedimento es que el departamento de seguridad de la información tarda en promedio 8 días hábiles en aprobar cualquier cambio de configuración, un cuello de botella externo al equipo y a la organización inmediata del SM. ¿Cuál es la acción más alineada con el rol de "agente de cambio" del Scrum Master en este caso?

a

Aceptar que este impedimento está fuera de su alcance y enfocarse únicamente en ayudar al equipo a planificar Sprints más pequeños alrededor del cuello de botella, sin intentar resolverlo

b

Ignorar el impedimento ya que la función del SM se limita estrictamente al equipo, sin ninguna responsabilidad hacia la organización en general

c

Pedir al Product Owner que elimine de la lista de prioridades cualquier elemento que requiera aprobación de seguridad, evitando el problema en lugar de resolverlo

d

Actuar como agente de cambio, ayudando a la organización a comprender el impacto del impedimento y promoviendo mejoras con seguridad para lograr un proceso más ágil y empírico.

38

Un Scrum Master nuevo en su rol observa que, en su ausencia por una emergencia médica de una semana, el equipo realizó su Daily Scrum, avanzó en el Sprint Backlog sin contratiempos, y resolvió un impedimento menor por sí mismo coordinando directamente con otro equipo. Al regresar, el SM se siente "innecesario" y preocupado por su valor en el equipo. ¿Cómo debería interpretar esta situación a la luz de la teoría del liderazgo servicial?

a

Su preocupación está justificada: si el equipo funciona bien sin él, significa que su rol no aporta valor real y debería considerar que la organización elimine la posición

b

Esto demuestra que el equipo nunca necesitó un Scrum Master desde el principio

c

Es una señal de éxito: el liderazgo servicial busca desarrollar la autogestión del equipo. Que pueda avanzar y resolver impedimentos sin depender del Scrum Master demuestra madurez, no falta de valor del rol.

d

El SM debería sentirse preocupado porque esto significa que el equipo violó la regla de que solo el Scrum Master puede facilitar el Daily Scrum

39

Un Product Owner le pide al Scrum Master que "presione" a los Developers para que acepten más elementos del Product Backlog en el próximo Sprint de los que ellos mismos consideran viables, argumentando que "hay una fecha límite del negocio que debe cumplirse". ¿Cuál es la respuesta más alineada con la teoría de Scrum por parte del SM?

a

Aceptar la solicitud y presionar al equipo, ya que el Scrum Master debe priorizar las necesidades del negocio comunicadas por el Product Owner por encima de la autogestión del equipo

b

Explicar al PO que los Developers deciden cuánto trabajo es viable en el Sprint Planning según su capacidad y Definition of Done. El SM debe facilitar una conversación sobre opciones reales, sin imponer presión que afecte la autogestión.

c

Negarse a cualquier conversación sobre el tema, ya que las fechas límite del negocio no son responsabilidad del Scrum Master en ningún sentido

d

Delegar la decisión completamente al Product Owner, ya que tiene autoridad total sobre cuánto trabajo debe realizar el equipo en cada Sprint

40

Una organización está adoptando Scrum por primera vez. El Scrum Master de uno de los equipos pasa la mayor parte de su tiempo dentro de su propio equipo, pero rara vez interactúa con otros Scrum Masters de la organización o con la gerencia general sobre cómo está progresando la adopción de Scrum a nivel organizacional. ¿Qué dimensión del servicio del Scrum Master, según la Guía Scrum 2020, está siendo menos atendida, y qué riesgo genera esto?

a

e descuida el servicio a la organización: el Scrum Master también debe apoyar la adopción de Scrum, compartir aprendizajes y ayudar a remover impedimentos organizacionales. Sin esto, los problemas sistémicos pueden permanecer sin resolver.

b

Ninguna dimensión está desatendida; el Scrum Master debe enfocarse exclusivamente en su propio equipo sin ninguna responsabilidad hacia la organización más amplia

c

Se está desatendiendo únicamente el servicio al Product Owner, ya que es la única relación formalmente obligatoria del SM

d

El problema no tiene relación con ninguna de las tres dimensiones de servicio del SM descritas en la Guía Scrum

Explicación

1

El valor de software funcionando sobre documentación NO elimina el registro de decisiones — especialmente arquitectónicas—, solo prioriza la entrega funcional. Eliminar TODA documentación generó exactamente el desperdicio que el pensamiento Lean busca evitar.

2

Como con los otros 3 valores del Manifiesto, este no elimina su contraparte (los contratos), sino que establece una prioridad relativa cuando hay tensión entre ambos.

3

Los 12 principios no son independientes entre sí. Entregar software con frecuencia sin atención a la excelencia técnica ni desarrollo sostenible produce exactamente este patrón: deuda técnica, defectos y agotamiento.

4

Ningún documento reemplaza al otro. El Manifiesto se enfoca en valores de desarrollo de software; la DOI complementa con valores de gestión de proyectos ágiles a un nivel más amplio.

5

El pensamiento Lean distingue entre desperdicio real y elementos que sostienen la capacidad de respuesta y resiliencia del sistema, como capacitación cruzada e inventario de seguridad para piezas críticas.

6

El marco es deliberadamente incompleto y se basa en la inteligencia colectiva, no en instrucciones detalladas — pero el problema no es tener apoyos, es que sustituyan la adaptación y el pensamiento del equipo.

7

El equipo no tiene transparencia real, ni inspección genuina, ni adaptación —los tres pilares empíricos están rotos simultáneamente. No es que Scrum no funcione, es que lo que ejecutan no es Scrum.

8

El Product Goal, el Sprint Goal y el Sprint Backlog SON planes — lo que el empirismo exige es que estos planes se actualicen constantemente con base en lo aprendido, no que se elimine la planeación.

9

El Equipo A inspecciona pero no actúa sobre lo que descubre: le falta adaptación. El Equipo B ajusta sin transparencia hacia afuera, lo cual vicia su propia inspección.

10

Lo que Scrum deja abierto es CÓMO se hace el trabajo; los eventos, artefactos y roles SON las partes mínimas que el marco sí define explícitamente. Eliminarlos es dejar de practicar Scrum.

11

La Apertura implica ser transparente sobre el trabajo y los desafíos —incluyendo errores propios—, y el Coraje es la valentía de hacer lo correcto incluso cuando es incómodo personalmente.

12

Un equipo real tendrá fricciones y desacuerdos genuinos. Su ausencia total en la Retrospectiva sugiere falta de Apertura y de Coraje, lo que erosiona la confianza que sostiene a los pilares empíricos.

13

El Respeto implica ver a cada miembro del equipo —incluyendo a los más junior— como personas capaces cuya perspectiva merece consideración real. El Coraje del junior para sostener su punto también falló.

14

Una métrica de ranking individual incentiva comportamientos opuestos al Compromiso compartido del equipo y al Respeto (verse como compañeros capaces, no rivales).

15

Comunicar el razonamiento de las decisiones es parte de mantener la transparencia y la confianza del equipo (Apertura). Del lado de los Developers, dejar de preguntar refleja pérdida de Coraje.

16

La Guía Scrum recomienda 10 o menos por capacidad de comunicación; con 14, debería considerarse reorganización en varios equipos compartiendo Product Goal, Backlog y PO — no añadir capas de gestión.

17

El PO puede delegar el trabajo del backlog manteniéndose responsable; eso no rompe la regla de "una sola persona". El riesgo real es la falta de transparencia durante el proceso, no la delegación en sí.

18

Asignar tareas centralizadamente genera una ganancia aparente de eficiencia inicial, pero sustituye el desarrollo de la capacidad de autogestión del equipo, generando dependencia en lugar de madurez.

19

Los equipos son multifuncionales: sus miembros en conjunto tienen las habilidades necesarias para crear valor, compartiéndolas o adquiriéndolas según sea necesario.

20

El liderazgo servicial requiere poder señalar y remover impedimentos, incluyendo los que provienen de decisiones gerenciales. La estructura de evaluación crea un incentivo real para evitar esa función.

21

Las 3 preguntas ya no son obligatorias, no deberían usarse en absoluto — Aplica correctamente un dato real (las preguntas dejaron de ser prescriptivas en 2020) pero saca una conclusión incorrecta: no usarlas no es obligatorio per se, el verdadero problema del escenario es la dirección del reporte y la falta de plan accionable, no el uso de las preguntas en sí.

22

El Sprint Backlog se compone del Sprint Goal, los elementos seleccionados y el plan para entregarlos (cómo). Omitir completamente el "cómo" deja el artefacto incompleto desde el inicio.

23

El PO es la única persona con autoridad para cancelar el Sprint, y la causa válida (Sprint Goal obsoleto) parece cumplirse; pero vale la pena cuestionar si se exploraron alternativas de ajuste antes de cancelar.

24

La Sprint Review es una sesión de trabajo, no una presentación unidireccional. Este escenario reproduce el antipatrón: sin colaboración sobre qué hacer después ni ajuste del Product Backlog basado en lo aprendido.

25

Las mejoras más impactantes identificadas en la Retrospectiva deben abordarse lo antes posible, incluso incorporándose al Sprint Backlog del siguiente Sprint. Repetir el mismo problema 5 veces sin acción real vacía el evento de su propósito.

26

Trabajo que no cumple la Definition of Done no puede presentarse en la Sprint Review, sin excepciones basadas en la intención. Debe volver al Product Backlog.

27

El Product Backlog es una lista emergente — nunca está "completa" ni todos sus elementos necesitan el mismo nivel de detalle simultáneamente. El refinamiento es continuo, no un estado final.

28

La ausencia de valor claro (Valuable) y de criterios de aceptación (Testable, vinculado a Confirmation) explica tanto la estimación poco confiable como la confusión posterior — son síntomas del mismo problema raíz.

29

El Product Goal da dirección de largo plazo; el Sprint Goal da foco específico a un Sprint particular. Un enunciado genérico usado para ambos elimina la capacidad de foco que cada uno debe aportar.

30

El Sprint Backlog es un plan por y para los Developers, que se actualiza a lo largo del Sprint. Las decisiones sobre el "cómo" lograr la Definition of Done son responsabilidad de los Developers, sin aprobación externa.

31

Cuando varios equipos trabajan sobre el mismo producto, deben compartir el mismo Product Goal, Product Backlog y Product Owner. Backlogs y POs separados recrean los silos que el escalado busca evitar.

32

Kanban es complementario, una técnica de visualización de flujo que puede usarse dentro del marco de Scrum sin sustituirlo. El equipo conserva Sprint, eventos, artefactos y roles.

33

El Scrum de Scrums no requiere un rol fijo como representante; puede rotar entre cualquier miembro. Su propósito es coordinar dependencias e impedimentos, no convertirse en una cadena de reporte jerárquico.

34

El timebox es un techo máximo, no una meta a llenar. Un Daily Scrum eficiente que cumple su propósito en menos tiempo del máximo permitido es exactamente lo que se espera.

35

Nexus se describe como el framework de escalado más cercano a la Scrum Guide original, con adiciones mínimas — coincide con los criterios de cercanía a la guía y mínima complejidad adicional de la organización.

36

El SM actúa como coach y facilitador: no impone la decisión, sino que guía el proceso para que el equipo construya su propia respuesta, coherente con el objetivo de volverse innecesario para este tipo de situaciones.

37

El SM sirve a la organización ayudando a comprender y promulgar un enfoque empírico para el trabajo complejo, y eliminando barreras entre partes interesadas y equipos — exactamente lo que este escenario sistémico exige.

38

El liderazgo servicial busca ayudar al equipo a desarrollar autogestión real. Un equipo capaz de sostener sus eventos sin el SM demuestra que el trabajo de habilitación está funcionando, no que sea redundante.

39

La selección de cuánto trabajo es viable en un Sprint es decisión de los Developers. La respuesta correcta del SM es facilitar una conversación honesta sobre las opciones reales, protegiendo la autogestión del equipo.

40

La Guía Scrum describe tres dimensiones de servicio del SM: al equipo, al Product Owner y a la organización. Enfocarse exclusivamente en el equipo propio deja huérfana la tercera dimensión.

#	Player	Accuracy	time
1	Cristel July 7, 2026	% 100	04:14
2	Daniela Alejandra Escalante Garcia July 7, 2026	% 100	23:53
3	La Maye July 11, 2026	% 100	30:19
4	Marianella Aponte R. July 7, 2026	% 100	41:12
5	Roger July 7, 2026	% 98	35:08
6	Camilo Nuñez July 7, 2026	% 95	22:39
7	Mauricio Prada July 7, 2026	% 95	37:01
8	yerson July 7, 2026	% 93	22:42
9	Cristian Sierra July 7, 2026	% 93	28:34
10	Luz Ángela July 7, 2026	% 93	38:38

You can integrate the game into an LMS compatible with LTI 1.1 or LTI 1.3 such as Canvas, Moodle, or Blackboard. This way, the scores will be automatically saved into the platform’s gradebook.

Simulacro Scrum final

Quiz

About this activity

Created by

Download the paper version to play

Top Games

Quiz

UPS 5 Seeing Habits Quiz

Quiz

Photosynthesis vs Cellular Respiration - Practice Quiz

Quiz

Practice Quiz - Punnett Square, Variation, and Mutations

Quiz

Tissues - Practice Quiz

Quiz

Spanish Alphabet Listening

Simulacro Scrum finalOnline version

by Cindy Mariana ARIZA RODRIGUEZ

Un Product Owner argumenta: "El empirismo de Scrum significa que no debemos planear nada por adelantado, solo reaccionar a lo que sucede sprint a sprint." Un Scrum Master responde que esta es una mala interpretación. ¿Cuál es la explicación correcta del empirismo según la Guía Scrum 2020?

Explicación

		%
	Anonymous	%
		%
		%