eliga_7699

(*) El punto de vista ágil... No acepta cambios en un proyecto porque modifican las condiciones acordadas y retrasan la entrega del producto. Acepta que los cambios siempre mejoran un proyecto y que proporcionan un valor adicional al producto. El entregable no va incorporando características sucesivamente. El entregable se produce al final de todos los ciclos.

(*) El Manifiesto Agile fue escrito en el año 2001 y aglutinó los valores que tenían en común las distintas metodologías consideradas ágiles en ese momento. Da mayor importancia a la adaptación de los proyectos a los cambios introducidos durante su desarrollo. Promueve la eliminación de procesos, documentación y contratos para los proyectos. Busca la manera de hacer los proyectos sin comprometerse con ningún alcance u objetivo. Fue redactado por expertos agilistas representando a todos los sectores.

(*) ¿Qué enunciados describen mejor la responsabilidad del propietario del producto (PO)?. Asegurar que el trabajo cumpla con los compromisos con el CEO. Optimizar el valor del trabajo que realiza el equipo de desarrollo. Mantener a raya a los gerentes y partes interesadas. Dirección del equipo de desarrollo.

(*) ¿Cuál es el rol del Product Owner en la retro?. Liderar al equipo de desarrollo. No tiene que asistir a la retro. Ser un miembro más del equipo Scrum. Facilitar la retro.

(*) ¿Quién puede hacer cambios en el sprint backlog?. Los stakeholders. El Product Owner. El equipo de desarrollo. El Scrum Master.

(*) En Scrum, ¿quién es el equivalente al project manager?. El Product Owner. No tiene equivalente. El Scrum Master. Depende de la empresa.

(*) ¿Cómo debería hacer un Scrum Master para dividir a un grupo de 75 personas en múltiples equipos Scrum?. Pedir al mánager funcional que asigne las personas a los equipos. Pedir ayuda a un Scrum Master senior. Solicitar a los propietarios del producto (PO) que asignen las personas a los equipos. Pedir a los desarrolladores (ejecutadores de tareas) que se dividan en equipos.

(*) ¿Cuál es una de las principales ventajas de adoptar SCRUM para nuestros proyectos?. Es un conjunto de sistemas operacionales y metodología estándar e iguales para todos los equipos de la organización. Garantiza un organigrama en el que el Product Owner puede tomar decisiones sobre el proyecto para garantizar su éxito. Los equipos trabajan de forma colaborativa para la obtención de resultados óptimos en el desarrollo de nuevos productos o servicios. Podemos realizar los proyectos mucho más rápido que con las metodologías tradicionales o predictivas.

(*) En el product backlog, ¿dónde se situarán los elementos de mayor prioridad?. En la parte superior. Depende. En la parte inferior. Donde diga el Product Owner.

(*) ¿Cuáles de las siguientes afirmaciones pueden considerarse como principios del Manifiesto Agile?. Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor para el cliente. El software que funciona debe ser la principal medida de progreso. La gente de negocios y los desarrolladores tienen que trabajar juntos de forma diaria durante el desarrollo del proyecto. Todas son correctas.

(*) Las metodologías y marcos de trabajo como design thinking, Scrum y Lean... No son integrables ya que no guardan mucha relación entre sus orígenes. No permiten empoderar el rol proactivo del equipo. Son altamente integrables ya que guardan mucha relación entre sus orígenes. No aseguran que la metodología se ajuste a las circunstancias y requisitos de cada proyecto.

(*) El sprint backlog es…. … el plan del equipo de desarrollo para conseguir el objetivo del sprint. … el incremento. … el elemento del product backlog. … los objetivos del sprint.

(*) Cuando un elemento tiene estimación de esfuerzo-complejidad muy alta, lo mejor es…. … hablar con el Scrum master. … no hacer nada. … dividir el elemento en varios. … pedir al equipo que estime más bajo.

(*) ¿Quién realiza el seguimiento del trabajo-subtareas pendientes?. El equipo de desarrollo. El Scrum master. El product owner. Los stakeholders.

(*) ¿Qué es INVEST?. Una herramienta Lean. Otra forma de nombrar las “Historias de Usuario”. Una técnica para ayudar al equipo y Product Owner a definir las “Historias de Usuario”. Una herramienta para la gestión de cambios.

(*) ¿Qué beneficios tiene estimar por puntos de historia?. El equipo puede calcular las horas que le llevará hacer esa historia. El equipo estima de una forma sencilla el esfuerzo en relación con otras historias conocidas. Para calcular los puntos de historia, el equipo le suma un porcentaje por el tiempo perdido no dedicado a trabajo efectivo. Es una manera de limitar que sólo los expertos en cada materia puedan opinar sobre esas historias.

(*) ¿Qué tiene que haber en todos los sprints?. Tres entregas al cliente final. Una funcionalidad que esté lista para entregar a los clientes. Cinco sesiones de refinamiento. Una demo a los interesados.

(*) El propietario del producto (PO) no está colaborando con el equipo de desarrollo durante el sprint. ¿Qué debe hacer un Scrum master?. Informar al responsable funcional del propietario del producto. Nominar un PO Proxy. Coach al propietario del producto en los valores de Scrum. Sacar el problema en la review del sprint.

(*) ¿Qué es la cadena de valor?. El conjunto completo de actividades necesarias para producir un producto o servicio. El conjunto de procedimientos de toda la empresa. El conjunto completo de actividades que son automatizables. El conjunto completo de actividades que se incluyen en un sprint.

(*) ¿Cuánto tiempo pasa entre un sprint y el siguiente?. El necesario para refinar el product backlog. El que determinen el PO y el SM. Ninguno. Dos días.

(*) ¿Qué es la agilidad organizacional?. La capacidad de una organización para adaptarse rápidamente a los cambios del mercado. La capacidad de una organización para mantenerse fiel a sus procesos y estructuras tradicionales. La capacidad de una organización para reducir su tamaño y aumentar su eficiencia. La capacidad de una organización para reducir su complejidad interna.

(*) Sobre la serie de Fibonacci: (Elige la mejor respuesta). Se usa en Kanban. Tiene los valores 1, 2, 3, 4, 5, 8…. Tiene los valores 1, 2, 3, 5, 8, 13…. No sirve para estimar valor.

(*) El concepto de adaptación o tailoring... Es uno de los conceptos clave incluidos en el PMBoK. Es uno de los conceptos clave de las metodologías agile pero no está incluido en el PMBok. No es un concepto clave en el ámbito Agile porque no es necesario que la metodología se ajuste a las características de cada proyecto. No guarda relación con las metodologías Agile.

(*) Para consolidar el escalado del Scrum a nivel organizacional se debe tener en consideración: El ciclo de escalado del Scrum master. El ciclo de escalado de los stakeholders. El ciclo de escalado de los clientes. El ciclo de escalado de los programadores.

Según el Manifiesto Agile, ¿cuál de los siguientes es uno de sus cuatro valores fundamentales?. Individuos e interacciones sobre procesos y herramientas. Documentación exhaustiva sobre software funcionando. Seguir un plan sobre responder al cambio. Negociación de contratos sobre colaboración con el cliente.

¿Cómo define la UD1 el Design Thinking?. Un marco de trabajo exclusivo para diseñadores de productos digitales. Un método a partir del cual se pueden generar ideas innovadoras, centrado en entender y obtener la solución adecuada a las necesidades reales de los usuarios. Una metodología predictiva para la gestión de proyectos complejos. Una técnica de estimación ágil basada en la secuencia de Fibonacci.

Takeuchi y Nonaka definieron el llamado "enfoque rugby". ¿En qué consistía?. Un equipo trabaja secuencialmente, pasando el trabajo de especialista en especialista como en una carrera de relevos. Un equipo planifica exhaustivamente todas las fases antes de comenzar el desarrollo. Un equipo intenta llegar al final como una unidad, pasando el balón hacia atrás y adelante en lugar de hacerlo secuencialmente. Un equipo divide el proyecto en subproyectos independientes gestionados por distintos líderes.

¿En cuántas categorías se agrupan los doce principios del Manifiesto Agile según la UD1?. Dos categorías: entrega de valor y comunicación del equipo. Cuatro categorías, una por cada valor del Manifiesto. Tres categorías: entrega de software de forma regular, comunicación del equipo y excelencia en el diseño. No se agrupan en categorías; se presentan de forma independiente.

¿Quiénes redactaron el Manifiesto Agile según la UD1?. Ken Schwaber y Jeff Sutherland, creadores de Scrum. Peter Drucker y Frederick Taylor, pioneros de la gestión científica. Fowler y Highsmith, siendo suscrito por 17 miembros de la Alianza Ágil. Hirotaka Takeuchi e Ikujiro Nonaka, autores del enfoque rugby.

Según la comparativa Traditional PM vs. Agile de la UD1, en la aproximación ágil el rol del PM consiste en... Empoderar al equipo. Ejercer un rol de Command and Control. Monitorizar el plan del proyecto. Documentar exhaustivamente todos los procesos.

¿En qué año fue fundada oficialmente la metodología ágil según la UD1?. 1995, con la presentación de Scrum en Austin, Texas. Febrero de 2001, con la redacción del Manifiesto Agile. 1986, con el artículo de Takeuchi y Nonaka. 2010, con la popularización del tablero Kanban.

Según la UD1, ¿qué metodología ágil conocida también como XP se centra en fomentar la interacción permanente entre el cliente y el equipo, pero no es recomendable para proyectos de larga duración?. Extreme Programming. Feature Driven Development. Crystal Methods. Dynamic Systems Development Method.

Según la UD1, ¿qué palabra japonesa da nombre al Kanban y qué significa?. Es una palabra china que significa "tablero de tareas". No tiene origen japonés; es un acrónimo inglés. En japonés hace referencia a "panel visible" y básicamente es una forma de visualizar el trabajo que se está realizando. Significa "ciclo corto" y hace referencia a la duración de los sprints.

¿Cuáles son los tres pilares del marco SCRUM según la UD1?. Foco, coraje y compromiso. Planificación, ejecución y revisión. Transparencia, inspección y adaptación. Colaboración, comunicación y entrega continua.

¿Cuántos valores tiene el marco SCRUM según la UD1?. Tres: transparencia, inspección y adaptación. Cinco: foco, coraje, compromiso, respeto y apertura. Cuatro: los mismos que el Manifiesto Agile. Siete: uno por cada evento del marco de trabajo.

En el proceso adaptativo (ágil), según el diagrama de la UD1, ¿qué variable se mantiene fija y cuál varía?. El alcance es fijo y el coste varía. El cronograma es fijo y el coste varía. El coste y el cronograma son fijos y el alcance varía. El alcance y el coste son fijos y el cronograma varía.

Según la UD1, ¿cuándo fue presentado el concepto de SCRUM y su aplicabilidad al desarrollo de software?. En 2001, junto con la redacción del Manifiesto Agile. En 1986, en el artículo "The New New Product Development Game". En 1995, en un congreso de programación celebrado en Austin, Texas, por Ken Schwaber y Jeff Sutherland. En 2020, con la publicación de la nueva Guía Scrum.

¿Qué afirma el valor del Manifiesto Agile "Respuesta ante el cambio en lugar de seguir un plan"?. Que los cambios en un proyecto deben evitarse a toda costa para no poner en riesgo el presupuesto. Que los cambios siempre mejoran un proyecto y proporcionan un valor adicional al producto, por lo que todos deben estar preparados para realizarlos. Que el plan inicial del proyecto es la única guía válida durante todo el desarrollo. Que los cambios solo pueden introducirse al inicio de cada sprint, nunca durante su desarrollo.

Según la UD1, ¿en qué áreas es preferible usar Traditional PM frente a Agile Project Management?. Procesos generales, productos basados en especificaciones cerradas y gestión de la configuración. Desarrollo iterativo, definición de especificaciones del producto y prototipos. Desarrollo de productos, actividad diaria del equipo y desarrollo de diseño de productos o servicios. Gestión del riesgo, comunicación verbal y funcionalidades negociables.

¿Cuáles son los tres roles principales en un equipo Scrum según la UD2?. Project Manager, analista de negocio y equipo técnico. Patrocinador, director de proyecto y equipo de desarrollo. Product Owner, Scrum Master y equipo de desarrollo. Product Owner, Scrum Master y stakeholders.

¿Cuál es la principal responsabilidad del Product Owner según la UD2?. Definir el trabajo y priorizar las tareas correspondientes en el proyecto a través del product backlog. Garantizar que el equipo Scrum trabaje de acuerdo con las reglas de la metodología. Desarrollar las funcionalidades del producto durante cada sprint. Eliminar los impedimentos que encuentre el equipo durante el sprint.

Según la UD2, ¿cómo consigue el Scrum Master que el equipo trabaje de forma más eficiente?. Asignando tareas específicas a cada miembro del equipo al inicio del sprint. Controlando el cumplimiento del plan de proyecto y el presupuesto. Eliminando impedimentos, facilitando reuniones, enseñando al equipo a autogestionarse y trabajando con el PO para mantener el backlog preparado. Definiendo el alcance del proyecto y negociando los requisitos con el cliente.

Según la UD2, ¿cuál es el tamaño óptimo del equipo de desarrollo en Scrum?. Entre uno y cinco miembros, sin contar al PO ni al SM. Entre tres y nueve personas, sin contar al Product Owner ni al Scrum Master. Entre cinco y quince personas, incluyendo todos los roles. No existe un tamaño definido; depende del proyecto.

¿Cuál es la diferencia fundamental entre el Scrum Master y el Project Manager según la UD2?. El Scrum Master gestiona el presupuesto; el Project Manager gestiona el equipo. El Project Manager facilita las reuniones; el Scrum Master define el alcance. En Scrum la responsabilidad del éxito es compartida por todo el equipo; el SM actúa como facilitador en lugar del PM, cuya responsabilidad recae en el éxito o fracaso del proyecto. No existe diferencia real entre ambos roles; son intercambiables.

Según la UD2, ¿cuál de las siguientes es una característica del equipo de desarrollo en Scrum?. Está dirigido jerárquicamente por el Scrum Master, quien indica cómo convertir los elementos del backlog en incrementos. Está dividido en subequipos especializados según las áreas del proyecto. Solo los expertos en cada área pueden opinar sobre las historias de su especialidad. Es autoorganizado, multifuncional y comparte la responsabilidad colectiva del éxito del proyecto.

¿Qué son los stakeholders en el contexto de Scrum según la UD2?. Miembros del equipo de desarrollo con habilidades especializadas. Roles auxiliares sin rol formal que deben ser tomados en cuenta; expertos del negocio e interesados cuyo aporte es la retroalimentación para revisar y planear cada sprint. Un segundo equipo de desarrollo que trabaja en paralelo al principal. Sinónimo de Product Owner en la Guía Scrum 2020.

¿Qué novedad introdujo la Guía Scrum 2020 respecto a los equipos según la UD2?. Los equipos pasan de ser autoorganizados a ser autogestionados, con más independencia y poder de decisión sobre qué se debe trabajar, quién lo va a trabajar y cómo se tendrá listo. El Product Owner pasa a tener autoridad directa sobre el equipo de desarrollo. Se incorpora un cuarto rol: el agile coach, responsable de la mejora continua. Los sprints pasan a tener una duración fija de dos semanas en todos los casos.

Según la UD2, ¿qué papel adopta el Scrum Master en la nueva Guía Scrum 2020?. Pasa a ser responsable directo de la entrega del producto al cliente. Toma decisiones sobre el backlog junto al Product Owner. Se denomina "líder que sirve" (servant leadership): lidera y aconseja a la organización en su adaptación a las prácticas de Scrum y mejora de forma continua el desarrollo del marco de trabajo. Se convierte en el único responsable del éxito o fracaso del sprint.

Según la UD2, una de las ventajas de adoptar Scrum en los proyectos es que... Garantiza terminar los proyectos más rápido que con cualquier metodología tradicional. Elimina la necesidad de comunicación entre el equipo y el cliente durante el desarrollo. Aumenta la capacidad de reacción ante cambios repentinos, reduce el tiempo de lanzamiento al mercado y maximiza el ROI. Fija los requisitos al inicio del proyecto para evitar cambios durante el desarrollo.

¿Qué tres grandes elementos tiene la estructura de Scrum según la UD2?. Roles, sprints y reuniones diarias. El equipo Scrum, los eventos Scrum y los artefactos Scrum. El Product Owner, el Scrum Master y el product backlog. La planificación, la ejecución y la retrospectiva.

Según la UD2, ¿qué ocurre si el equipo de desarrollo supera las nueve personas?. El Scrum Master debe abandonar el equipo para mantener el número correcto. Se debe incorporar un segundo Product Owner para gestionar la carga de trabajo. El Product Owner asume las tareas de desarrollo para equilibrar el equipo. Se debe reconsiderar la estrategia para dividir en más equipos.

En la Guía Scrum 2020, ¿qué responsabilidades (accountabilities) se asignan al Product Owner según la UD2?. Representa la voz del cliente, fija la visión y la meta del producto, y establece las prioridades y las relaciones con las demás tareas. Aporta el conocimiento y la capacidad, responde por la calidad del producto y se autogestiona. Lidera y sirve a todo el equipo y a la organización, y mejora de forma continua el desarrollo del marco de trabajo. Define el alcance técnico del sprint y programa las reuniones diarias.

¿Qué se afirma en la UD2 sobre el Product Owner respecto a la priorización del backlog?. El Product Owner delega la priorización completamente en el equipo de desarrollo. El Product Owner fija las prioridades sin necesidad de escuchar al equipo. El Product Owner tiene la última palabra en la priorización, pero debe escuchar las recomendaciones del equipo Scrum para obtener el mejor resultado. La priorización la determina el Scrum Master en coordinación con los stakeholders.

Según la UD2, ¿cuándo fue presentada la nueva versión de La guía Scrum 2020?. En enero de 2020, al inicio de ese año. El 18 de noviembre de 2020, por Ken Schwaber y Jeff Sutherland. En febrero de 2021, coincidiendo con el 20 aniversario del Manifiesto Agile. En diciembre de 2019, como anticipo al año siguiente.

¿Cuántos eventos posibles existen dentro del marco Scrum según la UD3?. Tres: sprint, sprint planning y sprint retrospective. Cuatro: sprint, daily meeting, sprint review y sprint retrospective. Cinco: el sprint, la reunión de planificación, el scrum diario, la revisión del sprint y la retrospectiva del sprint. Seis: los cinco anteriores más el refinamiento del backlog.

Según la UD3, ¿cuál es la duración máxima recomendada de un sprint?. Dos semanas como máximo. Dos a cuatro meses dependiendo de la complejidad. Aproximadamente un mes como máximo, con un promedio de dos o tres semanas. Una semana exactamente para maximizar la agilidad.

¿Quién tiene la autoridad para cancelar un sprint según la UD3?. El Scrum Master, al ser el responsable del proceso. Solo el Product Owner tiene la autoridad para cancelarlo, aunque los interesados, el equipo y el SM pueden influir. El equipo de desarrollo, por votación mayoritaria. Cualquier miembro del equipo Scrum si el sprint queda obsoleto.

¿Qué es el Sprint Planning según la UD3?. Una reunión informal diaria de 15 minutos para sincronizar al equipo. La reunión final del sprint en la que se presenta el incremento a los stakeholders. La reunión donde se planifica el qué y el cómo del sprint, se define el sprint goal, y tiene una duración máxima de ocho horas para sprints de un mes. Una reunión semanal de seguimiento del project manager con el cliente.

Según la UD3, el Daily Scrum tiene una duración máxima de... Quince minutos, preferiblemente de pie, con todo el equipo de desarrollo. Treinta minutos, sentados, con todos los miembros del equipo Scrum incluyendo el PO. Una hora, con agenda fija definida por el Scrum Master. El tiempo que el equipo considere necesario cada día.

¿Cuáles son las tres preguntas que responde cada miembro del equipo en el Daily Scrum según la UD3?. ¿Qué hice esta semana? ¿Qué haré la próxima semana? ¿Hay algún riesgo en el proyecto?. ¿Cuántas horas he trabajado? ¿Cuántas me quedan? ¿Necesito ayuda?. ¿Qué hice ayer para lograr el objetivo del sprint? ¿Qué haré hoy? ¿Veo algún impedimento que evite lograrlo?. ¿Qué tareas están en curso? ¿Cuáles están bloqueadas? ¿Cuáles están terminadas?.

Según la UD3, ¿cuál es la principal diferencia entre la Sprint Review y la Sprint Retrospective?. La review la lidera el PO y la retrospectiva la lidera el SM. La review trata sobre el presupuesto y la retrospectiva sobre el alcance. La review es obligatoria y la retrospectiva es opcional. En la review se mira lo que el equipo está construyendo; en la retrospectiva se pone más énfasis en cómo lo están construyendo.

Según la UD3, ¿quién lidera la sprint retrospective?. El Scrum Master. El Product Owner. El equipo de desarrollo por rotación. Un facilitador externo al equipo.

¿Qué es el Product Backlog según la UD3?. La lista de tareas que completará el equipo durante un sprint concreto. Un listado de funcionalidades priorizadas que siempre está vivo, crece y cambia a lo largo de la vida del proyecto; su responsable es el Product Owner. El registro de impedimentos que bloquean al equipo durante el sprint. El documento formal de alcance del proyecto aprobado por el patrocinador.

Según la UD3, durante la realización de un sprint, ¿qué NO se puede hacer?. Realizar modificaciones que pongan en peligro el objetivo del sprint ni disminuir los objetivos de calidad. Renegociar el alcance con el dueño del producto si se descubren nuevas condiciones. Actualizar el sprint backlog con nuevas tareas identificadas por el equipo. Mantener reuniones con los stakeholders para informar del progreso.

¿Qué novedad introdujo la Guía Scrum 2020 en el evento Sprint Planning según la UD3?. Redujo su duración máxima a cuatro horas para todos los sprints. Eliminó el segundo tópico (el cómo) para simplificar el evento. Estableció que solo el Product Owner puede proponer elementos para el sprint. Incorporó un tercer tópico al evento: el porqué, que genera un contexto asociado al sprint goal para explicar el valor del sprint a los interesados.

Según la UD3, ¿qué ocurre con los elementos del backlog cuando se cancela un sprint?. Todos los elementos se descartan y se comienza el siguiente sprint desde cero. Los elementos terminados (done) pueden ser aceptados por el PO y puestos a disposición del cliente; el resto vuelve a la pila del producto para reevaluar su prioridad. El equipo decide qué elementos se conservan y cuáles se eliminan. El Scrum Master determina qué se entrega y qué se devuelve al backlog.

Según la UD3, ¿cuál es el objetivo principal de la Sprint Review?. Identificar mejoras en los procesos de trabajo del equipo para el siguiente sprint. Definir las tareas que se realizarán en el siguiente sprint. Inspeccionar el incremento y adaptar la lista de producto si fuese necesario, facilitando retroalimentación entre el equipo Scrum y los interesados. Evaluar el desempeño individual de cada miembro del equipo.

¿Qué se afirma en la UD3 sobre el Sprint Goal?. Se utiliza para informar a los stakeholders sobre el progreso del sprint y lo que está trabajando el equipo, siendo establecido durante el sprint planning. Es un documento formal que reemplaza al sprint backlog en la nueva Guía Scrum 2020. Solo puede ser modificado por el Product Owner con el consentimiento de los stakeholders. Es idéntico al Product Goal y no debe confundirse con el objetivo del sprint.

Según la UD3, ¿cuál es el propietario del Impediment Backlog?. El Product Owner. El equipo de desarrollo. Los stakeholders del proyecto. El Scrum Master.

¿Cuáles son los cuatro artefactos que componen el framework Scrum según la UD4?. Sprint backlog, historias de usuario, épicas y criterios de aceptación. Product Backlog, Sprint Backlog, Impediment Backlog e Incremento. Product Backlog, Sprint Backlog, Definition of Done e Incremento. Burndown chart, tablero Kanban, Jira y Active Collab.

Según la UD4, ¿qué son las épicas en el contexto del Product Backlog?. Historias de usuario de muy baja prioridad que se dejan para el final del proyecto. Requisitos técnicos que solo pueden ser estimados por el equipo de desarrollo. Historias de usuario muy grandes que no pueden finalizarse en un sprint, por lo que necesitan descomponerse en historias de usuario más pequeñas. Documentos formales de especificación de requisitos aprobados por el cliente.

¿Quién es el responsable del Product Backlog según la UD4?. El Product Owner, quien lo organiza, prioriza y da a entender al resto del equipo. El Scrum Master, quien garantiza que esté actualizado en todo momento. El equipo de desarrollo, quien lo alimenta con las tareas técnicas necesarias. Los stakeholders, quienes definen los requisitos que deben incluirse.

Según la UD4, ¿qué es la Definition of Done (DoD)?. Un documento formal aprobado por el cliente al inicio del proyecto. Una lista de tareas pendientes del sprint que aún no han sido completadas. El conjunto de condiciones, parámetros y reglas explícitas que cada equipo Scrum define para decidir cuándo algo está realmente terminado; es uniforme para todos los miembros del equipo. El criterio que usa el Product Owner para decidir qué funcionalidades se liberan al cliente.

¿Qué es el Sprint Backlog según la UD4?. La lista completa de funcionalidades deseadas en el producto final, ordenada por prioridad. El plan del equipo de desarrollo para conseguir el objetivo del sprint; contiene las tareas derivadas del Product Backlog seleccionadas para la iteración. El registro de todos los impedimentos identificados durante el sprint. La suma de todos los trabajos completados al finalizar la iteración.

Según la UD4, ¿qué es el Incremento?. La diferencia entre el Product Backlog al inicio y al final de un sprint. El conjunto de tareas del sprint que no han podido completarse. La suma de todos los elementos de la lista de producto completados durante un sprint y el valor de los incrementos de todos los sprints anteriores; debe ser funcional aunque el cliente decida no liberarlo. El documento de entrega formal que el Product Owner presenta a los stakeholders en la Sprint Review.

¿Para qué sirve el burn-down chart según la UD4?. Para visualizar la cantidad de trabajo pendiente y compararla con el rendimiento de trabajo ideal estimado en la planificación. Para registrar las horas trabajadas por cada miembro del equipo durante el sprint. Para mostrar el historial de sprints completados y la velocidad media del equipo. Para planificar el product backlog ordenando los elementos por prioridad.

Según la UD4, ¿qué herramienta de gestión ágil es una de las más extendidas en el mundo y es desarrollada por Atlassian?. Active Collab, que integra tableros Kanban y gestión de tareas. Pivotal Tracker, orientado específicamente a proyectos de software ágil. Jira, que ofrece Scrum, Kanban y se integra con Confluence y otros productos Atlassian. Trello, diseñado exclusivamente para equipos que usan metodologías ágiles.

¿Qué novedad introdujo la Guía Scrum 2020 para los artefactos según la UD4?. Eliminó el Impediment Backlog y lo integró dentro del Sprint Backlog. Asoció compromisos a cada artefacto: el Product Backlog tiene el Product Goal, el Sprint Backlog tiene el Sprint Goal y el Incremento tiene el Definition of Done. Añadió el Kanban board como cuarto artefacto oficial de Scrum. Sustituyó el Sprint Backlog por una lista de tareas gestionada exclusivamente por el Scrum Master.

Según la UD4, ¿qué dice la nota sobre el burn-down chart respecto a qué se considera en él?. Se consideran todas las tareas registradas en el sprint backlog, independientemente de su estado. Se consideran únicamente las tareas asignadas a los miembros más experimentados del equipo. Solo se consideran las unidades o puntos de historia una vez que hayan alcanzado correctamente el estado de done. Se incluyen las estimaciones iniciales y se actualiza semanalmente con las desviaciones.

¿Qué afirma la UD4 sobre el Product Goal en la nueva Guía Scrum 2020?. Sustituye al sprint goal y elimina la necesidad de objetivos por iteración. Es un concepto ya existente en versiones anteriores de la Guía Scrum. Lo establece el Scrum Master en coordinación con el equipo de desarrollo. Es un nuevo concepto dentro de la guía que sirve al equipo Scrum para fijar el curso y entender cuál será el futuro del producto.

Según la UD4, ¿quién tiene la última palabra sobre si una funcionalidad terminada se pone a disposición del cliente?. El Product Owner, sin importar si la funcionalidad está done o no; el incremento debe estar en condiciones de utilizarse independientemente de que el PO decida liberarlo. El Scrum Master, quien valida el cumplimiento de la Definition of Done. El cliente directamente, tras inspeccionar el incremento en la Sprint Review. El equipo de desarrollo, que determina si el trabajo cumple los criterios de calidad.

Según la UD4, ¿qué tipos de elementos pueden formar parte del Product Backlog?. Solo historias de usuario y tareas técnicas. Únicamente bugs y nuevas funcionalidades del producto. Funcionalidades (historias de usuario), bugs, épicas y trabajo de investigación o adquisición de conocimientos. Exclusivamente sprints y sus tareas asociadas.

Según la UD4, una vez que el sprint se ha empezado, ¿qué es lo más importante para el Scrum Master?. Actualizar el burn-down chart diariamente para informar a los stakeholders. Eliminar los impedimentos del Impediment Backlog. Asegurarse de que el equipo cumple las horas estimadas de trabajo. Preparar el product backlog para el siguiente sprint junto al Product Owner.

¿Qué se afirma en la UD4 sobre la Definition of Done cuando existen varios equipos Scrum colaborando?. Cada equipo puede tener su propia DoD para respetar su autonomía. La DoD la define únicamente el Product Owner central del proyecto. El Scrum Master de cada equipo negocia su propia DoD con los demás Scrum Masters. Se debe establecer una Definition of Done común e integrada con todos los equipos.

Según la UD5, ¿qué es el Agile Inception Deck?. Un documento formal de apertura de proyecto equivalente al acta de constitución en metodologías ágiles. Una técnica de estimación basada en la experiencia del equipo. Una herramienta de primer acercamiento a la planificación de un proyecto ágil a través de ejercicios colaborativos para desarrollar la visión general o big picture del proyecto. Un tablero Kanban especializado para la gestión del product backlog.

¿Quién describió la herramienta Agile Inception Deck en su libro "The agile samurai" según la UD5?. Mike Cohn, en su libro "Agile estimation and planning". Jonathan Rasmusson, en "The agile samurai: How agile masters deliver great software". Ken Schwaber, en la Guía Scrum 2020. Jeff Sutherland, creador del framework Scrum.

Según la UD5, ¿cuántos pasos o procesos orientativos tiene el Agile Inception Deck?. Cinco pasos centrados en la visión del producto. Siete pasos orientados al equipo y al cliente. Ocho pasos que van desde la misión hasta la estimación del tamaño. Diez pasos que van desde "¿Por qué estamos aquí?" hasta "Muestra las necesidades del proyecto".

Según la UD5, ¿qué son las historias de usuario o user stories?. La manera en que el equipo registra cada funcionalidad solicitada por el cliente, siguiendo el acrónimo INVEST. Documentos técnicos de especificación redactados por el equipo de desarrollo. Listados de bugs encontrados durante las pruebas del producto. Reuniones de equipo donde se narran los avances del sprint.

¿Qué significa la "V" en el acrónimo INVEST de las historias de usuario según la UD5?. Verificable: que pueda comprobarse que la historia ha sido completada. Visual: que la historia incluya mockups o prototipos visuales. Valuable: que aporte valor al negocio y al proyecto por sí misma. Versátil: que pueda adaptarse a distintos contextos de uso.

Según la UD5, ¿qué son las épicas en el contexto de las historias de usuario?. Historias de usuario de muy baja complejidad que pueden completarse en pocas horas. Historias de usuario demasiado grandes para desarrollarse en un solo sprint, que deben descomponerse en varias historias más pequeñas. Temas agrupados que comparten un denominador o una temática común. Criterios de aceptación definidos por el cliente para validar el producto.

¿Qué son los temas (themes) en el contexto de las historias de usuario según la UD5?. Nombres alternativos para los sprints en metodologías ágiles. Historias de usuario que han sido canceladas durante el desarrollo del proyecto. Documentos de especificación técnica redactados por el Product Owner. Un conjunto de historias de usuario con un denominador o una temática común.

Según la UD5, ¿en qué dos unidades básicas se realizan las estimaciones en agile, diferentes a las de proyectos predictivos?. Horas y días laborables. Semanas y meses de trabajo. Puntos de historia (story points) y días ideales. Puntos de función y puntos de caso de uso.

¿Qué son los puntos de historia (story points) según la UD5?. El número de horas que tardará el equipo en completar una historia de usuario. Una unidad relativa de tamaño que expresa la medida relativa de una historia de usuario, funcionalidad o tarea de trabajo en relación con otras ya conocidas. La cantidad de bugs identificados en una historia de usuario. El coste económico asociado al desarrollo de una funcionalidad concreta.

¿Qué es el Planning Poker según la UD5?. Una técnica para priorizar el product backlog basada en el valor de negocio de cada historia. Una dinámica de equipo para distribuir las tareas del sprint entre los miembros. La mejor herramienta para estimar en entornos ágiles, mitad juego mitad dinámica grupal; definida por Grenning (2002) y popularizada por Mike Cohn, combina opinión de experto, analogía y disgregación. Un método para calcular la velocidad media del equipo a lo largo de los sprints.

Según la UD5, ¿por qué el Planning Poker usa la serie de Fibonacci?. Porque fue diseñado específicamente para proyectos de software y la Fibonacci es el estándar del sector. Porque los valores al principio de la serie no implican demasiada diferencia entre sí, aumentando la diferencia a medida que los valores crecen; así se es consciente del principio de disgregación. Porque permite calcular con mayor precisión las horas de trabajo de cada historia. Porque fue recomendada por la Guía Scrum 2020 como técnica oficial de estimación.

Según la UD5, ¿cuáles son los cuatro factores de priorización de las historias de usuario en entornos ágiles?. Urgencia, impacto, esfuerzo y dependencia técnica. Plazo de entrega, coste, número de usuarios afectados y complejidad técnica. Popularidad, satisfacción del cliente, velocidad del equipo y presupuesto disponible. Valor financiero o de negocio, coste del trabajo asociado, conocimiento adquirido en su desarrollo y riesgo que eliminamos al completarla.

Según la UD5, ¿qué se debe hacer con historias que aportan gran valor al proyecto pero su ejecución conlleva mucho riesgo?. Hacerlas en primer lugar. Hacerlas en segundo lugar, después de las que aportan alto valor y eliminan gran riesgo. Dejarlas para el final del proyecto. Evitar hacer estas historias definitivamente.

Según la UD5, ¿qué se debe hacer con historias sin valor y cuya ejecución conlleva mucho riesgo?. Hacerlas primero para eliminar el riesgo cuanto antes. Hacerlas en segundo lugar, después de las historias de alto valor. Dejarlas para el final del proyecto. Evitar hacer estas historias.

Según la UD5, ¿cuál es la principal ventaja del Planning Poker como método de estimación?. Permite que solo los expertos en cada área puedan estimar las historias de su especialidad. Garantiza que las estimaciones sean exactas y no requieran revisión posterior. Es muy rápido y sencillo de implementar; evita que los expertos impongan su criterio y que las personas más influyentes o vagas vean su opinión fuera del consenso, gracias a la votación semioculta simultánea. Utiliza inteligencia artificial para calcular automáticamente la complejidad de cada historia.

Según la UD5, ¿qué representa el "cono de incertidumbre" en la planificación ágil?. La curva de aprendizaje del equipo a lo largo de los sprints del proyecto. El orden de magnitud en la planificación inicial o en la definición del producto, estimado entre +75%/-25%, que se va reduciendo a medida que avanza el proyecto. La variación permitida en el presupuesto del proyecto según la metodología ágil. El número máximo de historias de usuario que puede contener el product backlog.

Según la UD5, ¿cuál es la diferencia entre una estimación y un compromiso según la definición de la UD?. Una estimación es siempre más precisa que un compromiso. Un compromiso equivale siempre a una fecha concreta y una cantidad fija de dinero. Una estimación es la probabilidad de que algo ocurra de acuerdo con unos valores; no es una fecha concreta ni una cantidad fija, por lo que el compromiso no puede definirse en términos de probabilidad. No existe diferencia; en agile estimación y compromiso son sinónimos.

Según la UD5, ¿qué es el User Story Mapping?. Un documento de requisitos que sustituye al product backlog en proyectos complejos. Una técnica para calcular los puntos de historia de cada user story de forma visual. Un método de estimación equivalente al Planning Poker pero orientado a épicas. Una herramienta para tener una visión global del proyecto y no perder el horizonte de lo que se debe realizar, asegurando que todo el equipo esté en la misma página durante la ejecución.

Según la UD5, ¿para quién están pensadas las dinámicas del Agile Inception Deck?. Para ser desarrolladas por el equipo de proyecto, el patrocinador (representado por el Product Owner) y un facilitador, normalmente un Scrum Master. Exclusivamente para el Product Owner y los stakeholders principales del proyecto. Para el cliente y el equipo comercial, sin necesidad de incluir al equipo técnico. Solo para proyectos de desarrollo de software; no es aplicable a otros sectores.

Según la UD5, ¿a qué se refiere el principio ALAP mencionado en el apartado de priorización por coste?. Significa "A Lo Antes Posible", equivalente al principio ASAP. Es un acrónimo para "Agile Lean Adaptation Process", un marco de trabajo híbrido. Significa "As Late As Possible": hacer las cosas lo más tarde posible para reducir el sobrecoste entre la estimación inicial y el coste final, completando el trabajo cuando ya no quede tiempo para introducir cambios. Hace referencia a un método de priorización basado en el impacto al cliente final.

¿Qué es el tailoring o adaptación según la UD6?. Un proceso de selección de la metodología ágil más adecuada entre Scrum, Kanban y XP. Determinar la combinación adecuada de procesos, entradas, herramientas, técnicas, salidas y fases del ciclo de vida para dirigir un proyecto; es un concepto clave incluido en la sexta edición del PMBoK. La capacidad del equipo para adaptar su velocidad en función de la carga de trabajo de cada sprint. El proceso de incorporar nuevos miembros al equipo Scrum de forma gradual.

Según la UD6, ¿cuáles son las dos ramas que componen la transformación ágil de una organización?. Cultura organizacional y gestión del cambio. Mejora continua y entrega de valor al cliente. Agilidad técnica y agilidad organizacional. Escalado de Scrum y adopción de DevOps.

¿En qué tres vertientes se puede resumir la agilidad técnica según la UD6?. Velocidad, calidad y automatización. Planificación, ejecución y retrospección. Gestión de riesgos, documentación y entrega continua. Autonomía, conocimientos y tecnología.

Según la UD6, ¿cuáles son los tres componentes de la agilidad organizacional?. Cultura, mejora continua y procesos (cadena de valor). Autonomía, conocimientos y tecnología. Liderazgo, comunicación y gestión del cambio. Sprint planning, retrospectiva y daily meeting.

¿Qué es el escalado de Scrum (Scrum@Scale) según la UD6?. Un proceso para reducir el tamaño de los equipos Scrum cuando son demasiado grandes. Una metodología alternativa a Scrum para proyectos de muy baja complejidad. La adaptación y aplicación de los valores, principios y prácticas de Scrum a un contexto más grande o complejo que involucra a múltiples equipos o a una organización entera, desarrollado por Jeff Sutherland. Un software de gestión de proyectos ágiles diseñado para grandes corporaciones.

Según la UD6, ¿cuáles son los dos propósitos principales del escalado de Scrum?. Reducir costes y aumentar la velocidad de entrega. Escalado lineal (correspondencia entre cantidad de producto a entregar y equipo requerido) y agilidad del negocio (capacidad de adaptación a cambios repentinos del mercado). Coordinación entre equipos y eliminación de dependencias técnicas. Mejorar la calidad del producto y reducir el número de bugs.

¿Quién diseñó y definió el marco Scrum@Scale según la UD6?. Ken Schwaber, coautor de la Guía Scrum. Mike Cohn, autor de "Agile estimation and planning". Jonathan Rasmusson, autor de "The agile samurai". Jeff Sutherland, uno de los creadores de Scrum.

Según la UD6, ¿qué es el chief Product Owner en el contexto del escalado de Scrum?. El Product Owner escalado: encargado del backlog que gestiona la visión general e integra los backlogs individuales de cada equipo. El Product Owner con más experiencia que coordina a los demás Product Owners. Un rol equivalente al Scrum Master en el marco escalado de Scrum. El representante del cliente en la organización, sin responsabilidades sobre el backlog.

¿Qué es el Scrum de Scrum Master (SoSM) según la UD6?. Un Scrum Master con más de cinco años de experiencia certificado para gestionar equipos grandes. El responsable de la entrega de valor conjunta y de la mejora continua en el Scrum de Scrum; coordina el "cómo" e identifica impedimentos y dependencias entre equipos. El facilitador de las reuniones de sprint planning en el marco escalado. El equivalente al Product Owner en el nivel de escalado de la organización.

Según la UD6, ¿cuáles son los tres factores de complejidad que caracterizan la complejidad del proyecto?. Tamaño del equipo, presupuesto disponible y plazo de entrega. Número de sprints, velocidad del equipo y tamaño del backlog. El comportamiento humano como factor de complejidad, el comportamiento del sistema y el desarrollo del proyecto, y la ambigüedad o falta de claridad en el proyecto. Tecnología utilizada, número de stakeholders y alcance del producto.

Según la UD6, ¿qué aspecto describe mejor la agilidad organizacional?. La capacidad de los equipos técnicos para adoptar nuevas herramientas de desarrollo. La velocidad con la que una organización completa sus sprints de desarrollo. La reducción del número de procesos y burocracia dentro de la organización. La capacidad de una organización para adaptarse rápidamente a los cambios del mercado, basada en cultura, mejora continua y procesos de cadena de valor.

Según la UD6, ¿qué se necesita para el "qué" en el escalado de Scrum@Scale?. Una versión escalada de los eventos de planificación y revisión del sprint, con un refinamiento del backlog que reúne a todos los equipos; conducido por el chief Product Owner con los Scrum Masters. El escalado de la daily meeting y la retrospectiva, conducidos por el Scrum de Scrum Master. Una reunión mensual de todos los equipos para alinear las prioridades del producto. La revisión técnica de las dependencias entre equipos realizada por los desarrolladores.

Según la UD6, ¿qué implica la agilidad técnica en términos de autonomía?. Que el Scrum Master toma todas las decisiones técnicas para garantizar la coherencia del producto. Que los desarrolladores pueden trabajar desde casa sin necesidad de coordinarse con el resto del equipo. La capacidad de los equipos de desarrollo para tomar decisiones y ser responsables de su trabajo sin la necesidad de una supervisión constante, fomentando la toma de decisiones descentralizada. Que el Product Owner puede modificar el sprint backlog sin consultar al equipo de desarrollo.

¿Cuál es el objetivo principal del escalado de Scrum según la UD6?. Reducir el número de equipos Scrum necesarios para completar un proyecto grande. Mantener la flexibilidad y la agilidad de Scrum mientras se ajusta a las necesidades de un entorno más grande y complejo, aplicando prácticas ágiles a un equipo de equipos, un programa o una organización entera. Eliminar la necesidad del Product Owner al escalar a nivel organizacional. Estandarizar los procesos de todos los equipos para garantizar la uniformidad.

Según la UD6, ¿qué afirmación es correcta sobre la transformación ágil de las organizaciones?. Es un proceso sencillo que se logra simplemente adoptando Scrum en todos los equipos. La agilidad organizacional se adquiere únicamente mediante la formación técnica de los empleados. La complejidad es uno de los factores más importantes al consolidar la transición ágil; el comportamiento humano, el del sistema y la ambigüedad hacen difícil consolidar esa agilidad aunque sea fácil decir que la organización debe ser ágil. Una vez adoptada la metodología ágil, la organización no necesita adaptaciones posteriores.

(-) El Product Owner debe actuar como "protector" del equipo de desarrollo. Según la UD2, ¿en qué consiste exactamente ese rol de protección?. En evitar que el equipo reciba feedback negativo de los stakeholders durante el sprint. En tomar decisiones técnicas en nombre del equipo para evitar distracciones. En que managers de otras áreas no puedan pedirle tareas directamente al equipo sin pasar por su filtro, para evitar solicitudes no prioritarias que hagan perder el foco del sprint. En garantizar que ningún miembro del equipo trabaje más horas de las estipuladas.

(-) Según la UD2, ¿cuál de las siguientes afirmaciones sobre el equipo de desarrollo es INCORRECTA?. Es autoorganizado: el equipo es responsable de llevar a cabo su trabajo y de cómo lo realizan. Todos los miembros se consideran en la misma posición: son todos desarrolladores independientemente del trabajo que realicen. Es multifuncional: dispone de las habilidades adecuadas sin depender de agentes externos. Puede dividirse en subequipos especializados si se necesitan dominios particulares como pruebas o análisis de negocio.

(-) En la UD2 se compara la dinámica del equipo Scrum con la jugada del rugby llamada "melé". ¿Qué implica esta analogía respecto al funcionamiento del equipo?. Que cada miembro del equipo trabaja de forma independiente en su especialidad, como en una carrera de relevos. Que todos los roles ponen su trabajo al servicio del resto del equipo para obtener el mismo objetivo; si un miembro falla, el conjunto se resiente, por lo que deben estar coordinados y apoyarse mutuamente. Que el Scrum Master dirige al equipo como un entrenador que da instrucciones desde fuera del campo. Que el Product Owner es el capitán que toma todas las decisiones estratégicas durante el sprint.

(-) Según la UD2, ¿cuál de las siguientes NO es una tarea del Scrum Master según la tabla comparativa con el Project Manager?. Definir el alcance del proyecto al equipo y preparar el horario de trabajo para sus miembros. Planificación del sprint y programación de la reunión diaria de Scrum. Eliminar barreras para que el equipo pueda centrarse en su trabajo. Cooperar con el Product Owner en el diseño de los elementos del product backlog para el próximo sprint.

(-) Según la UD2, ¿cuál de las siguientes responsabilidades corresponde a los Desarrolladores en la nueva Guía Scrum 2020?. Representan la voz del cliente y fijan la visión y la meta del producto. Lideran y aconsejan a la organización en su adaptación a las prácticas de Scrum. Aportan el conocimiento y la capacidad, responden por la calidad del producto y se autogestionan. Establecen las prioridades y las relaciones con las demás tareas del backlog.

(-) Según la UD2, si el Product Owner quiere incluir un elemento nuevo en el Sprint Backlog durante el sprint en curso, ¿qué debe hacer?. Añadirlo directamente al sprint backlog, ya que tiene autoridad sobre el backlog. Esperar al siguiente sprint planning para incluirlo en la planificación. Pedirle al Scrum Master que lo añada, quien tiene la última palabra sobre el sprint backlog. Negociarlo con el equipo de desarrollo, ya que solo el equipo puede agregar o eliminar tareas del sprint backlog.

(-) Según la UD3, ¿qué tres elementos se requieren para la fase de planificación del sprint en el Sprint Planning (¿qué puede entregarse en este sprint?)?. El sprint goal, el equipo disponible y el presupuesto del sprint. El product backlog, el último incremento desarrollado con las métricas del equipo, y la capacidad del equipo estimada para el nuevo incremento. El sprint backlog del sprint anterior, el burn-down chart y la Definition of Done. Las historias de usuario priorizadas, los criterios de aceptación y la velocidad media del equipo.

(-) Según la UD3, ¿cuántos sprints suelen tardar los equipos Scrum en lograr que sus planificaciones se acerquen a lo que se entrega al final del sprint?. Uno o dos sprints, ya que la curva de aprendizaje en Scrum es muy rápida. Entre diez y quince sprints, dependiendo de la experiencia previa del equipo. Hasta cinco sprints, ya que los primeros son de reconocimiento para afinar detalles y llegar al rendimiento óptimo. Depende exclusivamente del tamaño del equipo, no hay un número estándar.

(-) La Sprint Review se describe en la UD3 como una reunión informal. ¿Qué implicación tiene esto según el texto?. Que no tiene un tiempo máximo establecido y puede durar lo que el equipo considere necesario. Que no es una reunión de seguimiento; la presentación del incremento tiene como objetivo facilitar la retroalimentación, no evaluar el rendimiento del equipo. Que la asistencia es opcional para el Product Owner y los stakeholders. Que no requiere preparación previa por parte del equipo de desarrollo.

(-) Según la UD3, ¿qué ocurre si durante el desarrollo del sprint el equipo determina que no es capaz de alcanzar el objetivo del sprint?. El Scrum Master cancela el sprint automáticamente para evitar trabajo desperdiciado. El Product Owner puede ampliar la duración del sprint para dar más tiempo al equipo. El equipo decide por votación si continúan o cancelan el sprint. Lo correcto es renegociar el sprint backlog con el Product Owner para alcanzar una solución beneficiosa; el tiempo máximo del sprint no es negociable.

(-) Según la UD3, ¿cuál es la diferencia clave entre lo que se analiza en la Sprint Review y en la Sprint Retrospective?. En la review se mira lo que el equipo está construyendo (el incremento y el producto); en la retrospectiva se pone más énfasis en cómo lo están construyendo (procesos, personas, herramientas). La review es liderada por el Product Owner y la retrospectiva por el Scrum Master. En la review participan los stakeholders y en la retrospectiva solo el equipo de desarrollo. La review ocurre al final del sprint y la retrospectiva ocurre al inicio del siguiente.

(-) Según la UD3, ¿cuál es el cambio clave introducido en la Guía Scrum 2020 respecto al Daily Scrum?. Se eliminan las tres preguntas clásicas y se sustituyen por una conversación libre de quince minutos. Pasa a ser opcional si el equipo considera que no aporta valor en determinados días del sprint. Ahora es el equipo autogestionado quien selecciona las técnicas con las cuales desarrollará el evento, siempre que se mantenga el foco en el objetivo; ya no está vinculado obligatoriamente a las tres preguntas. Su duración pasa de quince a treinta minutos para equipos de más de cinco personas.

(-) Según la UD4, ¿quién puede intervenir en el Sprint Backlog añadiendo o quitando elementos durante el sprint?. El Product Owner, ya que es el responsable máximo de todas las listas del producto. El Scrum Master, para garantizar que el sprint backlog refleja el trabajo real del equipo. Cualquier miembro del equipo Scrum, previa comunicación en el Daily Scrum. Únicamente el equipo de desarrollo; ni el Scrum Master ni el Product Owner pueden intervenir en su desarrollo.

(-) Según la UD4, el Product Backlog "está siempre vivo". ¿Qué significa exactamente esta afirmación?. Que el equipo de desarrollo puede añadir elementos al product backlog en cualquier momento sin necesidad de consultarlo con el Product Owner. Que crece y cambia a lo largo de la vida del proyecto a medida que se recibe feedback de la funcionalidad por parte de los clientes; nunca está completo. Que el Scrum Master debe actualizarlo diariamente tras cada Daily Scrum. Que los elementos del backlog pueden cambiar de prioridad solo durante el sprint planning.

(-) Según la UD4, ¿cuál de las siguientes afirmaciones sobre el Incremento es correcta?. El Incremento es la lista de tareas completadas durante el sprint, pendiente de validación por el Product Owner. El Incremento solo existe si el Product Owner decide liberarlo al mercado al final del sprint. El Incremento es la suma de todos los elementos de la lista de producto completados durante un sprint y el valor de los incrementos de todos los sprints anteriores; debe ser funcional aunque el cliente decida no liberarlo. El Incremento equivale al sprint backlog una vez que todas sus tareas han alcanzado el estado de done.

(-) La UD4 afirma que la Definition of Done "evoluciona con la madurez de los equipos Scrum". ¿Qué implica esto en la práctica?. Que la DoD se simplifica con el tiempo para no sobrecargar al equipo con criterios excesivos. Que se va ajustando y adquiriendo características más rigurosas para elevar los criterios de calidad a medida que el equipo madura. Que al principio del proyecto la DoD la define el Product Owner y más adelante pasa a ser responsabilidad del equipo. Que cada miembro del equipo puede tener su propia DoD adaptada a sus tareas específicas.

(-) Según la UD4, ¿en qué se diferencia el Product Goal introducido en la Guía Scrum 2020 del Sprint Goal?. El Product Goal es un concepto nuevo que sirve al equipo Scrum para fijar el curso y entender cuál será el futuro del producto; el Sprint Goal es el objetivo concreto de cada iteración. El Product Goal es el compromiso asociado al Product Backlog. El Product Goal lo define el Scrum Master y el Sprint Goal lo define el Product Owner. El Product Goal sustituye al Sprint Goal en la nueva Guía Scrum 2020. Ambos son equivalentes; el Product Goal es simplemente el nombre actualizado del Sprint Goal en la nueva guía.

(-) Según la UD4, los trabajos asociados directamente a los objetivos del sprint en el burn-down chart representan... El 100% del trabajo del sprint, ya que todo el sprint backlog está vinculado al sprint goal. Menos del 10% del trabajo, siendo el resto tareas de soporte y mantenimiento. El 30-70% del trabajo total del sprint, y suelen ser los primeros en abordarse. Exactamente el 50% del trabajo, según el principio de equilibrio de Scrum.

(-) Según la UD5, ¿cuál es la secuencia exacta de valores de la serie de Fibonacci que se usa en las cartas del Planning Poker?. 1, 2, 3, 4, 5, 8, 13, 21, 34, 55, 89. 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, más ¿?, Infinito y Café. 1, 2, 4, 8, 16, 32, 64, 128. 1, 3, 5, 8, 13, 21, 40, 100.

(-) En el Planning Poker, ¿qué ocurre cuando en la primera ronda de votación hay discrepancias entre los valores más altos y más bajos según la UD5?. El Scrum Master decide el valor final haciendo la media aritmética de todas las votaciones. Se repite la votación inmediatamente hasta alcanzar el consenso sin debate previo. Se da la palabra a las personas que han votado los valores más altos y más bajos para que justifiquen su criterio, aportando posibles riesgos o alternativas; luego se realiza una segunda ronda. El Product Owner tiene la última palabra y decide el valor definitivo de la historia.

(-) Según la UD5, ¿qué representa la carta "¿?" en el Planning Poker?. Que el miembro del equipo considera que la historia tiene complejidad infinita y no puede estimarse. Que el miembro tiene dudas que traslada al Product Owner para que aclare la historia antes de estimar. Que el miembro del equipo quiere hacer una pausa de café. Que el miembro abstiene su voto porque no tiene conocimientos suficientes sobre esa historia.

(-) Según la UD5, ¿cuál es el principal problema de que los interesados interpreten las estimaciones del proyecto como compromisos?. Que el equipo pierde motivación al sentirse presionado por fechas inamovibles. Que el Product Owner pierde autoridad sobre la priorización del backlog. Que el Scrum Master debe intervenir para renegociar los plazos con los stakeholders. Que una estimación es una probabilidad, no una fecha concreta ni una cantidad fija; el compromiso no puede definirse en términos de probabilidad, lo que genera expectativas irreales.

(-) Según la UD5, ¿qué ventaja tiene hacer las cosas "As Late As Possible" (ALAP) en relación con el coste?. Reduce el sobrecoste entre la estimación inicial y el coste final, porque cuando ya no queda tiempo hábil para introducir cambios al trabajo se minimiza la posibilidad de que el cliente u otro interesado añada o cambie algo crítico. Permite al equipo dedicar más tiempo a la planificación y menos a la ejecución, mejorando la calidad. Garantiza que todas las historias de usuario estén perfectamente refinadas antes de comenzar su desarrollo. Reduce el número de sprints necesarios al concentrar el trabajo en las fases finales del proyecto.

(-) Según la UD5, ¿qué significa que los puntos de historia son una "unidad relativa de tamaño"?. Que el valor de un punto de historia equivale siempre a una hora de trabajo ideal. Que cada equipo fija el valor absoluto de un punto de historia al inicio del proyecto y no lo cambia. Que no importa el valor neto de lo que significa un punto sino el tamaño relativo de una historia contra otra ya conocida; se comparan historias entre sí, no se mide el tiempo. Que los puntos de historia miden únicamente la complejidad técnica, sin considerar el esfuerzo ni la incertidumbre.

(-) Según la UD5, el User Story Mapping sirve principalmente para... Calcular la velocidad media del equipo comparando el trabajo planificado con el trabajo entregado. Tener una visión global del proyecto, no perder el horizonte de lo que se tiene que realizar y asegurar que todo el equipo esté en la misma página durante la ejecución del proyecto. Priorizar el product backlog en función del valor de negocio de cada historia de usuario. Descomponer las épicas en historias de usuario estimables durante el sprint planning.

(-) Según la UD6, ¿cuál es la diferencia entre "silos" y "cadena de valor" en el contexto de la agilidad organizacional?. Los silos son equipos ágiles autogestionados y la cadena de valor es el proceso predictivo tradicional. Los silos son fallas de comunicación entre departamentos que se centran en sus propias tareas sin intercomunicación, fragmentando la cadena de valor; la cadena de valor refleja el ciclo completo por el que pasa un producto con cuatro participantes: cliente, negocio, desarrollo de productos y operaciones. Los silos son equipos de Scrum independientes y la cadena de valor es el Scrum@Scale que los coordina. Los silos son impedimentos técnicos y la cadena de valor es el product backlog priorizado.

(-) Según la UD6, para que la transformación ágil técnica y organizacional genere resultados positivos, ¿qué dos aspectos deben consolidarse de forma integrada?. La adopción de Scrum y la implementación de herramientas de gestión de proyectos digitales. La formación del equipo y la certificación de los Scrum Masters. La agilidad técnica y la agilidad organizacional; si no existe la evolución integrada entre ambas, muy difícilmente se pueden obtener grandes resultados aunque se implemente tecnología punta. El escalado de Scrum y la reducción de la burocracia interna de la organización.

(-) Según la UD6, ¿cuál es la principal herramienta de Scrum@Scale para lograr el crecimiento de la red de equipos?. La implementación de SAFe (Scaled Agile Framework) como marco de referencia complementario. La creación de un equipo central de coordinación formado por todos los Product Owners. La estandarización de procesos en todos los equipos para garantizar la uniformidad de entregas. Lograr el crecimiento orgánico de la red de equipos de trabajo basado en un cambio sostenible, justificado en las necesidades únicas del negocio y aceptado adecuadamente por los involucrados.

(-) Según la UD6, ¿qué ocurre si en la organización solo se mejora la agilidad técnica sin desarrollar la agilidad organizacional?. El equipo gana velocidad de entrega pero pierde calidad en el producto final. Muy difícilmente se pueden obtener grandes resultados, ya que si no existe la evolución integrada entre agilidad técnica y organizacional, implementar tecnología punta no es suficiente. El Scrum@Scale se vuelve imprescindible para compensar la falta de agilidad organizacional. Los sprints se acortan automáticamente al no poder coordinar correctamente los equipos.

(-) Según la UD6, ¿qué distingue al escalado lineal de la agilidad del negocio como propósitos del escalado de Scrum?. El escalado lineal busca una correspondencia entre la cantidad de producto a entregar y el equipo requerido; la agilidad del negocio se refiere a la habilidad y capacidad de adaptación a los cambios repentinos del mercado. El escalado lineal es un objetivo a corto plazo y la agilidad del negocio es un objetivo estratégico a largo plazo. El escalado lineal aplica solo a equipos técnicos y la agilidad del negocio aplica solo a equipos de negocio. Ambos son equivalentes; el escalado lineal es simplemente la denominación técnica de la agilidad del negocio.