Unidad 3.

SCRUM

Nombre Inmaculada
Apellidos Sánchez Fernández

Conceptos de SCRUM
Equipo SCRUM
1. Acerca del papel del Equipo SCRUM, contestar a las siguientes cuestiones.
1.1 ¿Cuál de las siguientes características no corresponde a un equipo SCRUM?
a) Auto-organizado. No hay un componente externo que dé las órdenes y
controle la asignación de tareas, sino que son todos los componentes.
b) Jerárquicos. Los componentes del equipo conocen qué otro componente es
responsable de su trabajo y del que deben recibir las instrucciones.
c) Basado en roles. Cada componente tiene un papel concreto en el equipo y
para el proyecto (Scrum Máster, Product Owner y Desarrollador)
d) Multifuncional. Tienen todas las competencias para hacer el trabajo sin que
dependan de otras personas que no formen parte del equipo.
Explicación:

Se trabaja
Se trabajacolaborativamente, en equipo,
colaborativamente, y obtener
en equipo, y el mejor resultado
obtener el mejorposible para elposible
resultado proyecto.
para el proyecto.

1.2 El “SCRUM Master” no es el líder del equipo SCRUM, por lo tanto, en la reunión de “Sprint
Planning Meeting” a la hora de tomar una decisión sobre las historias que se van a pasar al
Sprint Backlog, su papel debería ser.
a) Aceptar lo que decida el equipo de desarrollo ya que ellos son los que van a
implementar las historias de usuario.
b) Defender la opinión del “Product Owner” ante el equipo de desarrollo.
c) Tiene el mismo peso de decisión que el resto de componentes del equipo
SCRUM.
d) El SCRUM Máster no asiste a la reunión del Sprint Planning Meeting.
Explicación:
El scrum
El scrumMaster
Master es un
es facilitador, es un intermediador
un facilitador, entre todosentre
es un intermediador los elementos y es el equipo
todos los
de desarrollo el que decide como implementar el proyecto.
elementos y es el equipo de desarrollo el que decide como implementar el
proyecto.

1.3 En la reunión de “Sprint Review” el “SCRUM Master” debería.

a) Facilitar que la reunión se centre en las historias de usuario que se han
logrado y no en analizar quién es el responsable.
b) Reflexionar sobre cómo ha sido el Sprint
c) Analizar uno por uno el rendimiento de cada uno de los componentes del
equipo de desarrollo.
d) El SCRUM Máster no asiste a la reunión del Sprint Review.
Explicación:
La reunión de Sprint Review consiste en revisar la funcionalidad entregada y
recoger el feedback de los stakeholders.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 1 de 10

 Unidad 3. SCRUM

1.4 En la reunión de “Sprint Retrospective” uno de los componentes del equipo de desarrollo
se centra en culpar al “Product Owner” de la no conclusión de una historia de usuario. En
concreto le culpa de haber infraestimado la carga ¿Qué debería hacer el “SCRUM Máster”?
a) Comentar que la estimación de la carga la realizaron entre todo el equipo
SCRUM, por lo que la responsabilidad de la infraestimación es de todos.
b) Comentarle al Product Owner para que la próxima vez estime mejor la carga
de la historia de usuario.
c) Comentarle al desarrollador que el Product Owner es sagrado y por tanto su
estimación de carga siempre es la correcta, si no se ha terminado la historia
de usuario es por responsabilidad del desarrollador.
d) El Scrum Máster no asiste a la reunión del Sprint Retrospective.
Explicación:
Todo el equipo es responsable de las decisiones.

1.5 En la reunión del “Daily Sprint” el “SCRUM Máster” debería…

a) Asistir como uno más del equipo de desarrollo y dejar que cada
componente hable cuando quiera y del tema que quiera.
b) Convocar la reunión todos los días a la hora y el modo en que considere
adecuado.
c) Tener actualizado el Sprint Board, iniciar la reunión, dar la palabra y cerrar
la reunión.
d) El SCRUM Máster no asiste a la reunión del Sprint Daily.
Explicación:
El scrum master no es el jefe y la reunión no es para reportarle a él. Debe ser
un facilitador y asegurarse que los objetivos se cumplen, pero es un igual.

1.6 A la hora de crear las “Historias de Usuario” el “Product Owner” debería…

a) Realizarlas por completo, incluyendo las estimaciones de carga, prioridades,
etc.
b) Redactarlas en función de su conocimiento, su contacto con el cliente (o el
usuario) y de su experiencia.
c) Proponer el nombre de la historia, la redacción es responsabilidad del
equipo de desarrollo.
d) El Product Owner no participa de la realización de las Historias de Usuario.
Explicación:
El Product Owener es quien conoce las características del producto y las
prioriza según las necesidades de la compañia.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 2 de 10

 Unidad 3. SCRUM

1.7 En una reunión de “Sprint Planning Meeting”, el “Product Owner” propone una “Historia
de Usuario” para hacer durante el Sprint. ¿De quien es la responsabilidad de hacer la
estimación de esfuerzo que conllevará implementar dicha “Historia de Usuario”?
a) Únicamente del Scrum Owner
b) Del Scrum Máster y del Scrum Owner
c) De todo el equipo sCRUM (Máster, Owner y equipo de desarrollo)
d) El Product Owner no participa de la realización del Sprint Planning Meeting.
Explicación:
No existe jerarquía en el equipo. Todos deben participar de la planificación.

1.8 ¿Puede participar el “Product Owner” en la reunión del “Daily Sprint”?

a) Sí, es obligatorio que esté en todas las reuniones del Daily Sprint
b) Puede hacerlo, y con capacidad de decisión
c) Puede hacerlo pero sólo como oyente
d) No, nunca.
Explicación:
Es una reunión de transferencia de información y colaboración entre el equipo
de desarrollo.

1.9 En una reunión del “Daily Sprint” hay que hacer referencia al “Sprint Board” ya que se está
revisando qué desarrolladores tienen que hacer un trabajo conjunto durante la jornada. ¿De
quién es responsabilidad comprobar que el “Sprint Board” está actualizado?
a) Del Scrum Master
b) Del Product Owner
c) De cualquier componente del equipo de desarrollo
d) No, nunca.
Explicación:

Ellos son los responsable de actualizar su trabajo.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 3 de 10

 Unidad 3. SCRUM

Eventos de SCRUM
2. Acerca de los eventos que SCRUM Define, contestar a las siguientes cuestiones.

2.1 Si en un proyecto hemos determinado que la duración del Sprint es de cuatro semanas.
¿Qué duración se podría recomendar para la reunión del “Sprint Planning Meeting”?
a) Máximo ocho horas
b) Mínimo ocho horas
c) Entre media hora y dos horas
d) La duración de la reunión del Sprint Planning Meeting es siempre fija y
como máximo de una hora.
Explicación:
Tiempo suficiente para cumplir con los objetivos.

2.2 Si en un proyecto hemos determinado que la duración del Sprint es de cuatro semanas.
¿Qué duración se recomienda para la reunión del “Daily Sprint”?
a) Máximo una hora
b) Mínimo una hora
c) Mínimo quince minutos
d) La duración de la reunión del Daily Sprint es siempre fija y como máximo de
quince minutos.
Explicación:
Facilitar la transferencia de información y colaboración.

2.3 ¿En qué reunión se deben determinar las historias de usuario y, consiguientemente, el
grueso de el “Product Backlog”?
a) En la reunión inicial del proyecto.
b) En el Sprint Planning Meeting.
c) El Product Backlog se va generando a medida que se van determinando
historias de usuario
d) La duración de la reunión del Daily Sprint es siempre fija y como máximo de
quince minutos.
Explicación:
En la primera reunión es donde se define el grueso del producto.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 4 de 10

 Unidad 3. SCRUM

2.4 ¿Qué reunión es opcional en SCRUM?

a) La reunion del Sprint Planning Meeting.
b) La reunión de Daily Sprint.
c) La reunión de Sprint Review
d) La reunión de Sprint Retrospective
e) No hay reuniones opcionales en SCRUM
Explicación:
Todas son necesarias.

2.5 En SCRUM ¿se puede convocar una reunión de Sprint Review a mitad de Sprint?

a) No, ya que el Sprint es auto-gestionado por el equipo de desarrollo.

b) Sí, pero sólo en casos muy justificados, y únicamente puede convocarla el
Scrum Master
c) Sí, además es obligatoria, es una de las reuniones que Scrum contempla.
d) Sí, pero sólo en casos muy justificados, y únicamente puede convocarla el
Product Owner
Explicación:
Cuando se produzcan cambios en los requisitos.

2.6 Durante un Sprint, todo el equipo de desarrollo está ocupado con una tarea que les llevará
varios días ¿conviene hacer la reunión de Daily Sprint esos días?
a) Sí, la reunión del Daily Sprint no es para revisar tareas sino el
funcionamiento del Sprint.
b) Sí, aunque si los componentes están atareados se la pueden saltar.
c) No, ya que no hay cambios de tareas.
d) No, mejor que el equipo de desarrollo se centre en la tarea y no pierda
tiempo.
Explicación:
Se hace para coordinarse entre los miembros del equipo de desarrollo.

2.7 ¿Qué pregunta de un Daily Sprint es opcional que responda un desarrollador?

a) ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Sprint Goal?
b) ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Sprint Goal?
c) ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo
logremos el Sprint Goal?
d) Ninguna de las preguntas es opcional, se debe contestar a todas, aunque
sea con “nada” o “no”.
Explicación:
El Daily sprint se hace para dar respuesta a esas preguntas.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 5 de 10

 Unidad 3. SCRUM

2.8 El concepto de “Done” en SCRUM se refiere a...

a) La forma de determinar que una reunión se finaliza.
b) La forma de determinar que un Sprint se finaliza
c) La forma de determinar que una tarea o un elemento están finalizados, la
debe conocer todo el equipo SCRUM
d) La forma de determinar que una tarea o un elemento están finalizados, la
debe conocer sólo el Product Owner y el Scrum Master
Explicación:
Se utiliza para decir que una tarea del sprint está finalizada.

Artefactos de SCRUM
3. En lo que se refiere a los artefactos de SCRUM, contestar a las siguientes preguntas.
3.1 El Sprint Board, debe contener información relativa a...
a) Todo el proyecto
b) Al Sprint, aunque puede haber información del resto del proyecto y el Sprint
sólo sea un apartado pequeño del Sprint Board
c) Al Sprint en su totalidad.
d) A la planificación de reuniones, ya que las fechas de dichas reuniones puede
cambiar.
Explicación:
Contiene las historias del sprint.

3.2 El Scrum Board, debe contener información relativa a...

a) Todo el proyecto.
b) Al Sprint actual y al siguiente.
c) Al Sprint anterior, al actual y al siguiente.
d) No existe un Scrum Board en SCRUM.
Explicación:
Unifica la información de todos los sprints.

3.3 El Planing Poker es un método que se emplea para la torma de decisiones, en SCRUM
concretamente se usan para (entre otras cosas) estimar la carga de esfuerzo de una historia de
usuario. A la hora de estimar dicha carga ¿qué componentes del equipo SCRUM deben
participar en el juego?
a) El equipo de desarrollo junto al Product Owner, pero no el Scrum Máster
b) El equipo de desarrollo junto al Scrum Máster pero no el Product Owner
c) Todos, incluido Product Owner y Scrum Máster
d) Sólo el Equipo de Desarrollo.
Explicación:
Sirve para realizar las estimaciones del sprint.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 6 de 10

 Unidad 3. SCRUM

3.4 Acerca del “Product Backlog” ¿Cuál de las siguientes afirmaciones es correcta?
a) Es un conjunto de todo lo que es necesario para implementar el producto
(por tanto, no hay orden) especificado de una forma muy general.
b) Es una lista ordenada de todo lo que es necesario para implementar el
producto, siendo la única fuente de requisitos.
c) Es una lista ordenada de todo lo que es necesario para implementar el
producto, pero puede haber más fuentes de requisitos.
d) No se puede actualizar una vez se ha puesto en marcha el desarrollo del
producto.
Explicación:
Es una lista ordenada de historias de usuario, pero no contiene el detalle de las
historias.

3.5 Acerca del “Sprint Backlog” ¿Cuál de las siguientes afirmaciones es correcta?
a) Es el subconjunto de elementos del Product Backlog que sólo pueden
visualizar el Equipo de Desarrollo.
b) Es el conjunto de nuevos elementos que aparecen durante un Sprint y que
se incorporarán al Product Backlog al final del Sprint.
c) Es un conjunto de Historias de Usuario que todavía no se ha incorporado al
ProductBacklog.
d) Es un subconjunto de elementos del Product Backlog que se han
seleccionado para un Sprint Concreto.
Explicación:
Se utiliza para los elementos del sprint concreto que se está realizando.

3.6 ¿Qué información proporciona el BurnDown Chart?

a) Proporciona el esfuerzo invertido en las historias de usuario de las que se
compone dicho proyecto.
b) Proporciona el trabajo o esfuerzo pendiente en un Sprint
c) Proporciona las horas de trabajo de cada uno de los componentes del
equipo de desarrollo
d) Proporciona las horas dedicadas a cada historia de usuario en un Sprint.
Explicación:
Trabajo/esfuerzo pendiente del sprint.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 7 de 10

 Unidad 3. SCRUM

3.7 ¿Qué podemos deducir del siguiente BurnDown Chart?

a) Es un Sprint sin altibajos que se ha mantenido con un esfuerzo similar al

planeado, con un poco de esfuerzo extra al final.
b) Es un Sprint que ha costado menos esfuerzo del que se suponía ideal.
c) Es un Sprint que se ha terminado dos días antes de lo previsto.
d) Es un Sprint mal estimado puesto que se han invertido muchas más horas
de las que se consideraron ideales.
Explicación:
Al prinicio el esfuerzo coincide con el estimado, tenemos un pico de mayor
esfuerzo para luego continuar con ejecución similar a la estimada, terminamos
con un pico para alcanzar el objetivo.

3.8 ¿En cuál de los siguientes Burn Down Charts se ha producido un parón a mitad de Sprint?
a) b)

c) d)

Explicación:
En realidad el parón se produce desde el día 2, siendo el número total de 0
hasta llegar al final.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 8 de 10

 Unidad 3. SCRUM

3.9 ¿En cuál de los siguientes Burn Down Charts se ha producido una planificación en la que se
estimó más trabajo del que realmente fue necesario?
a) b)

c) d)

Explicación:
La linea actual está por debajo de lo planificado desde el día 3.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 9 de 10

 Unidad 3. SCRUM

Usando Artefactos (ejercicios opcionales)

Burndown Chart
4. En un proyecto gestionado por medio de SCRUM, estamos en la reunión de Sprint Planning
Meeting. Y se han generado 10 tareas de ocho horas para realizar en 10 días 1 (dos semanas
laborales). A partir del documento “U03.4-SCRUM-actividades-Burndown chart.xlsx”, rellenar
las celdas de cada día según los siguientes escenarios.

4.1 Escenario en que el día 9 terminamos antes de tiempo las tareas 1.3 y 2.1.

4.2 Escenario en que el las tareas 1.2 y 1.3, no se terminan hasta el día 7. La tarea 2.1 se
termina el día 6. Estimando siempre (los días anteriores) que la duración resultante es de 8
horas.

4.3 El siguiente escenario en el que se detallan las horas estimadas restantes.

Día Horas invertidas Horas estimadas restantes

Día 10 4 horas en la Tarea 1.1 5 horas para la Tarea 1.1
4 horas en la tarea 1.2 4 horas para la Tarea 1.2
Día 9 5 horas en la Tarea 1.1 y la terminamos. 10 horas para la Tarea 1.3
4 horas en la Tarea 1.2 y la terminamos.
Día 8 10 horas en la Tarea 1.3 y la terminamos
Día 7 4 horas en la Tarea 2.1. 3 horas para la Tarea 2.1
4 horas en la Tarea 2.2 4 horas para la Tarea 2.2.
1 hora en la Tarea 3.1 2 horas para la Tarea 3.1
Día 6 3 horas en la Tarea 2.1 y la terminamos 4 horas para la Tarea 2.2
4 horas en la Tarea 2.2
1 hora en la Tarea 3.1 2 horas para la Tarea 3.1
Día 5 4 horas en la Tarea 2.2 y la terminamos
1 hora en la Tarea 3.1 2 horas para la Tarea 3.1
Día 4 6 horas en la Tarea 3.2 y la terminamos
1 hora en la Tarea 3.1 3 horas para la Tarea 3.1
Día 3 8 horas en la Tarea 3.3 y la terminamos
Día 2 8 horas en la Tarea 4.1 1 horas para la Tarea 4.1
2 horas en la Tarea 3.1 y la terminamos
Día 1 1 hora en la Tarea 4.1 y la terminamos
7 horas en la Tarea 4.2 y la terminamos

Gestión de historias de usuario (opcional)

5. Crear una cuenta (es gratuita para un solo usuario) de ScrumDesk (www. scrumdesk.com)
y transformar las historias del ejercicio anterior en las tarjetas correspondientes.

1
Evidentemente esto es un caso ideal para poder “jugar” con las cifras en el ejercicio, la realidad es que
las tareas son variables de un Sprint a otro y que la duración de una tarea, no es habitual que sea la
misma que la de otra dentro del mismo Sprint.

Módulo de Metodologías Ágiles. Jose Luis Poza Luján (www.jopolu.net) Página 10 de 10