Kit de estudio de agilidad

Autor: Janneth Lorena Torres Valencia

Visión general de Scrum

Scrum es un marco de trabajo por

el cual las personas pueden
abordar problemas complejos
adaptativos, a la vez que entregar
productos del máximo valor posible
productiva y creativamente.

Scrum es:

• Liviano
• Fácil de entender
• Difícil de dominar

Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el trabajo
en productos complejos desde principios de los 90. Scrum no es un proceso, una técnica
o método definitivo. En lugar de eso, es un marco de trabajo dentro de lo cual se pueden
emplear varios procesos y técnicas. Scrum muestra la eficacia relativa de las técnicas
de gestión de producto y las técnicas de trabajo de modo que podamos mejorar
continuamente el equipo y el entorno de trabajo.

El marco de trabajo scrum consiste en los equipos scrum y sus roles, eventos, artefactos
y reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propósito
específico y esencial para el éxito de scrum y para su uso.

Las reglas de scrum relacionan los principios, aspectos y procesos y rigen las relaciones
e interacciones entre ellos. Las reglas de scrum se describen en el presente documento.

Las estrategias específicas para usar el marco de trabajo scrum son diversas y están
descritas en otros lugares.

Esto caballeros….. es scrum

 Usos de scrum

Scrum fue desarrollado inicialmente para gestionar y desarrollar productos. Desde

principios de los 90 Scrum se ha usado ampliamente en todo el mundo para:

• Investigar e identificar
mercados viables, tecnologías y
capacidades de productos.
• Desarrollar productos y
mejoras
• Liberar productos y mejoras
tantas veces como sea posible
durante el día
• Desarrollar y mantener
ambientes en la Nube (en línea,
seguros, bajo demanda) y otros
entornos operacionales para el
uso de productos
• Mantener y renovar
productos.

“Los individuos marcan goles, pero los equipos ganan

partidos”

Scrum se ha usado para desarrollar software, Hardware, software embebido, redes de

funciones interactivas, vehículos autónomos, escuelas, gobiernos, mercadeo, también
para gestionar la operación de organizaciones y casi todo lo que usamos en nuestra
vida diaria, como individuo y como sociedad.

Dado que la complejidad de la tecnología, el mercado y del entorno y sus interacciones

aumentan rápidamente, la utilidad de scrum para tratar con la complejidad está a prueba
diariamente.

Scrum demostró ser especialmente efectivo en la transferencia iterativa e incremental

de conocimiento. scrum se usa ahora ampliamente para productos, servicios y gestión
de la organización matriz.

Un gran equipo Scrum consiste en un Propietario de Producto (Product Owner) que

maximiza el valor, un Maestro Scrum (Scrum Master) que permite la mejora continua y
un Equipo de Desarrollo (Development Team) que se enfoca en entregar incrementos
de productos de alta calidad.

Scrum es un marco de trabajo en el que las personas pueden abordar problemas complejos
y desarrollar de manera productiva y creativa productos del mayor valor posible.
 La esencia de Scrum es un pequeño equipo de personas.
El equipo es altamente flexible y adaptativo. Ellos
vivencian los principios de SCRUM

• Auto-organización
• Colaboración
• Control de proceso Empírico
• Time Boxing
• Priorización basada en Valor
• Desarrollo Iterativo
Significado de scrum

Los principios de Scrum.

¿Qué mensaje te deja el video?

¿Porque Adam Smith se equivocó?
Cuando el equipo Scrum incorpora y
vivencia los valores: auto-organización,
priorización basada en valor, time boxing,
control del proceso empírico y
colaboración, se garantiza el uso exitoso de
scrum. Las personas se comprometen de
manera individual a alcanzar las metas del
Equipo Scrum. Los miembros del Equipo
Scrum tienen coraje para hacer bien las
cosas y para trabajar en los problemas
difíciles. Todos se enfocan en el trabajo del
Sprint y en las metas del Equipo Scrum. El
Equipo Scrum y sus interesados acuerdan
estar abiertos a todo el trabajo y a los
desafíos que se les presenten al realizar su
trabajo. Los miembros del equipo Scrum se
respetan entre sí para ser personas
capaces e independientes. Es muy
importante entender que significa ser un
equipo competitivo.

En SCRUM es muy importante que los miembros del equipo tengan experiencia en el
proyecto, ya que es la experiencia y el conocimiento empírico lo que garantiza el
cumplimiento de los pilares Scrum de transparencia, inspección y adaptación.
Teoría de Scrum

Scrum se basa en la teoría de control de procesos empírica o empirismo, El empirismo

asegura que el conocimiento procede de la experiencia y de tomar decisiones
basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para
optimizar la predictibilidad y el control de riesgo.

Tres pilares soportan

toda la implementación
del control de procesos
empírico: transparencia,
inspección y adaptación.

Control de proceso empírico - Transparencia

•La transparencia permite que todas las facetas de cualquier proceso de Scrum sean
observadas por cualquiera, esto promueve un flujo de información fácil y transparente
en toda la organización y crea una cultura de trabajo abierta. Aquellos que
desempeñan el trabajo y quienes inspeccionan al incremento resultante deben
compartir una definición común “terminado”.

Control de proceso empírico - Inspección

•La inspección en Scrum se representa mediante lo siguiente:

•Uso de un Scrumboard común y otros emisores de información que muestran el

progreso del Equipo Scrum en completar las tareas del sprint actual.

•Recopilación de la retroalimentación del cliente y otros stakeholders durante los

procesos de Desarrollar de épica(s), Crear Backlog Priorizado del Producto y Realizar
planificación del lanzamiento.

•La inspección y aprobación de los entregables por parte del Product Owner y el cliente
en el proceso de Demostrar y validar el sprint.

Control de proceso empírico - Adaptación

•Si un inspector determina que uno o más aspectos de un proceso desvían de límites
aceptables y que el producto resultante será inaceptable, el proceso o el material que
está siendo procesado deben ajustarse. Dicho ajuste debe realizarse cuanto antes para
minimizar desviaciones mayores.
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la
inspección y adaptación, tal y como se describen en la sección Eventos de Scrum del
presente documento.

• Planificación del Sprint (Sprint Planning)

• Scrum Diario (Daily Scrum)
• Revisión del Sprint (Sprint Review)
• Retrospectiva del Sprint (Sprint Retrospective)

Transparencia
Inspección
Adaptación

Dimensiones centrales del trabajo colaborativo

Conocimiento: Las personas que

trabajan juntas deben estar al tanto
del trabajo de los demás.

Articulación: Los colaboradores

Apropiación: Adaptar la tecnología
a la situación individual; la
tecnología se puede utilizar de
forma completamente distinta a lo
esperado por los diseñadores.
deben distribuir el trabajo en
unidades; dividir las unidades entre
los miembros del equipo y después
reintegrarlo cuando el trabajo esté
hecho.
El Equipo Scrum (Scrum Team).

El Equipo Scrum consiste en un Dueño

de Producto (Product Owner), el equipo
de desarrollo (Development Team) y un
Scrum Master. Los equipos Scrum son
autoorganizados y multifuncionales. Los
equipos autoorganizados eligen la mejor
forma de llevar a cabo su trabajo y no
son dirigidos por personas externas al
equipo. Los equipos multifuncionales
tienen todas las competencias
necesarias para llevar a cabo el trabajo
sin depender de otras personas que no
son parte del equipo. El modelo de
equipo en Scrum está diseñado para
optimizar la flexibilidad, la creatividad y
la productividad. El equipo de Scrum ha
demostrado ser cada vez más efectivo
para todos los usos anteriores y
cualquier trabajo complejo.

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando

las oportunidades de obtener retroalimentación. Las entregas incrementales de
producto “Terminado” aseguran que siempre estará disponible una versión
potencialmente útil y funcional del producto.

El Dueño de Producto (Product Owner).

El Dueño de Producto es el responsable de maximizar el valor del producto resultante

del trabajo del Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar
ampliamente entre distintas organizaciones, Equipos Scrum e individuos.

El dueño de Producto es la única persona responsable de gestionar la Lista del Producto

(Product Backlog). La gestión de la lista del Producto incluye:

• Expresar claramente los elementos de la lista de

producto
• Ordenar los elementos en la Lista de producto para
alcanzar los objetivos y misiones de la mejor manera
posible;
• Optimizar el valor del trabajo que el Equipo de
Desarrollo realiza;
• Asegurar que la Lista del Producto es visible;
transparente y clara para todos y que muestra aquello
en lo que el equipo trabajará a continuación; y,
• Asegurar que el Equipo de Desarrollo entiende los
elementos de la Lista del Producto al nivel necesario.
El dueño de Producto podría hacer el trabajo anterior o delegarlo en el Equipo de
Desarrollo. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el
responsable de dicho trabajo.

El Dueño de Producto es una única persona, no un comité. El Dueño de Producto podría

representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran
cambiar la prioridad de un elemento de la Lista deben hacerlo a través del Dueño de
Producto.

Para que el Dueño de Producto pueda hacer bien su trabajo, toda la organización debe
respetar sus decisiones. Las decisiones del Dueño de Producto se reflejan en el
contenido y en la priorización de la lista de Producto. Nadie puede forzar al Equipo de
Desarrollo a que trabaje con base en un conjunto diferente de requisitos.

Un gran Product Owner…

• Adopta, comparte y socializa la visión del producto. Un gran Propietario de

Producto representa la voz de los clientes y crea una visión de producto junto
con las partes interesadas. Cada decisión se toma teniendo en cuenta la visión
del producto. Esto asegura el desarrollo sostenible del producto, proporciona
claridad al equipo de desarrollo y aumenta drásticamente las posibilidades de
éxito del producto.
• Excede las expectativas del cliente. Un gran Propietario de Producto
realmente entiende las intenciones y objetivos del cliente con el producto y es
capaz de superar sus expectativas. La satisfacción del cliente es el objetivo final!
• Tiene poder. Un gran Propietario de Producto está facultado para tomar
decisiones relacionadas con el producto. Sin duda, la creación de apoyo para
sus decisiones puede tomar algún tiempo, pero la rápida toma de decisiones
importantes es una condición primordial para un ritmo sostenible del equipo de
desarrollo.
• Ordena y prioriza el backlog del producto. Un gran Propietario de Producto
entiende que el producto atrasado debe ser ordenado. Prioridad, riesgo, valor,
oportunidades de aprendizaje y dependencias se toman en cuenta y se
equilibran entre sí. Por ejemplo, cuando se construye una casa, el techo puede
tener la prioridad más alta considerando posibles lluvias. Pero todavía es
necesario realizar los cimientos y las paredes más temprano y por lo tanto
ordenarlos sobre la construcción del techo.
• Prefiere la comunicación cara a cara. Un gran Propietario de Producto
entiende que la mejor manera de transmitir información es la comunicación cara
a cara. Las historias de los usuarios se explican en una conversación personal.
Si se utiliza una herramienta para la gestión de atrasos, su función es apoyar el
diálogo. Nunca reemplaza a la conversación tradicional.
• Conoce las técnicas de modelado. Un gran Dueño de Producto tiene una
mochila llena de valiosas técnicas de modelado. Sabe cuándo aplicar un modelo
específico. Algunos ejemplos son la generación de modelos de negocio, la
puesta en marcha Lean o el mapeo de impacto. Basado en estos modelos, él
sabe cómo impulsar el éxito del producto.
• Comparte experiencias. Un gran Propietario de Producto comparte
experiencias con sus compañeros. Esto podría ser dentro y fuera de la
organización: los seminarios y conferencias son una gran manera de compartir
experiencias y de reunir conocimientos. Además, anotar las lecciones
aprendidas puede ser valioso para otros propietarios de productos.
• Posee el mapa de la historia del usuario (User Story Mapping). Un gran
Propietario de Producto debe dominar el concepto de mapeo de historias de
usuario. Es una técnica que le permite añadir una segunda dimensión a su
cartera de pedidos. La visualización le permite ver el cuadro completo de la
cartera de pedidos del producto. Jeff Patton escribió un excelente material sobre
el concepto de mapeo de historias.
• Se centra en la funcionalidad. Un gran Propietario de Producto tiene un
enfoque en la funcionalidad y los aspectos no funcionales del producto. Las
horas o incluso los puntos de la historia son menos importantes. El objetivo del
Propietario de Producto es maximizar el valor para el cliente. Es la funcionalidad
la que tiene valor; por lo tanto, este es el enfoque principal para el Propietario de
Producto.
• Tiene conocimientos. Un gran Propietario de Producto tiene un profundo
conocimiento del producto (no)funcional y entiende la composición técnica. Para
los productos grandes puede ser difícil entender todos los detalles, y escalar el
rol del Propietario de Producto puede ser una opción. Sin embargo, el Propietario
de Producto siempre debe conocer las piezas más grandes del rompecabezas y
por este medio tomar decisiones conscientes y sólidas.
• Entiende el dominio de los negocios. Un gran Propietario de Producto
entiende el dominio y el entorno del que forma parte. Un producto siempre debe
construirse teniendo en cuenta su contexto. Esto incluye entender la
organización que paga por el desarrollo, pero también estar al tanto de las
últimas condiciones del mercado. Enviar un producto impresionante después de
que la ventana de la oportunidad se cierra es absolutamente inútil.
• Actúa en diferentes niveles. Un gran Propietario de Producto sabe cómo actuar
en diferentes niveles. La forma más común de definir estos niveles es
estratégica, táctica y operativa. Un Propietario de Producto debe saber cómo
explicar la estrategia del producto a nivel de junta directiva, crear soporte en la
gerencia media y motivar al equipo de desarrollo con sus retos diarios.
• Conoce los 5 niveles de planificación ágil. Dentro de Agile, la planificación se
hace continuamente. Cada producto necesita una visión (nivel 1) que
proporcione información a la hoja de ruta del producto (nivel 2). La hoja de ruta
es un plan estratégico a largo plazo sobre la evolución del producto. Basándose
en la hoja de ruta, las condiciones del mercado y el estado del producto, el
Propietario de Producto puede planificar liberaciones (nivel 3). Durante la
planificación de Sprint (nivel 4) el equipo planifica y acuerda los ítems atrasados
del Producto que están seguros de que pueden completar durante el Sprint y
ayudarles a alcanzar la Meta de Sprint. El Scrum Diario (nivel 5) se utiliza para
inspeccionar y adaptar el progreso del equipo hacia la realización de la Meta
Sprint.
• Está disponible. Un gran Propietario de Producto está disponible para las partes
interesadas, los clientes, el equipo de desarrollo y el Scrum Master. Las
preguntas importantes se contestan rápidamente y se proporciona información
valiosa a tiempo. El propietario del producto se asegura de que su disponibilidad
nunca bloquee el progreso del equipo de desarrollo.
El Scrum Master.

El Scrum Master es responsable de promover y apoyar Scrum

como se define en la guía de Scrum. Los Scrum Master hacen
esto ayudando a todos a entender la teoría, prácticas reglas y
valores de Scrum.

El Scrum Master es un líder que está al servicio del Equipo

scrum. el scrum master ayuda a las personas externas al
equipo scrum a entender que interacciones con el equipo
scrum puede ser útiles y cuáles no. el scrum master ayuda a
todos a modificar estas interacciones para maximizar el valor
creado por el equipo scrum.

Un gran Scrum Master…

• Involucra al equipo con la configuración del proceso. Un gran Scrum Master

asegura que todo el equipo apoya el proceso Scrum elegido y entiende el valor
de cada evento. El Scrum diario, por ejemplo, se planifica en un momento
adecuado para todos los miembros del equipo. Una preocupación común acerca
de Scrum es la cantidad de «reuniones», involucrando al equipo con la
planificación de los eventos y discutiendo el resultado deseado aumentará el
compromiso seguro.
• Entiende el desarrollo de equipos. Un gran Scrum Master es consciente de
las diferentes fases por las que pasará un equipo cuando trabaje en equipo.
Entiende las diferentes etapas de Tuckman en el desarrollo del equipo:
formación, asalto, normalización, actuación y aplazamiento. Por lo tanto, la
importancia de una composición estable del equipo también es evidente.
• Entiende que los principios son más importantes que las prácticas. Sin una
comprensión sólida y respaldada de los principios ágiles, toda práctica
implementada es básicamente inútil. Es una cáscara vacía. Una comprensión en
profundidad de los principios ágiles por parte de todos los involucrados
aumentará las posibilidades de un uso exitoso de las prácticas drásticamente.
• Reconoce y actúa en conflictos de equipo. Un gran Scrum Master reconoce
el conflicto de equipo en una etapa temprana y puede aplicar diferentes
actividades para resolverlo. Un gran Maestro Scrum entiende que el conflicto no
es necesariamente incorrecto. Un conflicto sano y un desacuerdo constructivo
pueden ser utilizados para construir un equipo aún más fuerte.
• Se atreve a interrumpir. Un gran Maestro Scrum entiende que algunos cambios
sólo ocurrirán cuando sean disruptivos. Sabe cuándo es necesario y está
preparado para ser lo suficientemente perturbador como para imponer un cambio
dentro de la organización. Un gran Scrum Master puede tener un impacto en la
cultura de la organización para que los equipos Scrum puedan realmente
florecer. Entiende que cambiar el comportamiento de la gente no se trata de
cambiar a las personas, sino de cambiar el contexto en el que se encuentran.
• Es prescindible y buscado. Un gran Scrum Master ha apoyado el crecimiento
de los equipos de tal manera que ya no lo necesitan diariamente. Pero debido a
su contribución comprobada, se le pedirá consejo frecuentemente. Su papel ha
cambiado de entrenador y profesor diario a mentor y consejero periódico.
• Deja que su equipo falle (ocasionalmente). Un gran Scrum Master sabe
cuándo evitar que el equipo falle, pero también entiende cuándo no debería
impedirlo. Las lecciones aprendidas después de un error pueden ser más
valiosas que algunos buenos consejos de antemano.
• Fomenta la apropiación. Un gran Scrum Master anima y entrena al equipo para
que asuma la responsabilidad de su proceso, tarea, muro y entorno.
• Tiene fe en la auto-organización. Un gran Maestro Scrum entiende el poder de
un equipo auto-organizado. «Tráelo al equipo» es su lema diario. Los atributos
de los equipos auto-organizados son que los empleados reducen su
dependencia de la gerencia y aumentan la propiedad del trabajo. Algunos
ejemplos son: ellos toman sus propias decisiones sobre su trabajo, estiman su
propio trabajo, tienen una fuerte voluntad de cooperar y los miembros del equipo
sienten que se están uniendo para lograr un propósito común a través de metas
de liberación, metas de sprint y metas de equipo.
• Ritmo de valores. Un gran Scrum Master entiende el valor de un ritmo sprint
constante y hace todo lo posible para crearlo y mantenerlo. El ritmo del sprint
debe convertirse en el latido del equipo, que no cuesta energía. Todo el mundo
conoce la fecha, hora y propósito de cada evento Scrum. Saben lo que se espera
y cómo prepararse. Por lo tanto, un enfoque completo en el contenido es posible.
• Conoce el poder del silencio. Un gran Scrum Master sabe escuchar
verdaderamente y se siente cómodo con el silencio. No hablando, sino
escuchando. Es consciente de los tres niveles de la escucha -escucha interna
de nivel 1, escucha centrada de nivel 2, escucha global de nivel 3, y sabe cómo
usarlos. Escucha atentamente lo que se dice, pero también lo que no se dice.
• Observa. Un gran Maestro Scrum observa a su equipo con sus actividades
diarias. No tiene un papel activo en cada sesión. El diario Scrum, por ejemplo,
está en manos del equipo para el equipo. Observa la sesión y por este medio
tiene una visión más clara de lo que se está discutiendo (y lo que no se está
discutiendo) y cuál es el papel de cada uno durante la presentación.
• Comparte experiencias. Great Scrum Masters comparte experiencias con sus
compañeros. Esto puede ser dentro de la organización, pero también los
seminarios y conferencias son una gran manera de compartir experiencias y
reunir conocimientos. Por supuesto, escribir y compartir sus lecciones
aprendidas también es muy apreciado. Y sí, para los lectores atentos, esto es
exactamente lo mismo que para el propietario del producto y el equipo de
desarrollo.
• Tiene una mochila llena de diferentes formatos de retrospectivas. Un gran
Scrum Master puede aplicar muchos formatos retrospectivos diferentes. Esto
asegura que la retrospectiva será un evento divertido y útil para el equipo. Sabe
qué formato es el más adecuado para la situación del equipo. Aún mejor: apoya
al equipo organizando su propia retrospectiva para mejorar la participación.
El Equipo de Desarrollo (Development Team).

El equipo de Desarrollo consiste en los profesionales que realizan

el trabajo de entregar un incremento de producto “Terminado” que
potencialmente se pueda poner en producción al final de cada
sprint. Un incremento “Terminado” es obligatorio en la Revisión de
Sprint. Solo los miembros del Equipo de Desarrollo participan en la
creación de incremento.

La organización es la encargada de estructurar y empoderar a los

Equipos de Desarrollo para que estos organicen y gestionen su
propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad
del Equipos de Desarrollo.

Un gran equipo de desarrollo

• Busca la excelencia técnica. Los Grandes Equipos de Desarrollo utilizan la

Programación Extrema como fuente de inspiración. XP proporciona prácticas y
reglas que giran en torno a la planificación, diseño, codificación y pruebas.
Ejemplos de ello son la refactorización (sensibilización continua del código), la
programación de pares, la integración continua (los programadores fusionan su
código en una línea base de código cuando tienen una construcción limpia que
ha superado las pruebas de la unidad), las pruebas de unidad (código de prueba
a nivel de desarrollo) y las pruebas de aceptación (estableciendo pruebas de
aceptación específicas).
• Aplica el enjambre del equipo. Los Grandes Equipos de Desarrollo dominan el
concepto de «equipo enjambre». Este es un método de trabajo en el que un
equipo trabaja con sólo unos pocos elementos a la vez, preferiblemente incluso
con un solo elemento a la vez. Cada artículo se termina lo más rápido posible
haciendo que muchas personas trabajen juntas en él, en lugar de tener una serie
de entregas.
• Utiliza soluciones de puntas. Un spike es una actividad concisa y
cronometrada que se utiliza para descubrir el trabajo necesario para realizar una
gran tarea ambigua. Great Development Teams utiliza experimentos de spike
para resolver problemas técnicos, arquitectónicos o de diseño desafiantes.
• Perfecciona la cartera de pedidos como equipo. Los Grandes Equipos de
Desarrollo consideran el refinamiento de la cartera de pedidos como un esfuerzo
de equipo. Entienden que la calidad de la cartera de pedidos es la base para un
desarrollo sostenible y la creación de grandes productos. Aunque el Propietario
de Producto es responsable de la cartera de pedidos del producto, todo el equipo
debe perfeccionarlo.
• Respeta la regla del Boy Scout. Los Grandes Equipos de Desarrollo usan la
Regla Boy Scout: siempre deje el campamento más limpio de lo que lo encontró.
Traducido al desarrollo de software: siempre deje la base de códigos en un
estado mejor del que ha encontrado. Si encuentras el código desordenado,
límpialo, independientemente de quién haya hecho el desorden.
• Critica las ideas, no a la gente. Los Grandes Equipos de Desarrollo critican las
ideas, no a la gente.
• Compartir experiencias. Los Grandes Equipos de Desarrollo comparten
experiencias con sus pares. Esto puede ser dentro de la organización, pero
también los seminarios y conferencias son una gran manera de compartir
experiencias y reunir conocimientos. Por supuesto, escribir y compartir sus
lecciones aprendidas también es muy apreciado. Y sí, para los lectores atentos,
esto es exactamente lo mismo que para el propietario del producto.
• Entiende la importancia de tener un poco de holgura. Los Grandes Equipos
de Desarrollo tienen cierta holgura en su sprint. Los seres humanos no pueden
ser productivos todo el día.
• Necesitan tiempo para relajarse, charlar en la cafetera o jugar al futbolín.
Necesitan cierta holgura para ser innovadores y creativos. Necesitan tiempo para
divertirse. De este modo, garantizan una alta motivación y la máxima
productividad. Pero la holgura también es necesaria para manejar las
emergencias que puedan surgir; usted no quiere que todo su sprint se meta en
problemas cuando necesite crear un hot-fix. Por lo tanto: ¡Construye un poco de
holgura! Y cuando el sprint no contiene ninguna emergencia: ¡genial! Esto le da
al equipo la oportunidad de refactorización y diseño emergente. Es un ganar-
ganar!
• Se divierten el uno con el otro. Los Grandes Equipos de Desarrollo se
aseguran de que una dosis saludable de diversión esté presente todos los días.
Fomentar la diversión, la energía, la interacción y la colaboración crea un
ambiente en el que el equipo florecerá!
• No tiene reuniones innecesarias. Los Grandes Equipos de Desarrollo
consideran los eventos Scrum como oportunidades para conversaciones. Tobias
Mayer lo describe perfectamente en su libro’ The Peoples Scrum’:»Scrum se
centra en las personas, y la gente tiene conversaciones. Hay conversaciones
para planificar, alinear y reflexionar. Tenemos estas conversaciones en el
momento oportuno, y por las duraciones adecuadas para informar nuestro
trabajo. Si no tenemos estas conversaciones, no sabremos lo que estamos
haciendo (planificando), no sabremos hacia dónde vamos (alineación) y
seguiremos repitiendo los mismos errores (reflexión).».
• Conoce a su cliente. Los Grandes Equipos de Desarrollo conocen a su
verdadero cliente. Están en contacto directo con ellos. Ellos realmente entienden
lo que desean y por lo tanto son capaces de tomar las decisiones (técnicas)
correctas.
• Puede explicar el valor (empresarial) de los requisitos no funcionales. Los
Grandes Equipos de Desarrollo entienden la importancia de los requisitos no
funcionales como, por ejemplo, rendimiento, seguridad y escalabilidad. Ellos
pueden explicar el valor (empresarial) a su Propietario de Producto y cliente y
por la presente asegurar su parte del producto atrasado.
• Confíen el uno en el otro. Los Grandes Equipos de Desarrollo confían el uno
en el otro. Sí, esto es obvio. Pero sin confianza es imposible para un equipo
lograr la grandeza.
• Mantiene la diversión durante la retrospectiva. Los Grandes Equipos de
Desarrollo piensan en formatos retrospectivos. Ellos apoyan al Scrum Master
con formatos creativos, divertidos y útiles y se ofrecen para facilitar las sesiones
ellos mismos.
 • Entregar características durante el sprint. Los Grandes Equipos de Desarrollo
ofrecen características continuamente. Básicamente ya no necesitan sprints. La
retroalimentación se recopila y procesa cada vez que un artículo se hace; esto
crea un flujo de entrega continua.

Los Equipos de Desarrollo tienen las siguientes características:

• Son autoorganizados. Nadie (ni siquiera el Scrum

Master) indica al Equipos de Desarrollo cómo convertir
elementos de la lista de Producto en Incrementos de
funcionalidad potencialmente desplegables;
• Los equipos de Desarrollo son multifuncionales,
esto es, como equipo cuentan con todas las
habilidades necesarias para crear un Incremento de
producto;
• Scrum no reconoce títulos para los miembros de un
Equipos de Desarrollo
• independientemente del trabajo que realice cada
persona;
• Scrum no reconoce subequipos en los equipos de
desarrollo, no importa los dominios que requieran
tenerse en cuenta, como pruebas, arquitectura,
operaciones o análisis de negocio; y,
• Los Miembros individuales del Equipos de
Desarrollo pueden tener habilidades especializadas y
áreas en las que están más enfocadas, pero la
responsabilidad recae en el equipo de Equipos de
Desarrollo como un todo.

Tamaño del equipo de Equipos de Desarrollo.

El tamaño óptimo del Equipos de Desarrollo es lo suficientemente pequeño como

permanecer ágil y lo suficientemente grande como para completar una cantidad de
trabajos significativa. Tener menos de tres miembros en el Equipos de Desarrollo reduce
la interacción y resulta en ganancias de productividad más pequeñas. Los equipos de
Equipos de Desarrollo más pequeños podrían encontrar limitaciones en cuanto a las
habilidades necesarias durante un Sprint, haciendo que el Equipo de Desarrollo no
pudiese entregar un incremento que potencialmente se pueda poner en producción.
tener más de 9 miembros en el equipo requiere demasiada coordinación. Los grandes
equipos de desarrollo generan demasiada complejidad como para que un proceso
empírico le sea de utilidad. Los roles de dueño de producto y Scrum master no cuentan
en el cálculo del tamaño del equipo al menos que también están contribuyendo a trabajar
en la lista de Pendientes de Sprint (Sprint Backlog).
 •Asegurar que los objetivos, el alcance del dominio del producto sean
entendidos por todos en el equipo scrum de la mejor manera posible;
•Encontrar técnicas para gestionar la lista de producto de manera
EL SERVICIO DEL efectiva;
•Ayudar al equipo SCRUM de entender la necesidad de contar con
elementos de lista de productos claros y concisos;
SCRUM MASTER •Entender la planificación del producto en un entorno empírico;
•Asegurar que el dueño del producto conozca cómo ordenar la lista de
AL DUEÑO DEL producto para maximizar el valor;
•Entender y practicar la agilidad; y,
PRODUCTO. •Facilitar los eventos de scrum según se requiera o necesite

EL SERVICIO DEL •Guiar al equipo de desarrollo en ser auto organizado y multifuncional;

•Ayudar al equipo de desarrollo a crear producto de alto valor;
SCRUM MASTER •Eliminar impedimentos para el progreso del equipo de desarrollo;
•Facilitar los eventos de Scrum según se requiera o necesite; y,
AL EQUIPO DE •Guiar al equipo de desarrollo en entornos organizacionales, en los que
scrum aún no haya sido adoptado y entendido por completo.
DESARROLLO.

EL SERVICIO DEL •Liderar y guiar a la organización en la adopción de scrum;

•Planificar las implementaciones de Scrum en la organización;
SCRUM MASTER •Ayudar a los empleados e interesados a entender y llevar a cabo scrum
y el desarrollo empírico de producto;
A LA •Motivar cambios que incrementan la productividad del equipo SCRUM
•Trabajar con otros Scrum Masters para incrementar la efectividad de la
ORGANIZACIÓN aplicación de SCRUM en la organización.
MATERIAL DE APOYO

Código QR Video

Roles de Scrum

Equipo de Desarrollo

Scrum Master

Product Owner
Aspectos SCRUM

Historia de Usuario

Las historias de usuario, son pequeñas

descripciones de los requerimientos de un
cliente. Su utilización es común cuando se
aplica marcos de entornos ágiles como
Scrum. Al redactar las historias de
usuario se debe tener en cuenta describir
el Rol, la funcionalidad y el resultado
esperado en una frase corta. Debe venir
acompañada (al reverso) de los criterios
de aceptación, hasta un máximo de 4 por
historia, redactado también en una frase
que indique el contexto, el evento y el
comportamiento esperado ante ese
evento.
Es deseable que las historias de usuario sean escritas por el
usuario, en una frase corta. Debe describir el rol desempeñado por
el usuario de forma explícita e indicar el beneficio para el área de negocio que representa
esta funcionalidad.

Eventos SCRUM

En SCRUM existen eventos predefinidos

con el fin de crear regularidad y minimizar la
necesidad de reuniones no definidas en
Scrum. Todos los eventos son bloques de
tiempo (Time - Boxes), de tal modo que
todos tienen una duración máxima. Una vez
comienza un Sprint, su duración es fija y no
puede acortarse o alargarse. Los demás
eventos pueden terminar siempre que se
alcance el objetivo del evento, asegurando
que se emplee una cantidad apropiada de
tiempo sin permitir desperdicio en el
proceso.

Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los
eventos de scrum constituye una oportunidad formal para la inspección y adaptación de
algún aspecto. Estos eventos se diseñaron específicamente para habilitar los pilares
vitales de transparencia e inspección. La falta de alguno de estos eventos da como
resultado una reducción de la transparencia y constituye una oportunidad perdida de
inspección y adaptación.

EL SPRINT

El corazón de Scrum es el Sprint, es un bloque de tiempo (Time - box)

de un mes o menos durante el cual se crea un incremento de
producto “Terminado” utilizable y potencialmente desplegable. Es Sprint, máx.
más conveniente si la duración de los sprints es consistente a lo 30 días
largo del esfuerzo de desarrollo. Cada nuevo Sprint comienza
inmediatamente después de la finalización del sprint anterior.

Durante el sprint:

• No se realizan cambios que puedan afectar el Objetivo del Sprint (Sprint Goal)
• Los objetivos de calidad no disminuyen; y
• El alcance puede clasificarse y renegociarse entre el dueño de producto y el
equipo de desarrollo a medida que se va aprendiendo más.

Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes. Al

igual que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una meta
de lo que se construirá, un diseño y un plan flexible que guiará su construcción, el trabajo
del equipo y el incremento de producto resultante.
Los Sprints están limitados a un mes calendario. Cuando el
horizonte de un sprint es demasiado grande la definición de lo que se está construyendo
podría cambiar, la complejidad podría incrementarse y el riesgo podría aumentar. Los
sprints habilitan la predictibilidad al asegurar la inspección y adaptación de progreso al
menos en cada mes calendario. Los sprints también limitan el riesgo al costo de un mes
calendario.

CANCELACIÓN DE UN SPRINT.

Un Sprint puede cancelarse antes de que el bloque de tiempo llegue a su fin. Solo el
dueño de producto tiene la autoridad para cancelar el sprint, aunque puede hacerlo bajo
la influencia de los interesados, del equipo de desarrollo o del Scrum Master.

Un Sprint se cancelaría si el objetivo del sprint llega a quedar obsoleto. Esto podría
ocurrir si la compañía cambia la dirección o si las condiciones del mercado o de la
tecnología cambian. En general, un sprint debería cancelarse si no tuviese sentido
seguir con él dadas las circunstancias. Sin embargo, debido a la corta duración de los
sprints, su cancelación rara vez tiene sentido.

Cuando se cancela un sprint se revisan todos los

elementos de la lista de producto que se hayan
completado y “terminado”. Si una parte del
trabajo es potencialmente entregable, el Dueño
de producto normalmente lo acepta. Todos los
elementos de la lista de producto no completados
se vuelven a estimar y se vuelven a introducir a
la lista de producto. El trabajo finalizado en ellos
pierde valor con rapidez y por lo general debe
volverse a estimar.

Las cancelaciones de sprint consumen recursos ya que todos se reagrupan en otra

planificación de sprint para empezar otro sprint. Las cancelaciones de Sprint son a
menudo traumáticas para el equipo Scrum y son muy poco comunes.

PLANIFICACIÓN DE SPRINT (SPRINT PLANNING)

El trabajo a realizar durante el sprint se planifica en la planificación de sprint. Este plan

se crea mediante el trabajo colaborativo del equipo scrum completo.

La planificación de sprint tiene un máximo de duración de ocho horas para un sprint de

un mes. Para sprints más cortos el evento es usualmente más corto. El scrum master
se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
El scrum master enseña al equipo Scrum a mantenerse dentro del bloque de tiempo.
La planificación de sprint a las siguientes preguntas:

• ¿Qué puede entregarse en el

incremento resultante del Sprint que
comienza?
• ¿Como se conseguirá hacer el
trabajo necesario para entregar el
incremento?

TEMA UNO: ¿Que puede hacerse en este Sprint?

El equipo de desarrollo trabaja para proyectar la funcionalidad que se desarrollará

durante el Sprint. El dueño de producto discute el objetivo que el sprint debería lograr y
los elementos de la lista de productos que, si se completan en el Sprint, lograrán el
objetivo del Sprint. el equipo Scrum completo colaboradora en el entendimiento del
trabajo del sprint.

La entrada a esta reunión está constituida por la Lista de Producto, el último incremento
de producto, la capacidad proyectada de equipo de Desarrollo. el número de elementos
de la lista de Producto seleccionados para el Sprint depende únicamente del equipo de
desarrollo. Solo el equipo de Desarrollo puede evaluar que es capaz de lograr durante
el sprint que comienza

Durante la planificación del Sprint, el equipo Scrum también define un objetivo del Sprint
(Sprint GOAL). El objetivo del sprint debería lograrse durante el sprint a través de la
implementación de la lista de producto y proporciona una guía al equipo de desarrollo
de porque se está construyendo el incremento.
Temas DOS: ¿Cómo se conseguirá completar el trabajo seleccionado?

Una vez que se ha establecido el objetivo y seleccionado los elementos de la lista de

producto para el sprint, el equipo de desarrollo decide cómo construirá esta
funcionalidad para formar un incremento de producto “terminado” durante el Sprint. Los
elementos de la lista de producto seleccionados para este Sprint, más el plan para
terminarlos, recibe el nombre de lista de pendientes de sprint (Sprint backlog)

El equipo de desarrollo por lo general comienza diseñando el sistema y el trabajo

necesario para convertir la lista de producto en un incremento de producto funcional. El
trabajo podría ser de tamaño o esfuerzo estimado variables. Sin embargo, durante la
planificación del Sprint se planifica suficiente trabajo como para el Equipo de Desarrollo
puede hacer una proyección de lo que cree que puede completar en el Sprint que
comienza. Para el final de esta reunión, el trabajo planificado por el equipo de Desarrollo
para los primeros días del Sprint es descompuesto en unidades de un día más o menos.
el equipo de desarrollo se autoorganiza para asumir el trabajo de la lista de pendientes
de Sprint, tanto durante la planificación del Sprint como a lo largo del Sprint.

El dueño de producto puede ayudar a clasificar los elementos de la lista de producto

seleccionados y hacer concesiones. Si el equipo de desarrollo determina que tiene
demasiado trabajo o que no tiene suficiente trabajo, podría renegociar los elementos de
la lista de producto seleccionados con el dueño de Producto. el equipo de desarrollo
podría también invitar a otras personas a que asistan para que proporcionen asesoría
técnica a relacionada con el dominio.

Al finalizar la planificación del Sprint, el equipo de Desarrollo debería ser capaz de

explicar al Dueño de Producto y al Scrum master cómo pretende trabajar como un
equipo autoorganizado para lograr el objetivo del Sprint y crear el incremento esperado
Objetivo del Sprint (Sprint Goal).

El objetivo del Sprint es una meta establecida para el

Sprint que puede lograrse mediante la implementación
de la lista de Producto. Proporciona una guía al Equipo
de Desarrollo acerca de porque está construyendo el
incremento. Se crea durante la planificación del Sprint.
el objetivo del Sprint brinda al equipo de desarrollo
cierta flexibilidad con respecto a la funcionalidad
implementada en el Sprint. Los elementos de las Lista
de Producto seleccionados ofrecen una función
coherente que puede ser el objetivo del Sprint. El
objetivo del Sprint puede representar otro nexo de unión
que haga que el Equipo de desarrollo trabaje en
conjunto y no en iniciativas separadas.

A medida que el equipo de desarrollo trabaja mantiene el objetivo del Sprint en mente
con el fin de satisfacer el objetivo del Sprint, el equipo implementa funcionalidad y
tecnología. Si el trabajo resulta ser diferente de lo que es Equipo de Desarrollo espera,
ellos colaboran con el dueño del Producto para negociar el alcance de la lista de
pendientes del Sprint. (Sprint backlog)

Scrum Diario (Daily Scrum).

El Scrum Diario es una reunión con un bloque de

tiempo de 15 minutos para el Equipo de Desarrollo.
El Scrum Diario se lleva a cabo cada día del Sprint,
En él, el equipo de Desarrollo planea el trabajo para
las siguientes 24 horas. esto optimiza la colaboración
y el desempeño del equipo inspeccionando el trabajo
avanzado desde el último Scrum Diario y haciendo
una proyección del trabajo del Sprint a realizar a
continuación. el Scrum Diario se realiza a la misma
hora y en el mismo lugar todos los días para reducir
la complejidad.

El equipo de desarrollo usa el Scrum Diario para evaluar el progreso hacia el Objetivo
del Sprint y para evaluar qué tendencia sigue este progreso hacia la finalización del
trabajo contenido en la lista de pendientes del Sprint. El Scrum Diario optimiza las
posibilidades de que el Equipo de Desarrollo cumpla el Objetivo del Sprint. Cada día, el
equipo de Desarrollo debería entender como intenta trabajar en conjunto como un
equipo autoorganizado para lograr el Objetivo del Sprint y crear el incremento esperado
hacia el final del Sprint.

El equipo de Desarrollo es el encargado de establecer la estructura de la reunión y esta

se puede conducir de diferentes maneras, se enfoca en el progreso hacia la Meta de
Sprint. Algunos Equipos de Desarrollo usarán preguntas, algunos se basarán más en
discusiones.
Aquí hay un ejemplo de lo que podría usarse:

• ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
• ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del
Sprint?
• ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el
Objetivo del Sprint?

El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir

inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para
adaptar o planificar el resto del trabajo del Sprint.

El Scrum master se asegura de que el Equipo de

Desarrollo tenga la reunión, pero es el Equipo de
Desarrollo el responsable de dirigir el Scrum Diario
en los límites del bloque de tiempo de 15 minutos.

El Scrum Diario es una reunión interna del Equipo

de Desarrollo. Si otras personas están presentes, el
Scrum master se asegura de que no interrumpan la
reunión.

Los Scrum Diarios mejoran la comunicación,

eliminan la necesidad de realizar otras reuniones,
identifican impedimentos a remover relativos al
desarrollo, resaltan y promueven la toma rápida de
decisiones y mejoran el nivel de conocimiento del
Equipo de Desarrollo. El Scrum Diario es una
reunión clave de inspección y adaptación.

Revision de Sprint (Sprint Review).

Al final del Sprint se lleva a cabo una

Revisión de Sprint para inspeccionar el
Incremento y adaptar la Lista de Producto si
fuese necesario. Durante la Revisión de
Sprint. Basándose en esto y en cualquier
cambio a la Lista de Producto durante el
Sprint, los asistentes colaboran para
determinar las siguientes cosas que podrían
hacerse para optimizar el valor. Se trata de
una reunión informal, no una reunión de
seguimientos, y la presentación de
Incremento tiene como objetivo facilitar la
retroalimentación de información y fomentar
la colaboración.
Se trata de una reunión de, a lo sumo, cuatro horas para Sprint de un mes, Para Sprints
más cortos, el evento usualmente más corto, El Scrum master se asegura de que el
evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master
enseña a todos a mantener el evento dentro del bloque de tiempo fijado.

La revisión de Sprint incluye los siguientes elementos:

• Los asistentes son el Equipo Scrum y los interesados clave invitados por el
Dueño de Producto;
• El Dueño de producto explica que elementos de la lista de Productos se han
“terminado” y cuales no se han “Terminado”.
• El Equipo de Desarrollo habla acerca de que estuvo bien durante el Sprint, qué
problemas aparecen y cómo fueron resueltos esos problemas;
• El Equipo Desarrolló hace una demostración del trabajo que ha “terminado” y
responde preguntas acerca del incremento;
• El dueño del producto habla acerca de la lista de producto en su estado actual,
Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el
progreso obtenido hasta la fecha (si fuera necesario);
• El grupo completo colabora acerca de qué hacer a continuación, de modo que la
revisión del Sprint proporciona información de entrada valiosa para Reuniones
de planificación de Sprint subsiguientes.
• Revisión de cómo el mercado o el uso potencial del producto podría haber
cambiado lo que es de más valor para hacer a continuación; y,
• Revisión de la línea de tiempo, presupuesto, capacidades potenciales y mercado
para las próximas entregas de funcionalidad o capacidad prevista del producto.

El resultado de la revisión de Sprint es una lista de producto revisada que define los
elementos de la lista de productos posibles para los siguientes sprint. Es posible además
que la lista de producto reciba un ajuste general para enfocarse en nuevas
oportunidades.

Retrospectiva de Sprint (Sprint Retrospective).

La retrospectiva de Sprint es una oportunidad para el equipo scrum de inspeccionarse

a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente
sprint.

La retrospectiva de Sprint tiene lugar después de la revisión de Sprint y antes de la

siguiente planificación de sprint. Se trata de una reunión de, máximo cuatro horas para
sprint de un mes.

Para sprints más cortos el evento es usualmente más corto. El scrum master se asegura
de que el evento se lleve a cabo y que los asistentes entiendan su propósito.

El Scrum master se asegura de que la reunión sea positiva y productiva. El Scrum

master participa en la reunión como un miembro del equipo ya que la responsabilidad
del proceso scrum recae sobre él.
El propósito de la retrospectiva de sprint es:

• Inspeccionar cómo fue el último sprint en

cuanto a personas, relaciones, procesos y
herramientas;
• Identificar y ordenar los elementos más
importantes que salieron bien y las
posibles mejoras; y,
• Crear un plan para implementar las
mejoras a la forma en la que el equipo
scrum desempeña su trabajo.

El scrum master alienta al equipo para que mejore, dentro del marco de procesos scrum,
su proceso de desarrollo y sus prácticas para hacerlos más efectivos para el siguiente
sprint. Durante cada retrospectiva de sprint, el equipo scrum planifica formas de mejorar
la calidad del producto mediante el mejoramiento de la calidad de los procesos o
adaptando la definición de “Terminado” (definition of “Done”) según sea conveniente y
no entre conflicto con los estándares del producto y organizacionales.

Para el final de la retrospectiva de sprint el equipo scrum debería haber identificado

mejoras que implementa en el próximo sprint. El hecho de implementar estas mejoras
en el siguiente sprint constituye la adaptación subsecuente a la inspección del equipo
de desarrollo mismo. Aunque las mejoras puedan implementarse en cualquier momento,
la retrospectiva de sprint ofrece un evento dedicado para ese fin, enfocado en la
inspección y la adaptación

Artefactos de Scrum.

Los artefactos de scrum representan trabajo o valor en diversas formas que son útiles
para proporcionar transparencia y oportunidades para la inspección y adaptación. Los
artefactos definidos por scrum están diseñados específicamente para maximizar la
transparencia de la información clave, necesaria para asegurar que todos tengan el
mismo entendimiento del artefacto.

Lista de producto (Product Backlog).

La lista de producto es una lista ordenada de todo lo que se conoce que es necesario
en el producto. Es la única fuente de requisitos para cualquier cambio a realizarse en el
producto. El dueño de producto (Product Owner) es el responsable de la lista de
producto, incluyendo su contenido, disponibilidad y ordenación.

Una lista de producto nunca está completa. El desarrollo más temprano de la misma
solo refleja los requisitos conocidos y mejor entendidos al principio. La lista de producto
evoluciona a medida que el producto y el entorno en el que se usara también lo hacen.
La lista de producto es dinámica; cambia constantemente para identificar lo que el
producto necesita para para ser adecuado, competitivo y útil. Si un producto existe, su
lista de producto también existe.
La lista de producto enumera todas las características, funcionalidades, requisitos,
mejoras y correcciones que constituyen cambios a realizarse sobre el producto para
entregas futuras. Los elementos de la lista de producto tienen como atributos la
descripción, el orden, la estimación y el valor. Los elementos de la lista de producto
muchas veces incluyen descripciones de las pruebas que demostraran la finalización de
tales elementos cuando estén “terminados”.

A medida que un producto es utilizado y se

incrementa su valor y el mercado proporciona
retroalimentación, la lista de producto se
convierten en una lista más larga y exhaustiva.
los requisitos nunca dejan de cambiar así que la
lista de producto es un artefacto vivo. Los
cambios en los requisitos de negocio, las
condiciones del mercado o la tecnología podrían
causar cambios en la lista de producto.

A menudo, varios equipos scrum trabajan juntos

en el mismo producto. Para describir el trabajo a
realizarse sobre el producto se utiliza una única
lista de producto. En ese caso podría emplearse
un atributo de la lista de producto para agrupar
los elementos.

El refinamiento (refinement) la lista de producto es el acto de añadir detalle,

estimaciones y orden a los elementos de la lista de producto. Se trata de un proceso
continuo en el cual el dueño de producto y el equipo de desarrollo colaboran acerca de
los detalles de los elementos de la lista de producto. Durante refinamiento de la lista de
producto, se examinan y revisan sus elementos. El equipo scrum decide como y cuando
se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del
equipo de desarrollo. Sin embargo, los elementos de la lista de producto pueden
actualizarse en cualquier momento por el dueño de producto o a criterio suyo.

Los elementos de la lista de producto de orden más alto son generalmente más claros
y detallados que los de menor orden. se realizan estimaciones más precisas basándose
en la mayor claridad y detalle; cuanto más bajo es el orden, menor es el detalle. los
elementos de la lista de producto de los que se ocupara el equipo de desarrollo en el
siguiente sprint tiene una granularidad mayor, habiendo sido descompuestos de forma
que en cualquier elemento pueda ser “terminado” dentro de los límites del bloque de
tiempo del sprint. Los elementos de la lista de producto pueden ser” terminado” por el
equipo de desarrollo en un sprint son considerados “preparados” o “accionables” para
ser seleccionados en una reunión de planificación de sprint. los elementos de la lista de
producto normalmente adquieren este grado de transparencia mediante las actividades
de refinamiento descritas anteriormente.

El equipo de desarrollo es el responsable de proporcionar todas las estimaciones. El

dueño de producto podría influenciar al equipo ayudándoles a entender y seleccionar
sus compromisos, pero las personas que harán el trabajo son las que hacen la
estimación final.
Seguimiento del progreso hacia los objetivos

En cualquier momento es posible sumar el trabajo total

restante para alcanzar el objetivo. El dueño de producto
hace seguimiento de este trabajo restante total al menos en
cada revisión de sprint. El dueño de producto compara esta
cantidad con el trabajo restante con revisiones de sprint
previas, para evaluar el progreso hacia la finalización del
trabajo proyectado en el tiempo deseado para el objetivo.
Esta información se muestra de forma transparente a todos
los interesados.

Varias prácticas de proyección de tendencias se han utilizado para predecir el progreso,

como trabajo pendiente (burndown), completado (burnup) y flujo acumulado
(acumulative flow), estas han probado ser útiles. Sin embargo, no reemplazan la
importancia del empirismo. En entornos complejos se desconoce lo que ocurrirá. Solo
lo que ya ha ocurrido puede utilizarse para la toma de decisiones con miras al futuro.

Lista de pendientes del sprint (Sprint Backlog).

La lista de pendientes del sprint es el conjunto de

elementos de la lista de producto seleccionados para
el sprint, más un plan para entregar el incremento de
producto y conseguir el objetivo del sprint. La lista de
pendientes del sprint es una predicción hecha por el
equipo del objetivo del sprint. La lista de pendientes
del sprint es una predicción hecha por el equipo de
desarrollo acerca de qué funcionalidad formará parte
del próximo incremento y del trabajo necesario para
entregar es funcionalidad en un incremento
terminado.

La lista de pendientes del sprint hace visible todo el trabajo que el equipo de desarrollo
identifica como necesario para alcanzar el objetivo del sprint, para asegurar el
mejoramiento continuo, la listo de pendientes del sprint incluye al menos una mejora de
procesos de alta prioridad identificada en la retrospectiva inmediatamente anterior.

La lista de pendientes del sprint es un plan con un nivel de detalle suficiente como para
que los cambios en el proceso se puedan entender en el scrum diario. el equipo de
desarrollo modifica la lista de pendientes del sprint durante el sprint y esta lista de
pendientes del sprint emerge a lo largo del sprint. esto ocurre a medida que el equipo
de desarrollo trabaja en lo planeado y aprende más cerca del trabajo necesario para
conseguir el objetivo del sprint.

Cuando se requiere nuevo trabajo, el equipo de desarrollo lo adiciona a la lista de

pendientes del sprint. a medida que el trabajo se ejecuta o se completa se va
actualizando la estimación de trabajo restante. cuando algún elemento del plan se
considera innecesario, es eliminado. solo el equipo desarrollo puede cambiar su lista de
pendientes del sprint durante un sprint. La lista de pendientes del sprint es una imagen
visible en tiempo real del trabajo que el equipo de desarrollo planea llevar a cabo durante
el sprint y pertenece únicamente al equipo de desarrollo.
Seguimiento del proceso del sprint.

En cualquier momento durante un sprint es posible sumar el trabajo restante total en los
elementos de la lista de pendientes del sprint. el equipo de desarrollo hace seguimiento
de este trabajo restante total al menos en cada scrum diario para proyectar la posibilidad
de conseguir el objetivo del sprint. haciendo seguimiento del trabajo restante a lo largo
del sprint el equipo de desarrollo puede gestionar su progreso.

INCREMENTO.

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. al final de
un sprint el nuevo incremento debe estar “terminado”, lo cual significa que está en
condiciones de ser utilizado y que cumple la definición de “terminado” del equipo scrum.
un incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el
empirismo al final del sprint. el incremento es un paso hacia una visión y meta. El
incremento debe estar en condiciones de utilizarse sin importar si el dueño de producto
decide liberarlo o no.

TRANSPARENCIA DE LOS ARTEFACTOS.

Scrum se basa en la transparencia. las decisiones para optimizar el valor y controlar el

riesgo se toman basadas en el estado percibido de los artefactos. en la medida en que
la transparencia sea completa, estas decisiones tienen unas bases sólidas. en la medida
en que los artefactos no son completamente transparentes, estas decisiones pueden
ser erróneas, el valor puede disminuir y el riesgo puede aumentar.

El scrum master debe trabajar con el dueño de producto, el equipo de desarrollo y otras
partes involucradas para entender si los artefactos son completamente transparentes.
hay prácticas para hacer frente a la falta de transparencia; el scrum master debe ayudar
a todos a aplicar las prácticas más apropiadas si no hay transparencia completa. Un
scrum master puede detectar la falta de transparencia inspeccionando artefactos,
reconociendo patrones, escuchando atentamente lo que se dice y detectando diferencia
entre los resultados esperados y los reales.

La labor del scrum master es trabajar con el equipo scrum y la organización para mejorar
la transparencia de los artefactos. este trabajo usualmente incluye aprendizaje,
convicción y cambio. la transparencia no ocurre de la noche a la mañana si no que es
un camino.

DEFINICIÓN DE TERMINADO.

Cuando un elemento de la lista de producto o un incremento se describe “terminado”

todo el mundo debe entender lo que significa terminado. aunque esto puede variar
significativamente para cada equipo scrum. los miembros del equipo deben tener un
Entendimiento compartido en lo que significa que el trabajo esté completado para
asegurar la transparencia. Esta es la definición de “terminado” para el equipo scrum y
se utiliza para evaluar cuando se ha completado el trabajo sobre el incremento de
producto.
Esta misma definición guía al equipo de desarrollo en saber
cuántos elementos de la lista de productos pueden seleccionar durante la planificación
del sprint. el propósito de cada sprint es entregar incrementos de funcionalidad que
potencialmente se puedan poner en producción y que se ajustan a la definición de
terminado actual del equipo scrum.

Los equipos de desarrollo entregan

un incremento de funcionalidad de
producto en cada sprint. este
incremento es utilizable, de modo
que el dueño de producto podría
elegir liderarlo inmediatamente. si
la definición de terminado para un
incremento es parte de las
convenciones, estándares o guías
de la organización de desarrollo, al
menos todos los equipos scrum
deben seguirla.

Si terminado para un incremento no es una convención de la organización de desarrollo,

el equipo de desarrollo del equipo scrum debe especificar una definición determinado
apropiada para el producto. sí hay múltiples equipos scrum trabajando en la entrega del
sistema o producto, los equipos de desarrollo en todos los equipos scrum deben definir
en conjunto la definición de terminado.

Cada incremento se integra con todos los incrementos anteriores y es probado de forma
exhaustiva, asegurando que todos los incrementos funcionan en conjunto.

A medida que los equipos Scrum maduran, se espera que su definición de “Terminado”
se amplíe para incluir criterios más rigurosos para una mayor calidad. El uso de las
nuevas definiciones puede descubrir trabajo por hacer en los incrementos previamente
“Terminados”. Cualquier producto o sistema debería tener una definición de “Terminado”
que es un estándar para cualquier trabajo realizado sobre él.
FLUJO DE SCRUM – FASES Y PROCESOS
MATERIAL DE APOYO

CODIGO QR VIDEO

Requerimientos de SCRUM

Flujo SCRUM
Recomendaciones para ser un SCRUM MASTER

• Un Scrum master es un líder presente y consciente, Seamos más cercanos, lo

más bonito que tú puedes dejar en tu equipo es q tengan claro q tu estas ahí.
• Permite que las personas puedan expresar sus ideas de manera libre, es más
importante escuchar que hablar.
• Apasiónate por lo que haces, crea un objetivo común, es imposible ser un líder
sin pasión.
• Aprende a trabajar en equipo, ninguno de nosotros es tan bueno como cuando
estamos juntos. Si tú eres el mejor de tu equipo estas en problemas
• Enfócate en generar valor en todo lo que haces. Donde están tus prioridades
están tus oportunidades
• Ten coherencia entre lo que piensas, dices, sientes y haces. Esto se llama
coherencia cardiaca y esta determina tus resultados.
• Los líderes tienen un alto nivel de humildad, reconoce tus debilidades, cuando
se te presente un inconveniente no mires por la ventana; toma el espejo.
• Piensa en la huella o cicatriz que estás dejando en las personas que se
relacionan contigo. Que huella estás dejando en las personas que te conocen.
• Un buen Scrum master sabe formular las preguntas adecuadas, un proyecto
exitoso empieza con unas buenas preguntas - Historias de usuario.
• Un Scrum master tiene claro cuál es el propósito de hacer lo que hace - Para
que tu estas en la gerencia de proyectos, cuál es tu propósito.
• Como quieres que te recuerden tus colaboradores, Siempre se trata de lo que
otros sienten cuando se acuerdan de ti.
• Un buen líder no dirige, sino que inspira. A cuantas personas has inspirado a
ser mejores. Que tan clonable eres, cuántos quisieran ser como tú. Que tan
maravilloso sería este mundo si todos fueran como tú.
• Has q tu presencia se sienta donde sea, que cada persona se acuerde lo que
tú le enseñaste. Gánate primero el corazón de alguien antes de pedirle algo
• Debes aprender a manejar tu cuerpo, emoción y lenguaje. (Lenguaje no verbal)
• Recuerda, no se trata de lo que yo diga se trata de lo que tu comprendas.
• La gente puede ser brillante, pero si tú no confías no pasa nada.
• Cuando trabajas en la felicidad de alguien estas logrando que ellos trabajen
para ti. ¿Cuántos de tu equipo pagarían una fianza por ti? El Scrum master no
necesita auxiliares, porque él logra que un equipo de trabajo, trabaje en equipo.
• No importa cuánto sabes, lo que importa es, como tú colocas en práctica lo que
sabes
• Para que lo digital migre nosotros debemos hacerlo, la digitalización no se trata
de tecnología se trata de humanidad. Ocúpate en generar “Experiencias de
valor”
• Ojalá todos los PMP se convirtieran en Scrum master, sería el mundo ideal.
Pero se necesitan los dos roles para gerenciar los proyectos.
 SIMULADOR 1

1. Usted es un jefe de operaciones con amplio conocimiento en los proyectos

de Scrum. El jefe de tecnología tiene una idea de lo que es Scrum y le
informa que quiere implementarlo en varios proyectos dentro de la
organización. ¿Cuál declaración hecha por el jefe de tecnología NO es
verdadera?
a) Los equipos de Scrum idealmente deben de consistir de seis a diez
integrantes.
b) En un solo proyecto pueden participar múltiples equipos de Scrum.
c) Scrum no se puede utilizar para grandes proyectos.
d) Scrum se puede implementar en un nivel de programa.

2. ¿Cuál de las siguientes es la salida principal del proceso de retrospectiva

del sprint?
a) Mejoras accionables aceptadas
b) Mantenimiento de la lista de pendientes del sprint
c) Gráfica de trabajo pendiente actualizada (Burndown Chart)
d) Registro de impedimentos actualizado

3. ¿A qué se refiere la experiencia del equipo en Scrum?

a) La experiencia de los miembros del equipo Scrum para entender las historias
de usuario y las tareas requeridas para crear los entregables finales.
b) La experiencia de los roles principales para comunicar los requerimientos,
entender historias de usuario y supervisar todo el proyecto por parte del
propietario del producto, el equipo Scrum y el Scrum Master
respectivamente.
c) Los expertos que integran el cuerpo de asesoramiento de Scrum y actualizan
periódicamente las mejores prácticas en Scrum.
d) Expertos de Scrum externos que ayudan en los proyectos Scrum en proceso
en caso de que existan grandes problemas en la implementación de Scrum.
 4. Existen varias prácticas en Scrum que facilitan la gestión efectiva de
riesgos. Relacione las prácticas de Scrum en la columna de la izquierda
con los riesgos que mitigan en la columna a la derecha.

PRÁCTICA DE SCRUM RIESGO

1) Propiedad del equipo a) Entorno empresarial
2) Desarrollo iterativo b) No detección
3) Transparencia c) Expectativas
4) Flexibilidad d) Inversión
5) Retroalimentación constante e) Estimación

5. "Relacione los siguientes procesos y salidas":

PROCESO
a. Creación de entregables
b. Realizar reunión diaria de pie
c. Mantener lista priorizada de
pendientes del producto
d. Realizar reunión diaria de pie
SALIDA
1. Lista priorizada de pendientes del
producto actualizada"
2. Tablero Scrum actualizado
3. Grafica actualizada de trabajo
pendiente
4. Registro de pendientes actualizado

6. ¿Cuál opción NO es una de las entradas del proceso de realizar la

planificación del lanzamiento?
a) Socio
b) Criterios de terminado
c) Equipo Scrum
d) Caso de negocio del proyecto

7. En una reunión de planificación del sprint, la definición objetiva significa:

a) El Equipo Scrum explica al Scrum Master las historias de usuario de más alta
prioridad en la lista de pendientes del producto, y después el Scrum Master,
en colaboración con el(los) Socio(s), define la meta del sprint.
b) El Equipo Scrum define las historias de usuario de acuerdo con la lista
priorizada de pendientes del producto.
c) El propietario del producto explica al Equipo Scrum las historias de usuario
de más alta prioridad, y después el Equipo Scrum en colaboración con el
propietario del producto, define la meta del Sprint.
d) El propietario del producto y el Equipo Scrum deciden sobre los criterios de
aceptación requeridos de las varias historias de usuario.
8. Seleccione la entrada, herramientas y salida para el proceso de convocar
a una reunión de Scrum de Scrums.

a) Entrada: Equipo principal de Scrum

Herramienta: Criterios de aceptación de la historias de usuario

Salida: Reunión de revisión del sprint

b) Entrada: Scrum Master

Herramienta: Equipo Scrum

Salida: Entregables aceptados

c) Entrada: Equipo Scrum

Herramienta: Reunión de retrospectiva del sprint

Salida: Lista de pendientes del sprint

d) Entrada: Scrum Master/Representación del Equipo Scrum

Herramienta: Reunión Scrum de Scrums

Salida: Mejor coordinación del equipo

9. ¿Cuál de las siguientes NO es una pregunta que responde el equipo Scrum

durante las reuniones diarias de pie?

a) ¿Qué terminaré hoy?

b) ¿Estoy enfrentando impedimentos u obstáculos?
c) ¿Cómo resolveré los impedimentos que estoy enfrentando?
d) ¿Qué terminé ayer?
10. ¿Quién estima las historias de usuario en Scrum?

a) El propietario del producto

b) El equipo Scrum
c) El patrocinador ejecutivo
d) El grupo de usuarios

11. La empresa Coxal Times ha iniciado un proyecto que incluye la vigilancia

(seguimiento) de camiones que circulan por la ciudad. ¿Cuál NO es una de
las características de este proyecto si se administra según la metodología
de Scrum?

a) Se hará una planificación detallada por adelantado para asegurar que los
riesgos se identifiquen con anticipación.
b) El equipo que trabaja en este proyecto se reunirá diariamente durante 15
minutos para hacer una lista de los impedimentos en la conclusión de tareas.
c) El propietario del producto priorizará las tareas que entregarán el máximo
valor de negocio.
d) El cliente no siempre define los requerimientos (muy concretos) en
etapas tempranas.

12. NovaPixel es una empresa dedicada al desarrollo de software, ha decidido

utilizar Scrum en uno de sus proyectos. ¿Con qué se inicia el ciclo Scrum?

a) Reunión de mantenimiento de la lista de pendientes del producto

b) Reunión de Socios
c) Reunión de planificación del sprint
d) Reunión de planificación del lanzamiento

13. ¿Cuál NO es un proceso en la fase de revisión y retrospectiva?

a) Demostración y validación del sprint

b) Convocar Scrum de Scrums
c) Retrospectiva del sprint
d) Retrospectiva del proyecto
14. En Scrum, ¿qué es lo que garantiza la transparencia?

A. El tablero de Scrum
B. El registro de impedimentos
C. La reunión diaria de pie
D. Las videoconferencias

a) A, B y C
b) A, C y D
c) A, B , C y D
d) Solamente A

15. Seleccione el par que está incorrectamente relacionado:

a) Necesidad de estimar: Membresía del grupo

b) Seguridad: Seguridad física
c) Autorrealización: Creatividad
d) Pertenencia: Aprobación

16. ¿Cuál es el formato correcto para redactar una historia de usuario?

a) Como un {rol/prototipo} debo poder {requerimiento} para que {beneficio}
b) Debo poder {requerimiento} Como un {rol/prototipo} para que {beneficio}
c) Yo debo poder {beneficio}, como un {rol/prototipo} para que {requerimiento}
d) Yo debo poder {requerimiento} para que {beneficio} como un {rol/prototipo}

17. ¿Cuál debe ser la duración de una reunión de planificación de tareas para
un Sprint de cuatro semanas?

a) 2 horas
b) 4 horas
c) 6 horas
d) 8 horas
18. ¿Cuál de las siguientes NO es un objetivo de una reunión retrospectiva del
sprint?

a) Identificar mejoras del proceso.

b) Identificar mejoras de las características.
c) Identificar mejores prácticas.
d) Identificar problemas y embotellamientos del proceso.

19. ¿Cuál de las siguientes opciones NO se identifica en una reunión de visión

del proyecto?

a) Los datos históricos para justificar el proyecto

b) La identificación de los beneficios del negocio
c) 1Las expectativas de los socios
d) Los requerimientos del negocio del proyecto

20. La empresa A está en proceso de finalizar un proyecto que se llevará a cabo

durante el siguiente ejercicio fiscal. Cuentan con cuatro proyectos en
espera, de los cuales debe seleccionar uno utilizando el valor presente neto
(VPN) como su criterio de selección. ¿Cuál proyecto debería elegir la
empresa?

a) El Proyecto K, que cuenta con un valor presente neto (VPN) de $3,000 y un

período de 5 años.
b) El Proyecto L, que cuenta con un valor presente neto (VPN) de $1 ,500 y un
periodo de 2.5 años.
c) El Proyecto M, que cuenta con un valor presente neto (VPN) de $2,500 y un
periodo de 3 años.
d) El Proyecto N, que cuenta con un valor presente neto (VPN) de $5,000 y un
periodo de 6 años.
 SIMULADOR NÚMERO 2

21. ¿Cuál de las siguientes opciones NO es un objetivo de la reunión de

retrospectiva del sprint?

e) Identificar las cosas que el equipo debe seguir haciendo y que puedan seguir
como las mejores prácticas.
f) Identificar las cosas que el equipo debe dejar de hacer para procesar
problemas y embotellamientos.
g) Identificar a los miembros del equipo que fueron de gran importancia en el
éxito del sprint.
h) Identificar las cosas que el equipo debe empezar a hacer.

22. El Hotel Pandora Club, enfrenta varios problemas y obstáculos mientras

trabaja en su proyecto. En Scrum, todos las siguientes opciones incluyen
limitaciones que se pudieran enfrentar al momento de implementar un
proyecto, EXCEPTO:

e) Tiempo, Calidad, Entregables

f) Costo, Visión, Entregables
g) Personas, Visión, Alcance
h) Costo, Calidad, Alcance

23. ¿Qué NO hacen los socios después de que se les presenta un caso de
negocio del proyecto?

e) Miden el potencial de rentabilidad del negocio relacionado al proyecto.

f) Determinan los beneficios potenciales del negocio.
g) Confirman las finanzas del proyecto.
h) Priorizan las características más rentables para el proyecto.
24. Identifique la entrada-herramienta-salida del proceso de retrospectiva del
proyecto en la fase de lanzamiento.

a) quipo principal de Scrum - Reunión de retrospectiva del proyecto - Elementos

de acción asignados y Fechas límite
b) Entregables aceptados - Reunión de retrospectiva del sprint - Mejoras
accionables aceptadas
c) Socios - Reunión de revisión de la lista de pendientes - Acuerdo de
entregables funcionales
d) Propietario del producto - Registros de impedimentos - Lista de tareas del
esfuerzo estimado

25. ¿Cuál de los siguientes enunciados NO es verdadero sobre un registro de

impedimentos?

a) El registro de impedimentos puede ser actualizado durante la reunión diaria

de pie.
b) Los impedimentos están siempre dentro del equipo.
c) La transparencia en Scrum garantiza una identificación rápida y segura de
impedimentos.
d) El Scrum Master mantiene y actualiza el registro de impedimentos.

26. ¿Cuál de las siguientes opciones no se incluye en un caso de negocio del

proyecto?

a) Una comparación de otros proyectos y una breve descripción de cada uno.

b) El propósito de negocio para el proyecto.
c) El resultado deseado y un reporte de análisis de brechas.
d) Riesgos potenciales que pudieran afectar el proyecto.
27. ¿Cuál NO es uno de los propósitos de la gráfica de trabajo pendiente del
Sprint (Sprint Burndown Chart)?

a) Muestra si cualquier impedimento está obstaculizando el progreso de un

proyecto.
b) Muestra la cantidad de trabajo pendiente en un sprint.
c) Muestra la cantidad de trabajo concluido en un sprint.
d) Muestra el tiempo requerido para completar cada historia de usuario.

28. ¿Cuál de los siguientes procesos no es parte de la fase implementación?

a) Creación de la lista priorizada del sprint.

b) Creación de reunión diaria de pie (Daily Standup)
c) Creación de entregables
d) Mantenimiento de la lista priorizada de pendientes del producto.

29. Durante el proceso de elaboración de historias de usuario, el propietario

del producto debe tomar en cuenta el hecho de que uno de los aspectos
más importantes al momento de redactar dichas historias es priorizarlas y
darles el máximo valor de negocio en el menor tiempo posible. ¿Cuál de
las siguientes opciones refleja mejor la lógica detrás de
descrito anteriormente?

a) Al propietario del producto se le facilitará explicar las características a los

usuarios meta durante las demostraciones.
b) Las historias de usuario deben ser evaluadas y organizadas en una lista
priorizada con base en su valor únicamente.
c) La lista priorizada de pendientes del producto se debe mantener
constantemente a fin de acomodar cambios y nuevos requerimientos.
d) Los riesgos e incertidumbres deben ser identificados y resueltos
oportunamente en un proyecto.
30. Todas las siguientes opciones son salidas del proceso de creación de
entregables, EXCEPTO:

a) Registro de impedimentos actualizado

b) Entregables del sprint
c) Tablero de Scrum actualizado
d) Lista de pendientes del sprint

31. ¿Cuál de las siguientes NO es una pregunta que se responde durante una
reunión de Scrum de Scrums?

a) ¿En qué ha estado trabajando mi equipo desde la última reunión?

b) ¿Con qué contaban otros equipos que mi equipo hiciera que no se ha
hecho?
c) ¿Qué haremos hoy?
d) ¿Qué piensa hacer nuestro equipo que pueda afectar a otros
equipos?

32. _______________ - Esta técnica de identificación de riesgos se utiliza para

estimular ideas sobre las posibles fuentes de riesgo. Seleccione la opción
que complete correctamente el espacio en blanco.

a) Listas de verificación de riesgos

b) Lista corta de riesgos (Risk Prompt Lists)
c) Revisar lecciones aprendidas de la retrospectiva del sprint o del
proceso de retrospectiva del proyecto.
d) Lluvia de ideas

33. ¿Cuáles son dos procesos clave en la fase de lanzamiento?

a) Envío de entregables y Retrospectiva del proyecto

b) Entregables del sprint y Retrospectiva del riesgo
c) Entregables aceptados y Retrospectiva del sprint
d) Envío de entregables y Registro de retrospectiva del sprint
34. ¿Qué opción NO es verdadera sobre Scrum?

a) En Scrum es preferible tener equipos coubicados.

b) El propietario del producto representa la voz del cliente.
c) En ocasiones al equipo Scrum también se le denomina equipo de
desarrollo.
d) El Jefe Scrum Master debe estar presente durante una reunión diaria
de pie del Equipo Scrum.

35. ¿Quién NO participa en la reunión de visión del proyecto?

a) El Scrum Master del proyecto

b) El socio del programa
c) El jefe propietario del producto
d) El propietario del producto del programa

36. Una empresa que construye hélices para barcos cuenta con una baja tasa
de satisfacción de los clientes. La empresa pudo haber evitado tal
situación si hubiera aplicado la metodología Scrum ya que hubieran
garantizado que cualquier cambio solicitado por el cliente fuera incluido
como parte del proyecto, y que el equipo produjera entregables mejores
adecuados al ambiente final empresarial. ¿Cuál aspecto de Scrum se
enfatiza en este ejemplo?

a) Priorización basada en valor.

b) Apropiación
c) Desarrollo iterativo
d) Transparencia

37. ¿Cuáles actividades no suceden durante el inicio de un proyecto Scrum?

a) Crear la visión del proyecto

b) Identificar al Scrum Master y al Socio(s)
c) Creación de tareas
d) Realizar la planificación del lanzamiento
38. ¿Cuál es una salida del proceso de desarrollo de épicas?
a) Elementos de tareas
b) Estimación
c) Prototipo
d) Lista de pendientes del producto

39. ¿Cuál enunciado NO es verdadero respecto al tablero de Scrum?

A. Un tablero de Scrum debe, de preferencia, mantenerse en forma manual en
papel o en un pizarrón.

B. Los stakeholders mantienen el tablero de Scrum para planificar y dar

seguimiento al progreso durante cada Sprint.

C. Un tablero de Scrum contiene cuatro columnas para indicar el progreso de las

tareas estimadas para el Sprint.

D. Un tablero de Scrum se actualiza a diario durante la realización de la reunión

diaria de pie."
a) A y B
b) Solamente B
c) C y D
d) B y C

40. ¿Cuál opción es una descripción precisa de las reuniones de grupo de

enfoque?
a) Las reuniones de grupos de enfoque consisten de un grupo pequeño de
propietarios del producto que aportan información al equipo Scrum sobre cómo
se debe crear la funcionalidad.
b) Las reuniones de grupos de enfoque ayudan a reducir el alcance del proyecto.
c) Las reuniones de grupos de enfoque consisten de un grupo pequeño de usuarios
que ayudan a los desarrolladores a entender las necesidades del usuario
relacionadas a un producto o servicio.
d) Las reuniones de grupos de enfoque se llevan a cabo para ver si las
funcionalidades creadas por el Equipo Scrum son útiles para los grupos de
usuario.