Preguntas de entrevista para Scrum Master: La guía definitiva de preparación

Las organizaciones que utilizan marcos ágiles reportan un 60 % de reducción en el tiempo de lanzamiento al mercado y un 25 % de aumento en productividad en comparación con enfoques tradicionales de gestión de proyectos, según el 17.° State of Agile Report [1]. El Scrum Master se sitúa en el centro de esta transformación — no como un gerente de proyectos rebautizado, sino como un líder servicial que habilita equipos de alto rendimiento. Los entrevistadores que evalúan candidatos a Scrum Master buscan una combinación específica: conocimiento profundo del marco, instinto de coaching, habilidad de resolución de conflictos y la capacidad de proteger a un equipo sin crear dependencia. Esta guía cubre las preguntas más frecuentes en entrevistas de Scrum Master en cuatro categorías — conocimiento del marco y proceso, conductuales y de liderazgo, situacionales y basadas en escenarios, y conceptos ágiles avanzados — con marcos de respuesta detallados y lo que los entrevistadores realmente evalúan.

Puntos clave

• Las entrevistas de Scrum Master evalúan tu comprensión de la teoría Scrum Y tu capacidad para aplicarla en situaciones reales y desordenadas
• Espera preguntas que exploren si eres un ejecutor de procesos o un verdadero líder servicial
• Las preguntas conductuales evalúan tu capacidad de coaching, resolución de conflictos y gestión de stakeholders
• Prepara ejemplos concretos que muestren cómo mejoraste la velocidad del equipo, eliminaste impedimentos y facilitaste el cambio organizacional
• Demostrar conocimiento de marcos de escalamiento (SAFe, LeSS, Nexus) es cada vez más esperado

Preguntas de conocimiento del marco y proceso

1. ¿Cuáles son los tres pilares del control empírico de procesos en Scrum y cómo aplicas cada uno en la práctica?

Lo que buscan los entrevistadores: Que entiendes que Scrum se basa en el empirismo, no solo en ceremonias. Marco de respuesta: Los tres pilares son transparencia, inspección y adaptación [2]. Transparencia significa hacer visible el estado del trabajo — no solo a través del Sprint Backlog y gráficos de burndown, sino a través de conversaciones honestas en los Daily Scrums donde los miembros del equipo sacan a la luz los bloqueadores en lugar de dar informes de estado. Inspección significa examinar regularmente los artefactos y el progreso — los Sprint Reviews son inspecciones del incremento del producto, las Retrospectivas son inspecciones del proceso. Adaptación significa ajustar basándose en lo aprendido — aquí es donde muchos equipos fallan, tratando las acciones de la Retrospectiva como sugerencias en lugar de compromisos. Da un ejemplo específico: "Después de tres Sprints donde las pruebas eran el cuello de botella, nos adaptamos implementando una Definition of Done con enfoque 'test-first' que requería casos de prueba antes de comenzar el desarrollo. Nuestra tasa de defectos escapados bajó un 40 % en el trimestre siguiente."

2. ¿Cómo diferencias el rol del Scrum Master del de un Gerente de Proyectos?

Lo que buscan los entrevistadores: Una comprensión clara de que son roles fundamentalmente diferentes, no solo títulos diferentes. Marco de respuesta: Un Gerente de Proyectos es responsable del plan, asigna trabajo, rastrea el progreso y es responsable de la entrega. Un Scrum Master es responsable del proceso, guía al equipo hacia la autogestión, elimina impedimentos y es responsable de la efectividad del equipo [3]. El Scrum Master no asigna tareas — el Equipo de Desarrollo toma trabajo del Sprint Backlog. El Scrum Master no crea informes de estado para la gerencia — los artefactos del equipo (Sprint Backlog, Incremento, burndown) proporcionan transparencia. Donde un Gerente de Proyectos podría decir "necesitamos agregar recursos para cumplir la fecha límite", un Scrum Master podría decir "examinemos por qué bajó nuestra velocidad y abordemos la causa raíz." Enfatiza que muchas organizaciones contratan erróneamente Scrum Masters para que sean Gerentes de Proyectos Ágiles, y parte del rol es educar al liderazgo sobre esta distinción.

3. ¿Qué es la Definition of Done y por qué importa?

Lo que buscan los entrevistadores: Que ves la DoD como un compromiso de calidad, no una lista de verificación para evadir. Marco de respuesta: La Definition of Done es la comprensión compartida del equipo sobre lo que "terminado" significa para cada elemento del Product Backlog. Típicamente incluye criterios como: código revisado, pruebas unitarias pasando con umbral mínimo de cobertura, pruebas de integración pasando, documentación actualizada, benchmarks de rendimiento alcanzados y desplegado en staging [4]. La DoD importa porque sin ella, "terminado" es subjetivo — para un desarrollador "terminado" puede significar "funciona en mi máquina" mientras para otro significa "listo para producción." Una DoD débil crea trabajo sin terminar que se acumula como deuda técnica, haciendo que las métricas de velocidad pierdan sentido porque el equipo cuenta trabajo parcialmente completado. Comparte cómo has evolucionado la DoD de un equipo a lo largo del tiempo: "Cuando llegué, la DoD tenía tres elementos. En seis meses, la fortalecimos gradualmente hasta doce criterios, lo que inicialmente redujo la velocidad un 20 % pero eliminó completamente nuestro problema de bugs de regresión."

4. ¿Cómo manejas la planificación del Sprint cuando el equipo se compromete de más consistentemente?

Lo que buscan los entrevistadores: Un enfoque de coaching que construya la responsabilidad del equipo en lugar de imponer restricciones. Marco de respuesta: Primero, diagnostica por qué ocurre el sobrecompromiso — ¿es presión externa de stakeholders, sesgo de optimismo dentro del equipo o malas prácticas de estimación? Luego aborda la causa raíz. Si el equipo responde a presión, facilita una conversación con el Product Owner sobre el ritmo sostenible y el costo del cambio de contexto cuando el trabajo a medio terminar se arrastra [5]. Si la estimación es el problema, introduce técnicas como sesiones de calibración de story points, historias de referencia o planning poker con velocidad histórica como barrera. El movimiento de coaching clave es hacer el patrón visible: "Comencé a rastrear compromiso versus completado por Sprint en un gráfico simple. Después de tres Sprints, el equipo podía ver el patrón por sí mismo y comenzó a autocorregirse. Redujeron su compromiso de Sprint un 15 % y comenzaron a completar el 95 % del trabajo planificado, lo que realmente aumentó el rendimiento total."

5. Explica el propósito de cada evento Scrum y qué pasaría si lo omitieras.

Lo que buscan los entrevistadores: Que entiendes la contribución única de cada evento en lugar de verlos como reuniones obligatorias. Marco de respuesta: Sprint Planning alinea al equipo con el Objetivo del Sprint y la estrategia de descomposición — omítelo y el equipo trabaja en elementos individuales sin un objetivo unificador, reduciendo la colaboración. El Daily Scrum permite la inspección y adaptación del plan del Sprint dentro del Sprint — omítelo y los impedimentos se pudren, el trabajo se duplica y la sincronización se rompe. El Sprint Review inspecciona el Incremento con los stakeholders — omítelo y el producto diverge de las necesidades del usuario porque los ciclos de retroalimentación se rompen. La Sprint Retrospective inspecciona el proceso del equipo — omítela y la mejora se estanca, las frustraciones se acumulan y el equipo se estanca [6]. Nota que el Sprint en sí es un evento contenedor, y todos los demás eventos existen para apoyar el Objetivo del Sprint. "He visto equipos que dejaron las Retrospectivas porque 'se sentían como una pérdida de tiempo.' En tres Sprints, su tiempo de ciclo se duplicó porque problemas recurrentes — como un fallo intermitente de CI — nunca se sacaron a la luz ni se abordaron."

Preguntas conductuales y de liderazgo

6. Cuéntame sobre una ocasión en la que resolviste un conflicto dentro de tu equipo de desarrollo.

Lo que buscan los entrevistadores: Habilidad de mediación, inteligencia emocional y si abordas el conflicto o lo evitas. Marco de respuesta: Usa el método STAR con énfasis en tu enfoque de facilitación. Elige un conflicto interpersonal genuino — no solo un desacuerdo técnico. Quizás dos ingenieros senior tenían filosofías arquitectónicas opuestas que estaban causando revisiones de código pasivo-agresivas y bloqueando pull requests. Describe cómo (1) observaste el patrón a través de métricas de revisión y señales de moral del equipo, (2) tuviste conversaciones individuales para entender la perspectiva y las preocupaciones subyacentes de cada persona, (3) facilitaste una sesión estructurada donde ambos pudieron presentar su enfoque con criterios objetivos de evaluación, y (4) guiaste al equipo hacia un marco de decisión que pudieran reutilizar. Cuantifica el impacto: "El tiempo de ciclo de merge requests bajó de 4,2 días a 1,8 días, y los dos ingenieros finalmente coautorearon un proceso de registro de decisiones arquitectónicas del equipo."

7. ¿Cómo guías a un Product Owner que escribe historias de usuario vagas?

Lo que buscan los entrevistadores: Habilidades de coaching y la capacidad de influir sin autoridad. Marco de respuesta: Evita la tentación de reescribir las historias tú mismo — eso crea dependencia. En su lugar, usa preguntas socráticas durante el Backlog Refinement: "¿Qué problema está intentando resolver el usuario? ¿Cómo sabríamos que esto está terminado? ¿Cuál es la versión más pequeña de esto que entrega valor?" [7]. Introduce los criterios INVEST (Independiente, Negociable, Valiosa, Estimable, Pequeña, Testeable) como un lenguaje compartido en lugar de una herramienta de juicio. Ofrece trabajar en pareja con el Product Owner en la escritura de historias durante algunas sesiones, no para hacer el trabajo sino para modelar el proceso de pensamiento. "Trabajé con un PO que escribía historias como 'Mejorar el tablero.' A través de la facilitación del refinamiento, lo descompusimos en seis historias específicas con criterios de aceptación claros. En un mes, el PO escribía a ese nivel de forma independiente."

8. Describe una ocasión en la que tuviste que proteger a tu equipo de interferencia externa durante un Sprint.

Lo que buscan los entrevistadores: Liderazgo servicial en acción — proteger al equipo mientras se mantienen las relaciones con los stakeholders. Marco de respuesta: Esta es una responsabilidad clásica del Scrum Master. Describe una situación donde un stakeholder — quizás un VP o un líder de Ventas — quería insertar trabajo urgente a mitad del Sprint. Explica cómo (1) reconociste la urgencia, (2) explicaste el costo de la interrupción (impuesto de cambio de contexto, posible fallo del Objetivo del Sprint), (3) ofreciste alternativas (¿puede esperar al próximo Sprint? ¿podemos intercambiar elementos del mismo tamaño?) y (4) escalaste al Product Owner para la priorización en lugar de tomar la decisión tú mismo [8]. "Un VP de Ventas quería que se incorporara un cambio en el tablero a mitad del Sprint para una presentación ante la junta. En lugar de una negativa directa, facilité una conversación de 15 minutos entre el VP y el Product Owner para discutir las compensaciones. Acordaron una exportación manual de datos como solución puente, y el cambio del tablero fue priorizado para el siguiente Sprint."

9. ¿Cómo mides tu efectividad como Scrum Master?

Lo que buscan los entrevistadores: Autoconciencia y pensamiento orientado a resultados más allá de métricas de vanidad. Marco de respuesta: Evita métricas que reflejen el rendimiento del equipo en lugar de la efectividad del Scrum Master. Concéntrate en: (1) estabilidad y compromiso del equipo — ¿las personas se quedan, son altas las tasas de participación en Retrospectivas?, (2) velocidad de mejora del proceso — ¿qué tan rápido identifica y resuelve el equipo los impedimentos?, (3) tasa de cumplimiento del Objetivo del Sprint — no finalización de historias, sino logro de objetivos, (4) tendencias de satisfacción de stakeholders, (5) la creciente independencia del equipo — un gran Scrum Master debería ser cada vez menos necesario para la facilitación diaria [9]. "Hago seguimiento de lo que llamo la 'tasa de graduación de coaching' — el porcentaje de impedimentos que el equipo resuelve sin mi intervención. Cuando empecé, era del 30 %. Después de un año, era del 75 %. Eso me dice que estoy construyendo capacidad, no dependencia."

Preguntas situacionales y basadas en escenarios

10. Un desarrollador te dice en privado que cree que el líder del equipo está tomando decisiones técnicas unilaterales sin consultar al equipo. ¿Cómo lo manejas?

Lo que buscan los entrevistadores: Capacidad para navegar jerarquías, honrar la confidencialidad y abordar problemas sistémicos. Marco de respuesta: Primero, agradece al desarrollador por plantear la preocupación y asegúrale que abordarás el patrón sin atribuírselo. Luego observa — asiste a discusiones técnicas, revisa cómo se documentan las decisiones, busca evidencia del patrón. Si se confirma, plantéalo como una observación de proceso en la Retrospectiva: "He notado que algunas decisiones técnicas se están tomando fuera de las discusiones del equipo. ¿Cómo podemos crear un proceso donde la opinión de todos esté incluida?" [10]. Si el patrón persiste, ten una conversación privada de coaching con el líder del equipo sobre principios de autoorganización. El objetivo no es castigar la autoridad sino crear estructuras colaborativas de toma de decisiones.

11. La velocidad de tu equipo ha caído un 30 % en los últimos tres Sprints. ¿Qué pasos tomas?

Lo que buscan los entrevistadores: Pensamiento diagnóstico en lugar de intervenciones reactivas. Marco de respuesta: Las caídas de velocidad tienen muchas causas potenciales — no saques conclusiones precipitadas. Investiga sistemáticamente: (1) Verifica factores externos — salidas de miembros del equipo, aumento de carga de soporte a producción, inestabilidad del entorno o distracciones organizacionales. (2) Examina el trabajo en sí — ¿ha aumentado la complejidad? ¿Se subestimaron historias recientes? ¿Está la deuda técnica ralentizando el desarrollo? (3) Revisa la dinámica del equipo — ¿hay conflictos sin resolver, agotamiento o desvinculación? (4) Observa cambios en el proceso — ¿se introdujo una nueva herramienta, política o dependencia? Usa la Retrospectiva para sacar a la luz el diagnóstico del propio equipo, complementado con datos de tu investigación. "Cuando mi equipo experimentó una caída de velocidad, los datos mostraron que los incidentes en producción se habían triplicado debido a un cambio reciente de infraestructura. Al colaborar con el equipo de DevOps para estabilizar el entorno, la velocidad se recuperó en dos Sprints."

12. El Product Owner quiere cancelar el Sprint porque las prioridades del negocio han cambiado drásticamente. ¿Qué haces?

Lo que buscan los entrevistadores: Comprensión de cuándo es apropiada la cancelación del Sprint y el rol del Scrum Master en esa decisión. Marco de respuesta: Según la Guía Scrum, solo el Product Owner puede cancelar un Sprint, y debe ocurrir cuando el Objetivo del Sprint se vuelve obsoleto [11]. Tu rol es asegurar que la decisión sea informada y que se siga el proceso. Facilita una conversación: ¿Qué cambió específicamente? ¿El Objetivo del Sprint actual es verdaderamente obsoleto, o puede adaptarse? ¿Cuál es el costo de la cancelación (revisión de trabajo completado, esfuerzo de replanificación, impacto en la moral del equipo)? Si la cancelación procede, facilita una revisión del trabajo completado y luego realiza Sprint Planning para un nuevo Sprint. "He experimentado una cancelación de Sprint en mi carrera. Un cambio regulatorio invalidó completamente nuestro Objetivo del Sprint. Realizamos un mini-Review del trabajo completado, hicimos un Sprint Planning abreviado, y el equipo apreció la transparencia de la decisión en lugar de ser forzados a continuar trabajo que ya no tenía valor."

13. Eres Scrum Master de tres equipos simultáneamente. ¿Cómo gestionas tu tiempo y atención?

Lo que buscan los entrevistadores: Estrategia práctica de facilitación multi-equipo y priorización. Marco de respuesta: Reconoce el desafío — la Guía Scrum recomienda un equipo, pero la realidad organizacional suele ser diferente [12]. Describe tu estrategia: (1) Escalonar las cadencias de Sprint para que las ceremonias no se superpongan, (2) desarrollar líderes de facilitación dentro de cada equipo que puedan dirigir Daily Scrums y algunas sesiones de Refinement de forma independiente, (3) priorizar tu tiempo hacia el equipo con los impedimentos más urgentes o la menor madurez ágil, (4) usar temas de Retrospectiva compartidos para identificar problemas sistémicos entre equipos, (5) establecer canales de comunicación claros para que los equipos puedan plantear impedimentos de forma asíncrona en lugar de esperar tu disponibilidad diaria. "Dividí mi horario semanal en bloques: lunes y jueves estaban dedicados a las ceremonias del Equipo A, martes y viernes al Equipo B, y rotaba semanas con el Equipo C. Los tres equipos tenían un facilitador capacitado para los stand-ups diarios."

Preguntas de conceptos ágiles avanzados

14. ¿Cómo facilitarías la transición de una organización de Cascada a Scrum?

Lo que buscan los entrevistadores: Capacidad de gestión del cambio y expectativas realistas sobre la transformación ágil. Marco de respuesta: Comienza con un piloto — selecciona un equipo y un proyecto que tenga apoyo de los stakeholders y complejidad razonable. No intentes una transformación de golpe. Para el equipo piloto: (1) proporcionar capacitación en Scrum para el equipo y stakeholders clave, (2) establecer el marco Scrum con todos los eventos y artefactos, (3) establecer expectativas realistas — los primeros Sprints serán desordenados, (4) proteger al piloto de los anticuerpos organizacionales que resisten el cambio [13]. Escala demostrando resultados: cuando el equipo piloto muestre mejor predictibilidad de entrega y satisfacción de stakeholders, otros equipos pedirán adoptar el marco en lugar de ser forzados a hacerlo. Aborda los impedimentos organizacionales: los procesos de planificación de portafolio, los modelos de financiamiento, los sistemas de evaluación del desempeño y las estructuras de gobernanza necesitan adaptarse para apoyar equipos ágiles.

15. ¿Cuál es tu experiencia con marcos de escalamiento como SAFe, LeSS o Nexus? ¿Cuáles son sus ventajas y desventajas?

Lo que buscan los entrevistadores: Amplitud de conocimiento y perspectiva fundamentada y con opinión. Marco de respuesta: SAFe (Scaled Agile Framework) proporciona estructura integral para grandes empresas pero puede sentirse pesado y prescriptivo — los críticos lo llaman "Cascada disfrazada de Ágil" cuando se implementa sin cambio cultural [14]. LeSS (Large-Scale Scrum) se mantiene más cerca de los principios Scrum con estructura adicional mínima, pero requiere un compromiso organizacional fuerte y reestructuración significativa. Nexus se enfoca específicamente en 3-9 Equipos Scrum trabajando en un solo producto, agregando un Nexus Integration Team y una Definition of Done compartida [15]. Comparte tu experiencia real: qué marco has usado, qué funcionó y qué harías diferente. La mejor respuesta reconoce que ningún marco es una solución mágica — la cultura, el tamaño y la arquitectura del producto de la organización determinan qué enfoque de escalamiento encaja.

16. ¿Cómo manejas la deuda técnica dentro del marco Scrum?

Lo que buscan los entrevistadores: Balance entre la presión de entrega y la sostenibilidad a largo plazo. Marco de respuesta: La deuda técnica debe ser visible, no oculta. Conviértela en un ciudadano de primera clase en el Product Backlog cuantificando su impacto — no "refactorizar el módulo de autenticación" sino "el módulo de autenticación tiene 3x la tasa promedio de bugs y agrega 2 días a cada funcionalidad que toca la gestión de usuarios" [16]. Negocia con el Product Owner una asignación sostenible — muchos equipos usan una "regla del 20 %" donde el 20 % de la capacidad del Sprint se reserva para deuda técnica y mejoras de plataforma. Fortalece la Definition of Done para prevenir la acumulación de nueva deuda. Usa las Retrospectivas para sacar a la luz la deuda que está ralentizando al equipo. "Introduje una métrica de 'salud técnica' — la proporción de funcionalidades versus corrección de bugs y trabajo de mantenimiento por Sprint. Cuando caía por debajo de 60/40, lo tratábamos como una señal para aumentar nuestra asignación de reducción de deuda."

17. Un miembro del equipo dice que ya no ve valor en las Retrospectivas. ¿Cómo respondes?

Lo que buscan los entrevistadores: Creatividad en la facilitación y capacidad para revitalizar procesos estancados. Marco de respuesta: Toma el feedback en serio — si las Retrospectivas se sienten inútiles, el problema usualmente es facilitación repetitiva, acciones sin resolver, o ambos. Diagnostica primero: ¿Se rastrean y completan las acciones de Retrospectivas anteriores? Si no, esa es la causa raíz — el equipo ha aprendido que las Retrospectivas no conducen a cambios. Si la facilitación está estancada, introduce variedad: prueba formatos como "Velero" (viento, anclas, rocas, isla), "Empezar/Parar/Continuar", "Línea de tiempo" o Retrospectivas temáticas enfocadas en aspectos específicos como colaboración, herramientas o prácticas técnicas [17]. Pide al miembro desvinculado que co-facilite la próxima Retrospectiva — la apropiación crea compromiso. "Un miembro del equipo me dijo que las Retrospectivas eran 'solo sesiones de desahogo.' Implementé dos cambios: las acciones recibieron responsables y fechas límite rastreadas en nuestro tablero, y roté los deberes de facilitación. En dos Sprints, el miembro del equipo que se quejó se convirtió en uno de nuestros participantes más activos en las Retrospectivas."

Preguntas para hacer al entrevistador

Las preguntas reflexivas señalan profundidad e interés genuino:

1. "¿Cuántos equipos Scrum estaría apoyando y cuál es su nivel de madurez actual?" — Te ayuda a evaluar el alcance y el desafío del puesto.
2. "¿Cómo es el apoyo de coaching ágil más allá del rol de Scrum Master? ¿Hay un Centro de Excelencia Ágil o un equipo de coaching?" — Muestra que piensas en las estructuras de apoyo organizacional.
3. "¿Cuáles son los mayores impedimentos que enfrentan sus equipos y que no pueden resolver a nivel de equipo?" — Demuestra orientación de liderazgo servicial desde la primera conversación.
4. "¿Cómo ve el liderazgo el rol del Scrum Master — como facilitador, coach o coordinador de proyectos?" — Te ayuda a entender si la organización realmente quiere un Scrum Master o un PM rebautizado.

Lista de verificación de preparación

1. Vuelve a leer la Guía Scrum. La versión 2020 tiene 13 páginas. Conócela a fondo — los entrevistadores evaluarán si sabes lo que el marco realmente dice versus conceptos erróneos comunes [18].
2. Prepara tres historias STAR sólidas. Una sobre resolución de conflictos, una sobre eliminación de impedimentos y una sobre coaching de un equipo hacia mayor rendimiento. Cada una debe tener resultados cuantificados.
3. Conoce tus métricas. Prepárate para discutir tendencias específicas de velocidad, tasas de cumplimiento del Objetivo del Sprint y métricas de mejora de los equipos que has guiado.
4. Practica las preguntas situacionales en voz alta. Las preguntas situacionales requieren pensar sobre la marcha — ensayar tu enfoque diagnóstico lo hace natural.
5. Investiga la madurez ágil de la empresa. Revisa sus ofertas de trabajo, blog de ingeniería y reseñas en Glassdoor buscando señales sobre su cultura ágil.

Referencias

[1] Digital.ai, "17th Annual State of Agile Report," Digital.ai, 2023. [2] Schwaber, K. & Sutherland, J., "The Scrum Guide," ScrumGuides.org, 2020. [3] Scrum Alliance, "Scrum Master vs. Project Manager," Scrum Alliance Resources, 2024. [4] Scrum.org, "Definition of Done," Scrum.org Professional Resources, 2024. [5] Rubin, K., "Essential Scrum: A Practical Guide to the Most Popular Agile Process," Addison-Wesley, 2012. [6] Schwaber, K. & Sutherland, J., "The Scrum Guide — Scrum Events," ScrumGuides.org, 2020. [7] Cohn, M., "User Stories Applied: For Agile Software Development," Addison-Wesley, 2004. [8] Adkins, L., "Coaching Agile Teams," Addison-Wesley Professional, 2010. [9] Scrum.org, "Evidence-Based Management Guide," Scrum.org, 2024. [10] Derby, E. & Larsen, D., "Agile Retrospectives: Making Good Teams Great," Pragmatic Bookshelf, 2006. [11] Schwaber, K. & Sutherland, J., "The Scrum Guide — Sprint Cancellation," ScrumGuides.org, 2020. [12] Scrum.org, "Scrum Master Focus Areas," Scrum.org Professional Resources, 2024. [13] Kotter, J., "Leading Change," Harvard Business Review Press, 2012. [14] Scaled Agile, Inc., "SAFe 6.0 Framework," ScaledAgileFramework.com, 2024. [15] Scrum.org, "The Nexus Guide," Scrum.org, 2021. [16] Fowler, M., "Technical Debt," MartinFowler.com, 2019. [17] Retromat, "Retrospective Activities," Retromat.org, 2024. [18] Schwaber, K. & Sutherland, J., "The Scrum Guide," ScrumGuides.org, 2020.