priss 1 bloque 4

Durante la Sprint Review, ¿qué acción representa correctamente el propósito del evento según Scrum?. Mostrar únicamente los requisitos parcialmente completados para obtener más feedback. Actualizar el Sprint Backlog para cerrar tareas pendientes. Adaptar el Product Backlog basándose en el incremento y el feedback recibido. Validar los criterios de aceptación técnicos con el Scrum Master.

¿Cuál de los siguientes usos de la Velocidad (Velocity) es correcto?. Calcular la productividad individual de cada miembro del equipo. Identificar cuántas tareas pueden asignarse a cada desarrollador. Estimar el número de Sprints necesarios en un Release Planning. Determinar la complejidad técnica del producto.

En el Daily Scrum, ¿qué afirmación es correcta?. Porque se revisan todos los burndown charts del Sprint. Porque existe el riesgo de que el equipo repita ideas superficiales y no encuentre mejoras reales. Porque es obligatoria la aprobación del Product Owner. Porque se redefinen los objetivos del siguiente Sprint.

¿Cuál es una característica del Sprint Burndown Chart?. Debe llegar exactamente a cero cada día. Puede mostrar incrementos en las horas restantes debido a reestimaciones. Refleja el avance de toda la Release. Se actualiza únicamente al finalizar el Sprint.

El Release Burndown Chart se utiliza para: Conocer la velocidad individual de los desarrolladores. Predecir si la versión completa estará lista a tiempo. Reemplazar el Product Backlog. Medir la calidad del incremento.

Durante el Sprint Planning, ¿cuál es un insumo esencial?. La velocidad histórica del equipo. El burndown de la Release. Las vacaciones del Product Owner. La lista completa de impedimentos del proyecto.

¿Cuál es un atributo típico de un Product Backlog Item (PBI)?. Criterios de codificación interna. Estimación y orden. Asignación obligatoria a un desarrollador específico. Documentación de pruebas.

¿Qué tipo de elemento podría formar parte del Product Backlog?. Horas dedicadas por cada desarrollador. Requisitos funcionales, defectos o mejoras técnicas. El Sprint Goal. La capacidad semanal del equipo.

En la Sprint Retrospective, uno de los objetivos es: Identificar culpables de fallos para ajustar el rendimiento. Mejorar el proceso y la colaboración del equipo. Priorizar el Product Backlog. Reestimar el tamaño de los PBIs.

Según el valor “Individuos e interacciones sobre procesos y herramientas”, ¿qué implicación tiene para la gestión de riesgos?. La mitigación es más efectiva mediante comunicación directa que mediante reportes burocráticos. Solo el Scrum Master puede hablar con los stakeholders. Los procesos de gestión de riesgos no deben modificarse. La herramienta de gestión de riesgos debe priorizarse sobre las reunionesel cumplimiento del Sprint Goal.

Durante la creación de la Visión del Producto, uno de los pasos críticos es validar el borrador con los interesados. ¿Cuál es el motivo principal según el enfoque ágil?. Asegurar que el documento final tenga suficiente detalle técnico para el Equipo de Desarrollo. Evitar cambios posteriores, ya que la visión debe ser estática durante todo el proyecto. Garantizar que la visión refleje necesidades reales del cliente y objetivos de negocio antes de avanzar a la planificación. Permitir que los stakeholders reasignen recursos antes de la fase de ejecución.

En Lean, “Crear Integridad / Calidad intrínseca” enfatiza: Que la documentación es la principal forma de asegurar calidad. Que los componentes deben funcionar bien juntos como un todo coherente. Que la calidad debe revisarse solo al final del proyecto. Que los desarrolladores y QA trabajen siempre separados.

¿Cuál de los siguientes elementos SIEMPRE forma parte del Product Roadmap según el Tema 2?. Burndown Charts por cada versión. Los temas y características principales están organizados en hitos temporales. Las tareas detalladas con estimación en horas. Los criterios de aceptación de cada historia de usuario.

En la plantilla de Historia de Usuario, ¿qué parte se detalla únicamente durante la conversación PO–Equipo?. El “Como/Quiero/Para”. El Usuario principal del sistema. Los Criterios de Aceptación (condiciones de satisfacción). El título y la estimación inicial de puntos.

Durante la Planificación de Versiones (Release Planning), el Product Owner y el equipo deben: Construir el Sprint Backlog completo para todos los sprints de la versión. Estimar el número de Sprints necesarios usando la velocidad histórica del equipo. Definir los criterios técnicos que debe cumplir el incremento final. Seleccionar tareas individuales en función de la especialización de cada desarrollador.

El Sprint Planning incluye decidir cuántas Historias de Usuario entrarán en el Sprint. ¿Cuál es el principio clave para hacerlo según el Tema 2?. Seleccionar el máximo número posible de historias para aumentar la productividad. Elegir únicamente historias técnicas o de mantenimiento. Seleccionar historias en función de la capacidad del equipo y del valor que aportan al objetivo del Sprint. Priorizar únicamente historias que eliminen deuda técnica.

¿Qué valor aporta el Product Vision Board presentado en el Tema 2?. Sirve como documento contractual entre cliente y proveedor. Permite al PO validar rápidamente cliente objetivo, necesidades, beneficios y diferenciadores del producto. Sustituye la fase de Product Roadmap. Contiene únicamente historias de usuario priorizadas.

El Product Owner debe crear la Visión del Producto porque: Es el documento legal del proyecto. Define claramente el “por qué” y “para qué” del producto. Permite al SM priorizar los requisitos. Sustituye el Product Roadmap.

El Product Roadmap contiene: Tareas detalladas del sprint. Temas y características distribuidos en el tiempo. Historias técnicas y HU descompuestas. Exclusivamente Bugs del sistema.

La planificación de versiones (Release Planning) utiliza: La velocidad histórica del equipo. Las horas estimadas por desarrollador. El número de tareas técnicas. El número de testers disponibles.

La estimación relativa es preferible porque: Usa horas exactas, mejorando la precisión. Es más humana y permite comparar historias entre sí. Evita la necesidad de descomposición. Elimina la incertidumbre.