QUIZ - PROFESSIONAL SCRUM MASTER CERTIFICATE

.md

SCRUM MASTER PROFESSIONAL CERTIFICATE (SMPC®)

Simulador para examen Scrum Master

1. ¿Quién debe hacer el trabajo requerido para los elementos del Producto Backlog, para crear un Incremento potencialmente liberable?

1. El equipo Scrum.
2. El Scrum Master.
3. El Equipo de Desarrollo.
4. El Product Owner.

El Equipo de Desarrollo es multifuncional y hace el trabajo de entregar un Incremento potencialmente liberable del producto “Hecho” o “Done” al final de cada Sprint. No usan ninguna ayuda externa. No se recomienda, ni es una buena práctica, que el Scrum Master o el Product Owner trabajen como desarrolladores.

2. Son los Pilares de Scrum.

1. Simplicidad, Comunicación, Retroalimentación, Respeto, Coraje.
2. Transparencia, Inspección, Adaptabilidad.
3. Compromiso, Coraje, Enfoque, Apertura, Respeto.
4. Individuos e interacción, Software de trabajando, Colaboración con el cliente, Respuesta al cambio.

Los pilares de la teoría de Scrum nombrados en la Guía Scrum son Transparencia, Inspección, Adaptabilidad. Los Valores de Scrum son Compromiso, Valor, Enfoque, Apertura y Respeto.

3. ¿Cuáles son tres cosas que son responsabilidad del Scrum Master durante el Sprint?

1. Facilitar las reuniones necesarias.
2. Eliminar impedimentos.
3. Asignar tareas a los desarrolladores.
4. Asegurarse de que el Equipo de Desarrollo se mantenga autoorganizado.
5. Aprobar la longitud del Sprint.

El Scrum Master es responsable de ayudar a todos a comprender la teoría, las prácticas, las reglas y los valores de Scrum. Elimina impedimentos (resuelve problemas), facilita las reuniones según sea necesario. Todo el Equipo Scrum decide la duración del Sprint considerando cuatro semanas para la duración máxima. Las tareas son asignadas por los propios desarrolladores.

4. ¿Cuáles son dos razones por las que Scrum promueve equipos autoorganizados?

1. Porque mejoran su previsibilidad.
2. Porque mejoran su auto-responsabilidad.
3. Porque mejoran su cumplimiento normativo.
4. Porque mejoran su compromiso.

Ser autoorganizado implica que el equipo sigue su propio proceso, en lugar de recibir órdenes. Cuando es así, los miembros del equipo tienden a comprometerse y aumentar su responsabilidad y creatividad.

5. Se necesitan Sprints de análisis y diseño, para resolver dependencias y reducir la deuda técnica.

1. Verdadero
2. Falso

No hay Sprint de análisis, Sprint de diseño, Sprint zero, Sprint de integración, Sprint de lanzamiento, etc. Solo hay un tipo de Sprint, y su objetivo es crear un Incremento de características valiosas potencialmente liberables.

6. ¿Cuál es el criterio correcto para ordenar el Product Backlog?

1. Los ítems más seguros están en la parte superior y los ítems más riesgosos están en la parte inferior.
2. Lo que el Product Owner considere más apropiado.
3. Los ítems están dispuestos al azar.
4. El cliente siempre decide.

La decisión sobre el orden de los ítems puede ser influenciada por un comité, el cliente o cualquier otra parte interesada, pero solo el Product Owner decide qué tiene más sentido para optimizar el valor del trabajo realizado por el Equipo de desarrollo.

7. ¿Quién debe asistir al Daily Scrum?

1. El Equipo de Desarrollo y el Product Owner.
2. El Equipo de Desarrollo y el Scrum Master.
3. El equipo Scrum.
4. Los miembros del Equipo de Desarrollo.

Los únicos que deben asistir son los miembros del Equipo Scrum. El Scrum Master se asegura de que el equipo de desarrollo tenga la reunión, pero no necesita estar presente en ella. Cualquier otra persona puede asistir, pero no “deben” participar, hay que notar que los invitados solo miran y escuchan sin participar.

8. Es uno de los pilares de la teoría de Scrum.

1. Adaptabilidad.
2. Apertura.
3. Respeto.
4. Planificación.

La Adaptabilidad, la Transparencia y la Inspección son los pilares de la teoría de Scrum. Scrum como marco ágil, se trata principalmente de Adaptabilidad (en lugar de predicción).

9. Durante el Sprint Planning que avanza, el equipo de desarrollo se ha dado cuenta de que no podrán terminar el trabajo para todos los elementos seleccionados para el Sprint Backlog. ¿Cuáles de las siguientes son dos de las mejores acciones generalmente?

1. Trabajar cada fin de semana.
2. Negociar con el Product Owner para remover o ajustar algunos de los elementos tomados del Product BackLog.
3. Contratar desarrolladores extra.
4. Informar al Product Owner tan pronto como sea posible y comenzar el Sprint.
5. Cancelar el Sprint.

Incluso si el equipo no entrega incrementos, el Product Owner debe estar informado al respecto y debe trabajar con el equipo de desarrollo y ajustar, agregar y/o eliminar los elementos del Sprint Backlog a lo largo de la iteración para lograr el Objetivo del Sprint. Pero, dado que esta sigue siendo la el Sprint Planning, también tenemos la oportunidad de modificar el Objetivo del Sprint, no podremos hacerlo después del Sprint Planning.

Siempre trabajamos a un ritmo regular y constante, no debemos trabajar horas extras. No deberíamos cambiar el número de desarrolladores, agregar desarrolladores no aumentará la productividad a corto plazo.

10. El Product Owner decide cuántos elementos de Backlog de Producto deben seleccionarse para el próximo Sprint.

1. Correcto, basado en los acuerdos con el cliente.
2. Incorrecto, el Scrum Master decide eso.
3. Incorrecto, la PMO decide eso.
4. Falso.
5. Correcto.

El Product Owner establece el Objetivo que debe alcanzar el Sprint, aunque puede ser influenciado por el Equipo de Desarrollo. Sin embargo, solo los miembros del Equipo de Desarrollo crean el Incremento, es por eso que solo extraen los elementos del Backlog del Producto para lograr el Objetivo del Sprint.

11. ¿Cuándo puede un Equipo de Desarrollo cancelar un Sprint?

1. Cuando el Sprint ya no tiene sentido.
2. Cuando no pueden resolver algún problema técnico.
3. En cualquier momento.
4. No pueden cancelar Sprints.

El único que puede cancelar un Sprint es el Product Owner. Esto puede suceder cuando se da cuenta de que el Sprint ya no tiene sentido, porque el Objetivo Sprint se ha vuelto obsoleto.

12. Cuando tenemos más riesgo, necesitamos Sprints más largos.

1. Falso
2. Verdadero

Cuando tenemos Sprints más cortos, hay más oportunidades para mostrar el progreso y recibir comentarios, validar nuestro conocimiento y, por lo tanto, adaptarnos. Por esta razón, se prefieren Sprints más cortos cuando tenemos mayores riesgos.

13. ¿Cuáles tres de las siguientes afirmaciones son verdaderas acerca del rol como Scrum Master?

1. Es un puesto de gestión.
2. Es un rol de coaching al equipo de desarrollo en autoorganización y funcionalidad cruzada.
3. Es un líder que sirve (servant-leader) para el Equipo Scrum.
4. Es la única persona responsable de administrar el Product Backlog.
5. Es responsable de actualizar la gráfica de burndown (burndown chart).

A pesar de que Scrum Master no gestiona personas, gestiona procesos. Por eso se considera una función de gestión. El equipo de desarrollo está autoorganizado; el Scrum Master puede entrenar y ayudar, pero los desarrolladores son los que manejan el progreso y el rendimiento de los Sprints. Es el Product Owner quien es dueño del Backlog del Producto.

14. ¿Qué es lo que generalmente sucede cuando el Equipo Scrum madura a través del proyecto?

1. Ya no necesitan un Scrum Master.
2. Ya no necesitan Retrospectivas de Sprint.
3. Son capaces de mejorar la definición de Hecho (o Done).
4. Son capaces de liberar cada Incremento.
5. Ya no necesitan Sprint Reviews.

Cada equipo tiende a aprender más y madurar durante el proyecto, por lo que las técnicas, la experiencia, las habilidades y los métodos también mejoran. Esto debe afectar la definición de Hecho (o Done). Todos los roles, eventos y artefactos de Scrum son necesarios y no deben omitirse por ningún motivo.

15. El jefe de tecnología de su organización y uno de los clientes más importantes solicitan a algunos miembros del equipo de desarrollo que agreguen una nueva funcionalidad en medio del Sprint. ¿Que deberían hacer?

1. Remitirlos al Product Owner.
2. Agregar la nueva característica al Product Backlog.
3. Rechazar la solicitud.
4. Reemplazar un elemento en el Backlog actual del Sprint con el nuevo.
5. Agregar la nueva característica al Sprint Backlog.

Una de las principales responsabilidades del Product Owner es maximizar el valor del trabajo del equipo de desarrollo, y él es el único que puede agregar nuevos elementos al Product Backlog. Incluso cuando el Equipo de Desarrollo posee el Backlog del Sprint, los miembros no agregan elementos arbitrariamente, el Product Owner debe asegurarse de que cualquier elemento nuevo agregue valor y pueda trabajar con las partes interesadas adecuadas al respecto y luego agregarlo al Backlog del Producto para los próximos Sprints, además el propietario del producto puede rechazar la nueva función, en lugar del equipo de desarrollo.

16. ¿Cuál es la responsabilidad principal del Project Manager bajo el esquema Scrum?

1. Verificar constantemente el resultado de los programadores.
2. No hay rol de Project Manager en Scrum.
3. Ayudar al equipo a implementar buenas prácticas.
4. Crear un acta de constitución del proyecto.

Solo tenemos tres roles en Scrum: Propietario del producto, Scrum Master y Equipo de desarrollo. No está permitido definir nuevas funciones y el equipo de desarrollo debe ser autoorganizado y multifuncional.

17. El Equipo de Desarrollo y el Product Owner no están trabajando juntos en absoluto. ¿Qué debe hacer el Scrum Master?

1. Enviar a todos a un curso de capacitación Scrum y reiniciar el proyecto.
2. Entrenar al Product Owner y el equipo de desarrollo sobre los valores de Scrum y la entrega incremental.
3. Reiniciar el Sprint.
4. Reportar al Product Owner con su gerente.

El Scrum Master debe entrenar a todos los miembros del Equipo Scrum en entornos organizacionales en los que Scrum aún no se haya adoptado y entendido por completo con el fin de practicar la Agilidad. El Scrum Master debe ayudarlos a comunicarse eficazmente entre sí, pero ha que tener cuidado cuidado de no actuar como un “mediador” entre ellos.

18. ¿Cuál es el resultado de un Sprint?

1. Un Incremento potencialmente liberable de producto "Hecho" o "Done".
2. Un conjunto de documentos que muestra el diseño general del producto.
3. El plan de pruebas para QA.
4. Las maquetas que muestran la atmósfera general que se utilizará para el producto.

El propósito de los Sprints es crear incrementos; en otras palabras, un producto de trabajo que sea potencialmente utilizable y se basado en la definición acordada de “Hecho” o “Done”, independientemente de las técnicas, documentos o métodos utilizados para lograrlo.

19. ¿Cuándo puede cambiar la composición del equipo de desarrollo?

1. Durante los Sprints.
2. Después de cada Sprint.
3. Nunca, la composición del equipo no debe cambiar.
4. Siempre que sea necesario, teniendo en cuenta una reducción de la productividad a corto plazo.

Esto no debería ser frecuente porque crea una reducción de tiempo breve en la productividad, pero si es necesario, trate de evitar cambios en los miembros del equipo durante el Sprint.

20. ¿Quién puede decidir agregar más trabajo al Sprint Backlog durante el Sprint?

1. La Gerencia
2. El Equipo Scrum.
3. El Development Team.
4. El Product Owner.
5. El Scrum Master.

Después del Sprint Planning, los elementos incluidos en el Sprint Backlog no se pueden cambiar. Pero las tareas desglosadas y creadas por el Equipo de Desarrollo para completar el trabajo siempre cambian y se adaptan de acuerdo con sus prácticas, técnicas y conocimientos.

21. Siempre debe haber un Lanzamiento después de cada Sprint.

1. Falso
2. Verdadero

El objetivo principal del Sprint es crear un incremento de producto “Listo” utilizable y potencialmente liberable.

22. ¿Cuándo se considera completado un elemento del Backlog?

1. Cuando todas sus tareas están 100% completas.
2. Cuando el cliente está satisfecho con el resultado.
3. Cuando todo esté completo basado en la Definición de Hecho (Definition of Done).
4. Cuando los expertos en control de calidad hayan terminado con las pruebas.

Cuando el elemento se completa según la Definición de Hecho, y por lo tanto, los usuarios reales y finales pueden usarlo, lo que también significa que se ha creado un Incremento de software que es potencialmente liberable.

23. El Product Owner dice que el cliente tiene problemas de seguridad. ¿Dónde se pueden abordar estas preocupaciones en el contexto Scrum? (Seleccione 2 respuestas).

1. Se pueden agregar al Product Backlog.
2. Se puede manejar en un Sprint dedicado especial.
3. Se puede manejar en la Definition of Done.
4. Puede ser manejado por contratistas expertos en seguridad en algún momento.

Se pueden agregar muchas características no funcionales, como la seguridad, como criterios de aceptación y pruebas en la Definition of Done para aplicar a todos o algunos elementos del Product Backlog.

Podemos tener algunos problemas de seguridad específicos que pueden ser elementos en Product Backlog. El equipo de desarrollo es multifuncional y autosuficiente, debe ser capaz de cuidar todos los aspectos del producto, incluida la seguridad.

24. ¿Cuáles son las tres razones por las cuáles incluir las pruebas en la definición de “Hecho o Done” es una buena práctica?

1. Porque agrega transparencia a los incrementos finales.
2. Porque puede simplificar las definiciones de los requerimientos.
3. Porque es más probable que los resultados sean liberables.
4. Porque el progreso será más fácil de mostrar en los gráficos de quemado (burndown charts).

Necesitamos saber cuándo un elemento está realmente Hecho o Done, en otras palabras, compartimos una comprensión común de lo que significa un trabajo terminado. Con este propósito, podemos aumentar la Transparencia cuando hay pruebas incluidas en la Definición de “Hecho o Done” que verificarán qué tan cerca está el trabajo de estar “completo”, “potencialmente liberable” y convertirse en un Incremento real utilizable para los usuarios finales.

También escribir pruebas de aceptación ayuda a expresar muchos de los detalles que resultan de las conversaciones entre los clientes y los equipos Scrum, en lugar de escribir largas listas de “El sistema debe …”.

25. ¿Cuál de los siguientes no es responsabilidad del Equipo de Desarrollo?

1. Tratar los conflictos internos del equipo.
2. Ordenamiento de los elementos del Backlog del Producto.
3. Medir del rendimiento del Sprint.
4. Estimar el trabajo necesario para los elementos de Backlog del Sprint.

Recuerde que el Equipo de Desarrollo es autoorganizado. Por lo tanto, es responsabilidad del equipo medir su propia productividad y rendimiento a lo largo del Sprint, determinar su propio proceso, planificar, estimar y optimizar el trabajo requerido para los artículos y el Objetivo del Sprint, así como resolver sus propios conflictos.

26. La estructura del Daily Scrum la establece el Equipo de Desarrollo.

1. Falso
2. Verdadero

El Equipo de Desarrollo es propietario de las reuniones diarias de Scrum, se pueden llevar a cabo de diferentes maneras, pero siempre se enfoca en el progreso hacia el Objetivo del Sprint.

27. ¿Cuál es la mejor descripción de Scrum?

1. Es una metodología para el desarrollo de software.
2. Es una nueva metodología de gestión de proyectos.
3. Es un marco de trabajo dentro del cual las personas pueden abordar problemas complejos de forma adaptativa.
4. Es un cuerpo de conocimiento práctico y moderno de gestión de proyectos.

Scrum es un marco de trabajo que es adaptativo y empírico en lugar de teórico, por lo que se puede utilizar para el desarrollo de productos complejos en entornos de alta complejidad. Scrum tiene más que ver con la entrega de proyectos que con la gestión de proyectos, por lo tanto, no es una metodología ni un cuerpo de conocimientos.

28. El Sprint Backlog incluye …

1. Casos de Uso.
2. Historias de Usuario.
3. Pruebas.
4. Tareas.
5. Cualquiera de los anteriores, ya que son una descomposición de los elementos seleccionados del Product Backlog.

Las Historias de Usuario, Casos de Uso, Pruebas, Tareas e incluso otros elementos que ayudan a definir y aclarar el trabajo pueden ser parte del Sprint Backlog.

29. ¿Quién es responsable de comunicar e involucrar a los interesados?

1. El Product Owner.
2. El Scrum Master.
3. El Equipo Scrum.
4. El equipo de desarrollo.

Los Product Owner deben comunicarse efectivamente con los clientes, por lo tanto, también involucrarlos.

30. Al comienzo del Sprint, el Development Team no tiene las herramientas ni la infraestructura necesarias para completar los elementos del Backlog del Sprint actual. ¿Qué dos cosas debe hacer el Scrum Master?

1. El Incremento del Sprint actual se enfocará en entregar infraestructura y adquisición de herramientas.
2. Cancelar el proyecto.
3. Ayudar al Development Team a obtener herramientas y mejorar la infraestructura mientras la Definition of Done se adapta en consecuencia.
4. Hablar con el Product Owner para aceptar incrementos parcialmente realizados.
5. Facilitar la comunicación entre el Product Owner y el Development Team para establecer un Objetivo del Sprint plausible y una "Definition of Done" adecuada.

La infraestructura y las herramientas no están preparadas por adelantado, ya que se requiere de una comprensión completa de todo el proyecto y el producto, que generalmente no es el caso, por lo que debemos aferrarnos al pilar de adaptación. La infraestructura y las herramientas necesarias se prepararán gradualmente a través del proyecto porque dependen del producto que vamos a crear, que a su vez se define a través del proyecto.

31. ¿Cuáles son las tres responsabilidades de un equipo autoorganizado?

1. Facilitar todos los eventos Scrum según lo solicitado.
2. Estimar la cantidad de trabajo necesaria para completar los elementos del Backlog del Producto.
3. Tomar los elementos del Backlog del Producto para el próximo Sprint.
4. Crear los elementos del Backlog del producto.
5. Expresar claramente los elementos del Backlog del Producto.
6. Establecer las tareas necesarias para los elementos del Backlog del Sprint.

Es responsabilidad del Equipo de Desarrollo seleccionar la cantidad adecuada de elementos del Backlog de Producto, desglosar las tareas y crear estimaciones para cada Sprint.

32. Eventualmente, el Scrum Master se vuelve innecesario cuando el Equipo de Desarrollo madura a través del proyecto.

1. Falso
2. Verdadero

Si un proyecto no incluye los roles Scrum Master o Product Owner, este proyecto no está utilizando Scrum. Ambos roles pueden ser a tiempo parcial, pero siempre existen en un proyecto Scrum. Una de las actividades más importantes del Scrum Master es eliminar los impedimentos, y no importa cuán maduro sea el Equipo de Desarrollo, sus miembros siempre se beneficiarán cuando alguien se ocupe de estos problemas.

33. El Sprint termina cuando …

1. Todos los elementos del Sprint Backlog están listos.
2. El Product Owner considera que está terminado.
3. El tiempo del Sprint termina

Los eventos de duración fija (timeboxed) Scrum no se extienden, puede tomar el tiempo disponible para algunos de estos eventos como duración máxima, por lo que pueden terminarse antes si se hace completado, pero la duración del Sprint tienen una duración fija, esto significa que no pueden reducirse. Si todo está terminado antes del final del Sprint, el Equipo de Desarrollo elegirá el siguiente elemento del Product Backlog y comenzará a trabajar en eso.

34. ¿Qué cantidad de trabajo debe hacer el Development Team en un elemento seleccionado del Product Backlog para completar el Sprint?

1. Tanto como sea necesario en cumplimiento a la definición de "Hecho o Done".
2. Análisis de requisitos, diseño, implementación, pruebas, documentación y algún mantenimiento.
3. Todo el trabajo necesario, incluidas algunas mejoras.
4. Tanto como se pueda hacer en el Sprint.

La definición acordada de “Hecho o Done” para el Equipo Scrum se utiliza para evaluar cuándo se completa el trabajo en el incremento del producto, con el fin de ofrecer un incremento de de funcionalidad potencialmente liberable.

35. ¿Cuáles dos afirmaciones son ciertas sobre el Product Owner?

1. Ordenar los elementos en el Product Backlog que mejor logren objetivos y misiones.
2. Todo su tiempo debe estar dedicado a un sólo proyecto.
3. Optimizar el valor del trabajo que realiza el Development Team.
4. Es otro nombre para el Project Manager.

El Product Owner es responsable de maximizar el valor del producto resultante a partir del trabajo del Development Team, y en consecuencia, de priorizar los elementos del Producto Backlog .

No existe un rol Project Manager o equivalente en el marco de Scrum.

El Product Owner puede dedicarse a tiempo parcial a un proyecto.

36. De las siguientes opciones, ¿cuál es la mejor manera en que un Scrum Master puede aumentar la productividad del equipo?

1. Eliminar impedimentos y facilitar eventos de Scrum.
2. Asignar de tareas a los desarrolladores.
3. Desglosar los elementos del Product Backlog más valiosos.
4. Implementar un tablero de control de cambios.

Eliminar los impedimentos y facilitar los eventos Scrum según es solicitado o necesitado son el tipo de cosas que se esperan del Scrum Master. El Development Team está auto-organizado, el Scrum Master no les da órdenes. El Scrum Master debe asegurarse de que el Product Owner sepa cómo priorizar el Producto Backlog para maximizar su valor, pero el Scrum Master no es responsable de hacerlo.

37. ¿Cuáles son dos buenos enfoques para que el Development Team haga visibles los requisitos no funcionales?

1. Agregarlos a los criterios de aceptación como parte de la definición de "Hecho" (o "Done").
2. Crear un Product Backlog solo para estos requisitos.
3. QA debe ejecutar pruebas de integración y regresión antes del final del Sprint.
4. Agregarlos al Product Backlog y mantener informado al Product Owner sobre el esfuerzo estimado.

El Product Owner es la única persona responsable de administrar el Product Backlog, pero siempre puede y debe tener en cuenta los comentarios y opiniones de otras partes interesadas, incluido el equipo de desarrollo, que pueden influir para agregar nuevos elementos en el Produt Backlog. Los buenos requisitos deben ser lo suficientemente breves, es por eso que las pruebas de aceptación se pueden utilizar para expresar muchos de los detalles que resultan de las conversaciones entre clientes, usuarios, propietarios de productos y desarrolladores, incluidos los requisitos no funcionales. Un producto solo tiene un Backlog de Producto.

38. Los elementos del Product Backlog en posición inferior son generalmente más grandes y menos claros que los de la parte superior.

1. Verdadero
2. Falso

Cuando se crea el Product Backlog, se le agregan elementos. Tienen diferentes tamaños y, finalmente, se ordenan según su valor de negocio. Los items más valorados estarán en la parte superior y, por lo general, estos elementos se desglosarán en otros más pequeños. No hacemos esto con aquellos elementos en la parte inferior. Es por eso que generalmente hay elementos más grandes y menos transparentes en la parte inferior del Product Backlog.

39. El Development Team debe preparar una infraestructura completa y un conjunto de herramientas para el proyecto durante el primer Sprint.

1. Verdadero
2. Falso

El Development Team no analiza, diseña ni describe la arquitectura e infraestructura completas de antemano para todo el proyecto. Los procesos ágiles se caracterizan por frecuentes ráfagas cortas de diseño, lo suficiente para alcanzar el objetivo de Sprint.

40. ¿Cuál es el rol de Scrum que más sabe sobre el desempeño del proyecto?

1. El Equipo de Desarrollo.
2. El Producto Owner.
3. El equipo Scrum.
4. El Gerente de Producto.
5. El Scrum Master.

El Product Owner es responsable de medir el rendimiento del proyecto. El Equipo de Desarrollo solo mide el rendimiento del Sprint actual.

41. ¿Cuál debería ser la duración de un Sprint de acuerdo con la Scrum Guide?

1. Todas las respuestas son correctas.
2. Lo suficientemente corto como para poder sincronizar el trabajo de desarrollo con otros procesos de negocio.
3. No más de cuatro semanas.
4. Suficientemente corto para mantener riesgos de negocio aceptables para el Product Owner.

Todas estas opciones son criterios correctos para decidir la duración de un Sprint.

42. ¿Qué representa la línea de tendencia en un gráfico de quemado, a través de un Sprint?

1. El trabajo restante se completará si nada cambia en la Product Backlog o el Equipo de Desarrollo.
2. La fecha en que el equipo Scrum puede ser liberado para otro trabajo.
3. Los cambios del costo a través del Sprint actual.
4. El arrastre de la deuda técnica restante.

La línea de tendencia nos da visibilidad sobre el pronóstico para la fecha de finalización, considerando un constante Capacidad del Equipo de Desarrollo para el Backlog del Sprint.

43. ¿Cuáles dos respuestas son verdaderas acerca de la definición de “Hecho o Done”?

1. Se utiliza para tener una comprensión compartida de lo que significa que el trabajo esté completo.
2. Se utiliza para evaluar cuándo se completa el trabajo en el Incremento del producto.
3. Es el propósito del Sprint.
4. Describe las tareas que se deben realizar para completar el Sprint.

La Definición de “Hecho o Done” define lo que se espera como resultado del Sprint actual. Esto incluye (pero no se limita) a criterios de aceptación y características no funcionales. El propósito es compartir la misma comprensión del trabajo completado para aumentar la transparencia.

El Objetivo del Sprint es lo que define el propósito del Sprint.

El equipo de desarrollo debe tener presente la definición de “Hecho o Done” para crear tareas, pero también la descripción de cada elemento extraído del Backlog del producto.

44. ¿Cuándo debería el equipo Scrum celebrar la reunión Retrospectiva del Sprint?

1. Al final de cada proyecto.
2. Cuando el Product Owner y el Scrum Master determinan que es necesario.
3. Al final de cada Sprint.
4. Al final de cada lanzamiento.
5. Al comienzo de cada Sprint.

La Retrospectiva del Sprint ocurre siempre después de la Revisión del Sprint y antes de la próxima Planificación del Sprint.

45. Son los Valores de Scrum.

1. Transparencia, Inspección, Adaptabilidad.
2. Compromiso, Coraje, Enfoque, Apertura, Respeto
3. Simplicidad, Comunicación, Retroalimentación, Respeto, Coraje.
4. Individuos e interacción, Software trabajando, Colaboración con el cliente, Respuesta al cambio.

Los valores de Scrum nombrados en la Guía Scrum son Compromiso, Coraje, Enfoque, Apertura, Respeto. Los pilares de la teoría Scrum son Transparencia, Inspección, Adaptabilidad.

46. ¿Quién estima el trabajo durante el Sprint?

1. El Scrum Master.
2. El equipo de desarrollo y el Product Owner.
3. Todo el Equipo Scrum.
4. El Product Owner.
5. El Development Team.

Dado que las personas que realmente hacen el trabajo son las que mejor saben lo que se necesita para completar tareas específicas; Todas las estimaciones son hechas por el Equipo de Desarrollo.

47. ¿Cómo deben estar compuestos los miembros de múltiples equipos para un solo proyecto?

1. El Scrum Master elige a los miembros del equipo para cada equipo.
2. El Product Owner elige los miembros del equipo para cada equipo.
3. La gerencia elige a los miembros del equipo para cada equipo.
4. Todos juntos decidirán cómo formar los equipos.
5. Los propios desarrolladores decidirán la composición de los equipos.

Los desarrolladores deben ser auto-organizados y son responsables de la formación y composición de los equipos.

48. El Product Owner quiere crear estimaciones y pedirle al Scrum Master que lo guíe. ¿Cuál es la guía más adecuada que debe dar el Scrum Master?

1. El Development Team debe crear estimaciones.
2. El Product Owner debe usar días ideales para obtener estimaciones.
3. El Product Owner debe usar puntos de historia para obtener estimaciones.
4. No hay estimación en Scrum.

Solo los miembros del Development Team crean el Incremento y son los miembros del Equipo Scrum más adecuados para hacer estimaciones. El Product Owner y el Scrum Master pueden sugerir y usar técnicas para ayudar al Development Team a medir su esfuerzo, sin embargo, solo el Development Team realiza la estimación por sí mismo.

49. Varios equipos Scrum deben usar la definición de “Hecho o Done” para normalizar las estimaciones. De esta manera será más fácil medir y comparar su rendimiento.

1. Falso
2. Verdadero

No hay unidades de estimación comparables entre los equipos de desarrollo, cada equipo es diferente. Si intenta normalizar, puede provocar malentendidos y problemas de relleno.

La definición de “Hecho o Done” es una práctica común, pero no forma parte de la Guía Scrum, y su objetivo no es normalizar las estimaciones ni la medición del rendimiento.

50. Un programador no funciona correctamente, está bloqueando el progreso del equipo y sus actividades constantemente. ¿Quién debe decidir sobre el futuro de esta persona como miembro del equipo?

1. El Development Team.
2. La gerencia.
3. El Scrum Master.
4. El Product Owner.

El Development Team está auto-organizado, por lo tanto, esta es una decisión y responsabilidad de sus miembros. Por supuesto, el Scrum Master debe abordar y apoyar esta decisión, ya que también es un impedimento.

51. ¿Cuál es el tema más importante que el Equipo Scrum debe resolver durante Sprint cero?

1. Preparar el Product Backlog para al menos tres Sprints.
2. No existe el Sprint zero.
3. Comunicarse con las partes interesadas y presentar al equipo.
4. Determinar el número total de Sprints en el proyecto.

No existe tal cosa como el Sprint zero. El primer Sprint es el primero, y no es diferente de otros Sprints, desde la perspectiva de que el Development Team debería crear un Incremento. La infraestructura, las herramientas y los requisitos se preparan gradualmente a lo largo del proyecto.

52. Durante el Sprint, el Equipo de Desarrollo determina que no puede completar su trabajo al final del Sprint. ¿Qué pasa en este caso?

1. El Sprint será cancelado.
2. El Sprint se extenderá.
3. El equipo de desarrollo continuará el trabajo sin terminar en el próximo Sprint.
4. El Sprint continúa.

El Sprint actual continúa. El Product Owner y el equipo de desarrollo revisarán y ajustarán el trabajo de Sprint seleccionado, siempre siguiendo el objetivo de Sprint.

53. ¿Qué parte del trabajo pendiente del Sprint debe definirse a lo largo de la reunión del Sprint Planning?

1. Sólo lo suficiente para crear la línea de base para todo el proyecto.
2. Lo suficiente, para que el propietario del producto pueda asignar tareas a los desarrolladores.
3. Absolutamente todo el trabajo.
4. Solo lo suficiente, para que el Equipo de Desarrollo pueda estimar lo que pueden hacer y comenzar el trabajo en los primeros días del Sprint.

Scrum no realiza una planificación de antemano, sólo se crean algunas tareas desglosadas desde los elementos tomados para el Sprint Planning.

El equipo de desarrollo se autoorganiza, sus miembros deciden quién qué hacer.

No hay línea de base para un proyecto Scrum.

54. ¿De quién es la decisión de establecer las tareas que se realizarán durante el Sprint?

1. El Development Team.
2. El Scrum Master.
3. El Product Owner.
4. El líder del equipo.

El Development Team es auto-organizado, por lo tanto, sus miembros deciden sobre su forma de trabajo y el enfoque técnico del proyecto.

55. ¿Cuál de las siguientes es la situación más adecuada durante el Sprint Planning teniendo en cuenta que tenemos siete equipos Scrum trabajando en un solo producto?

1. Todos se reúnen en el mismo lugar al mismo tiempo, los Equipos Scrum pueden nominar a un número menor de personas apropiadas para representar al equipo en las primeras discusiones que se llevan a cabo a nivel de escalamiento, el Propietario del producto brinda información y luego cada dependencia es discutida y coordinada por los equipos. Los miembros del equipo se pueden cambiar según sea necesario y se crean los Sprint Backlogs para cada equipo Scrum.
2. El Product Owner se reúne solo con algunos representantes de cada equipo para seleccionar elementos del Product Backlog. Luego, cada representante trabaja con su equipo para crear su Sprint Backlog y se evitan las dependencias para Sprints de escalamiento especiales.
3. Todos los miembros del equipo se reúnen y juntos crean un Sprint Backlog para la iteración, en la cual todos trabajarán.

Solo hay una Product Backlog y un Product Owner para un producto. Sin embargo, cada equipo debe tener un Sprint Backlog separado.

El Development Team es responsable de seleccionar los elementos del Product Backlog , sin embargo, pueden seleccionar representantes para hacerlo. Pero, comparten la propiedad de estos.

Los miembros del equipo pueden cambiar la composición de los equipos (turno) entre Sprints.

Aunque los elementos del Product Backlog y deberían independientes entre sí, las dependencias entre los equipos son inevitables en escalamiento Scrum y deben ser manejadas.

56. ¿Quién puede eliminar y reemplazar los elementos del Sprint Backlog durante el Sprint?

1. El equipo Scrum.
2. El Product Owner.
3. El Scrum Master.
4. El Development Team.
5. Nadie.

Sólo el Development Team puede modificar el Sprint Backlog a lo largo del mismo, aunque no puede modificar el objetivo del Sprint. Si hay tiempo y el Development Team ha completado todos los elementos, el equipo sacará el siguiente elemento de la parte superior del Product Backlog.

57. Scrum es una metodología que describe pasos detallados para que el software funcione.

1. Verdadero
2. Falso

Scrum no describe ningún paso detallado, y más que una metodología es un marco de trabajo.

58. ¿De los siguientes puntos cuáles dos son ciertos acerca de Scrum?

1. La duración máxima de los Sprints es de seis semanas.
2. Scrum es una metodología para gestionar proyectos complejos.
3. Es fácil de entender y difícil de dominar.
4. Scrum es el marco de trabajo dentro del cual las personas pueden abordar problemas complejos de manera adaptativa.

Scrum no es una metodología o cuerpo de conocimiento, es un marco de trabajo. Muchas organizaciones comienzan a implementar Agile en un contexto cultural que en su mayoría no es Agile. Esto crea tensiones y fricciones con las que tienen que lidiar los equipos que adoptan Agile.

Según la Guía Scrum, un Sprint es un período de tiempo de 4 semanas como máximo (puede ser menos).

59. ¿Cuál es la forma correcta de ordenar los elements del Product Backlog?

1. Ordenar elementos por su nivel de riesgo.
2. Ordenar elementos por su valor.
3. Ordenar elementos por su tamaño.
4. Ordenar elementos por la dependencias entre ellos.

Los elementos del Product Backlog se ordenan en función de su valor de negocio. El Product Owner es responsable del Product Backlog, incluido su contenido, disponibilidad y priorización. El Product Owner puede considerar el tamaño y el riesgo de los items, pero entre otros, estos son solo criterios para establecer el valor final. Los elementos deben tratar de ser independientes entre sí, para facilitar su orden de priorización.

60. ¿Qué dos enfoques debe tomar el Scrum Master cuando su equipo no tiene la infraestructura adecuada para hacer el trabajo necesario para completar los elementos seleccionados del Product Backlog?

1. Suspender el proyecto.
2. Suspender el Sprint.
3. Asesorar al Development Team para mejorar la infraestructura mientras se ajusta la Definition of Done correctamente.
4. Ayudar al Equipo Scrum a crear el Objetivo del Sprint adecuado y la Definition of Done en concordancia a las circunstancias actuales.
5. Crear un Sprint especial para obtener infraestructura en lugar de crear un incremento.

La infraestructura y las herramientas se preparan gradualmente a lo largo del proyecto, y el Objetivo del Sprint y la Definition of Done deben ser realistas y crearse en consecuencia.

61. El Sprint Backlog contiene elementos extraídos solo del Product Backlog.

1. Verdadero
2. Falso

No podemos cambiar el Objetivo del Sprint, sin embargo, el equipo puede hablar y negociar con el Product Owner para agregar nuevos elementos del Sprint Backlog según sea necesario.

62. Cada elemento del Sprint Backlog es propiedad de uno o más desarrolladores.

1. Verdadero
2. Falso

Todos los Equipos de desarrolladores comparten la propiedad de los elementos del Backlog del Sprint y sus tareas; estas tareas son asignadas a los desarrolladores por sí mismos. Además, todos los miembros del Equipo de Desarrollo comparten la responsabilidad de sus propias tareas.

63. ¿Qué significa para el Equipo de Desarrollo ser un equipo multifuncional?

1. Todos los miembros del equipo de desarrollo deben ser desarrolladores completos.
2. Todas las áreas funcionales de la organización trabajan con el Equipo de Desarrollo.
3. El Equipo de Desarrollo está integrado no solo por programadores, también puede incluir diseñadores, evaluadores, arquitectos, etc.
4. La colaboración entre los miembros del Equipo de Desarrollo debe ser muy cercana, compartiendo conocimientos.

Multifuncional significa que los profesionales en el Equipo de Desarrollo deben tener toda la experiencia para hacer el trabajo necesario a fin de entregar un Incremento potencialmente liberable del producto “Hecho o Done” al final de cada Sprint.