SMC LIBRO DE TRABAJO ALUMNO

INTRODUCCIÓN

Reglas básicas y acuerdos de trabajo

 Este curso tiene una duración de dos días. La clase da inicio diariamente a las 09:00 AM y
continúa hasta las 05:00 PM. El instructor permitirá algunos descansos durante el día.
 Los participantes deben llegar a tiempo al salón de clases y regresar de los descansos según
se indique.
 Los teléfonos celulares deben permanecer apagados o en silencio.
 Se busca una participación total de parte de los estudiantes. Favor de incorporarse a las
actividades y ejercicios según se instruya. AVISO: ¡Probamente se divierta durante el curso.
 El material didáctico y demás recursos que estén a disposición de los estudiantes están
sujetos a derechos de autor y son propiedad absoluta de SCRUMstudy. No se permite
compartirlos, fotocopiarlos o distribuirlos. Deben ser utilizados únicamente por los
estudiantes inscritos en la capacitación presencial de SCRUMstudy.

Objetivos del curso

 Dar a conocer la filosofía y los principios de Scrum.

 Ofrecer información básica sobre Scrum, incluyendo los roles, reuniones y artefactos.
 Preparar a los estudiantes para que se sientan cómodos al momento de implementar Scrum
en sus organizaciones, así como en el manejo de obstáculos y problemas comunes.

Resultados del curso

 Los estudiantes podrán fácilmente reconocer, definir y trabajar con los conceptos, ventajas
y retos del framework de Scrum.
 Los estudiantes estarán preparados para asumir el rol de Scrum Master en sus
organizaciones y ayudarlas a adoptar el framework de Scrum. Además, los estudiantes
entenderán los demás roles en Scrum.
 Los estudiantes participarán en simulaciones en las que presentarán un proyecto Scrum.
 Los estudiantes obtendrán el conocimiento y la habilidad correspondiente para prever
problemas en sus respectivas organizaciones.
 Los estudiantes contarán con las herramientas adecuadas para atender, resolver y asumir el
liderazgo en cuestiones de Scrum en sus organizaciones.
 Los estudiantes tendrán acceso a un examen en línea. Una vez aprobado el examen, se les
enviará su certificado por correo.

Metodología del curso

 Nos comprometemos a ofrecer un curso altamente participativo que garantice una alta
retención de los conceptos y teorías.
 El curso fomenta el trabajo de los estudiantes sobre conceptos en vez de solo escucharlos.
Esto permite la retención e internalización.
 Llevamos a cabo juegos de roles y discutimos asuntos prácticos de implementación para
todas las partes del flujo de Scrum.
 Los estudiantes trabajan en un estudio de caso para simular el desarrollo de un producto
utilizando el framework de Scrum.
Acerca de SCRUMstudy
SCRUMstudy es el organismo de certificación global para certificaciones de Scrum y Ágil. En el sitio
SCRUMstudy.com podrá encontrar más información sobre SCRUMstudy, sus certificaciones y
programas de membresía. A continuación, se presenta un resumen:

Nivel ESMC SCT

Expert Scrum SCRUMstudy
Experto Master Certified Certified Trainer

SSMC SSPOC
Scaled Scrum Scaled Scrum SMC
Master Product Owner Scaled Scrum
Nivel Certified Certified Certified

Intermedio SAMC
SPOC SCRUMstudy
Scrum Product Agile Expert
Owner Certified Certified

Nivel SDC
Scrum Developer Certified
Básico

Membresía de SCRUMstudy y recursos en línea

Se requiere una cuenta como miembro de SCRUMstudy para hacer los exámenes supervisados en
línea. Los detalles para el acceso a la cuenta como miembro de SCRUMstudy se envían a los
estudiantes por correo electrónico con anticipación al programa presencial. Como parte de este
curso de SCRUMstudy, también se proporcionan recursos complementarios adicionales en línea,
incluyendo videos de conceptos, guías de estudio, estudios de caso, tarjetas de vocabulario, entre
otros. Todos los recursos en línea también se encuentran disponibles en la aplicación móvil de
VMEdu.

Examen de certificación SMC

Formato del examen

 Opción múltiple
 100 preguntas por examen
 Se otorga un punto por cada respuesta correcta
 No se quitan puntos por las respuestas incorrectas
 Duración de 120 minutos
 Examen supervisado en línea
 DESCRIPCIÓN DE ÁGIL

Descripción de ágil

“La agilidad es la habilidad de crear y responder al cambio a fin de

obtener beneficios en un turbulento entorno empresarial. La agilidad
es la capacidad para equilibrar la flexibilidad y la estabilidad!”
- Highsmith, 2002

La necesidad de ser ágil

Antes de profundizar en el significado de lo ágil, es importante entender por qué el desarrollo de

métodos ágiles se convirtió en algo necesario. El mercado de los teléfonos inteligentes puede ser
un ejemplo donde fueron prominentes los siguientes factores:

El rápido cambio en el mercado y la tecnología; la necesidad de estar a la vanguardia

La reducción del “tiempo para comercializar” productos y el aumento en la demanda de

innovación por parte del cliente.

La reducción de pruebas (testing) y costos de experimentación (simulación y

automatización)

El valor del cliente se entrega en el punto de venta, no en el punto de planificación

La necesidad de un método adaptable de desarrollo en vez de los métodos tradicionales

y predecibles

Gestión adaptiva de proyectos (Adaptive Project Management)

Ágil no fue desarrollado en un día. Hubo personas alrededor del mundo que insistieron la necesidad
de la gestión adaptiva de proyectos debido a que vieron que los métodos tradicionales de cascada
no tenían ___________.

La siguiente figura muestra la línea de tiempo del desarrollo de varios métodos ágiles:

Crystal Scrum Método de Programación Desarrollo Desarrollo

1998 1995 desarrollo Extrema basado en adaptivo
de sistemas 1996 funcionalidades de
dinámicos 1996 software
1995 2000
 Manifiesto Ágil

La aplicación de cualquier método re quiere de un claro entendimiento de los cuatro valores

señalados en el Manifiesto Ágil.

_____________________________

“Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia
experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

 Individuos e Interacciones sobre procesos y herramientas.

Aunque los procesos y las herramientas ayudan a terminar con éxito un proyecto, son las
_____________ quienes asumen, participan e implementan un proyecto y determinan
cuáles procesos y herramientas utilizar. Los actores clave en cualquier proyecto son las
personas, por ello, el énfasis debe estar en ellos y en sus interacciones en vez de los
complicados procesos y herramientas.

 Software funcionando sobre documentación extensiva

Aunque la documentación es necesaria y útil para cualquier proyecto, muchos equipos se
centran en la recopilación y el registro de descripciones cualitativas y cuantitativas de los
entregables, cuando el valor real que se le entrega al cliente es en forma de un software
funcional. Por lo tanto, en vez de la documentación detallada, el enfoque ágil está en la
entrega de un software de buen funcionamiento en incrementos a lo largo del ciclo de vida
del producto.

 Colaboración con el cliente sobre negociación contractual

Tradicionalmente a los clientes se les ha visto como participantes externos, involucrados
principalmente al inicio y al final del ciclo de vida del producto y cuya relación se basaba en
contractos y en su cumplimiento. Ágil cree en un enfoque de valor compartido en el cual
los clientes se consideran colaboradores. El equipo de desarrollo y el cliente trabajan
unidos para evolucionar y desarrollar el producto.

 Responder ante el cambio sobre seguir un plan

En mercado actual – donde los requerimientos del cliente, las tecnologías disponibles y los
patrones empresariales cambian contantemente -, es fundamental abordar el desarrollo
de productos en una forma adaptiva que permita la incorporación de cambio y rápidos
ciclos de vida de desarrollo de producto en vez de enfatizar el seguimiento de planes
formados probablemente con información obsoleta.
Principios Ágiles

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega

temprana y continúa de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardías del

desarrollo. Los procesos Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y

dos meses, con preferencia al periodo de tiempo más corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos

de forma cotidiana durante todo el proyecto.
PRINCIPIOS DEL MANIFIESTO ÁGIL

Los proyectos se desarrollan en torno a individuos motivados. Hay

que darles el entorno y el apoyo que necesitan, y confiarles la
ejecución del trabajo.

El método más eficiente y efectivo de comunicar información al

equipo de desarrollo y entre sus miembros es la conversación cara a
cara.

El software funcionando es la medida principal de progreso.

Los procesos ágiles promueven el desarrollo sostenible. Los

promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.

La atención continua a la excelencia técnica y el buen diseño mejora

la agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no

realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipo

auto-organizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más

efectivo para a continuación ajustar y perfeccionar su
comportamiento en consecuencia.
 ¿Qué ha cambiado?
La siguiente figura muestra la diferencia entre los métodos tradicionales de gestión y los métodos
ágiles.

Alcance Valor

Costo Tiempo Calidad Limitantes

Tradicional triángulo de acero Triángulo Ágil

Los métodos ágiles requieren que cambie la mentalidad de los métodos tradicionales. Mientras que
los métodos en cascada (waterfall) se enfocan en el alcance y lo utilizan para determinar los costos
y el tiempo, los frameworks ágiles se enfocan en el valor del negocio y lo utilizan para determinar la
calidad y los limitantes del desarrollo.

Aunque el modelo en cascada es más adecuado para entornos ordenados y/o predecibles, los
métodos ágiles tienen más éxito en entornos caóticos, ya que son métodos “caórdicos” (caos +
orden). Mientras que los métodos en cascada creen en un modelo de agente racional, los métodos
ágiles tienden a basarse en métodos de valor compartido. El método en cascada o waterfall,
implementa estructuras de comando y control, mientras que los métodos ágiles utilizan estructuras
más llanas y colaborativas basadas en ciclos de inspección – adaptación.

Comparación de métodos ágiles y tradicionales:

Enfoque Ágil Cascada (Waterfall)

Énfasis En las personas En los procesos
Dominio Impredecible/Explicativo Predecible
Documentación Mínima; solo lo necesario Excesiva
Garantía de calidad Centrada en el cliente Centrada en procesos
Estilo de proceso Iterativo Lineal
Organización Auto-organizada Gestionada
Planificación por adelantado Baja Alta
Perspectiva hacia el cambio Adaptabilidad Sostenibilidad
Priorización de Basada en el valor del negocio Fija en el plan del proyecto
requerimientos y se actualiza constantemente
Estilo de gestión Descentralizado Autocrático
Liderazgo Colaborativo; liderazgo Comando y control
servicial
Medida del desempeño Valor del negocio Conformidad con el plan
Retorno sobre la inversión Temprano/A lo largo del Al final de la vida del proyecto
proyecto
La siguiente figura muestra la diferencia entre los métodos tradicionales de gestión y los métodos
ágiles representados por un proyecto Scrum.

Tal como se ilustra en el diagrama anterior, los proyectos de Scrum se llevan a cabo en forma
iterativa, de forma que las funcionalidades se presentan al final de cada iteración (llamada sprint en
Scrum). De preferencia, se completan primero aquellas con el más alto valor de negocio. Varios
equipos interfuncionales trabajan en paralelo en los sprints a fin de entregar soluciones
potencialmente enviables al final de cada sprint. La cantidad de funcionalidades no terminadas
permanece alta hasta el final o casi hasta el final del proyecto.

Ya que cada sprint resulta en una solución final (que forma parte de producto general), existe un
objetivo medible que el equipo debe lograr. Esto asegura que el equipo avance según sea el caso, y
que el proyecto sea completado a tiempo. Los métodos tradicionales no presentan tales
verificaciones a tiempo y, por lo tanto, pueden resultar en situaciones donde el equipo se desvía del
programa y termina con demasiado trabajo al final.

Debido a que el cliente interactúa regularmente con el Equipo Scrum, el trabajo completado se revisa
constantemente; por ello, existe una garantía de que el avance cumple con las especificaciones del
cliente. En la gestión tradicional de proyectos, no existe tal interacción, ya que el trabajo se lleva a
cabo en silos y no hay una funcionalidad presentable sino hasta el final del proyecto.
En los proyectos complejos, donde el cliente no tiene en claro lo que será el producto final, y donde
las funcionalidades del producto final cambian constantemente, el modelo iterativo es más flexible
al asegurar que tales cambios puedan ser incluidos mientras se trabaja. En la gestión tradicional de
proyectos se dificulta ajustar tales funcionalidades cambiantes.

Sin embargo, en el caso de proyectos sencillos con funcionalidades bien definidas, y donde el equipo
cuenta con experiencia para completar tales proyectos y pueden hacer estimaciones precisas, el
método en cascada puede ser exitoso.

Métodos Ágiles

Valores centrales Características Roles

Modelo iterativo con time
– box y con equipos auto –
 Control de proceso organizados.
empírico Los procesos tales como
Scrum  Auto – organización Crear el Sprint Backlog,  Product Owner
 Colaboración Crear entregables, Refinar  Scrum Master
 Priorización basada el Backlog Priorizado del  Equipo Scrum
en valor Producto, y Retrospectiva
 Time – boxing del sprint son parte de
 Desarrollo Iterativo cada sprint.
Daily Standup para la
comunicación abierta.
Desarrollo Propiedad individual de  Project manager
basado en clase; modelación de  Chief architect
funcionalidades Planear, diseñar y crear objeto de dominio; equipo  Development
(Feature Driven por funcionalidad. de funcionalidad; manager
Develpment) modelación inicial;  Chief programmer
configuración de model Class owner
storming management, y  Domain expert
desarrollos frecuentes.
Programación  Simplicidad Se enfoca en las buenas  XP Coach
Extrema  Comunicación prácticas del desarrollo de  XP Customer
(Extreme  Retroalimentación software; programación  XP Programmer
Programming)  Valor por partes, Desarrollo  XP Administrator
 Respeto guiado por pruebas,  XP Tracker
propiedad colectiva del  XP Tester
código y refactorización.
Métodos de  Se enfoca en la Fase de pre-proyecto, fase  Advisor user
desarrollo de necesidad del del ciclo de vida del  Ambassador user
sistemas negocia. proyecto y fase post –  Analista
dinámicos  Entrega a tiempo. proyecto. Estudio de  Arqwuitecto
(Dynamic  Colaborativo. viabilidad, estudio del  Developer
Systems  Nunca se negocio, iteración del  Executive Sponsor
Development compromete la modelo funcional,  Project Manager
Methods) calidad. iteración de diseño y  Stakeholder
 Desarrollo iterativo. construcción, e  Tester
 Crear en forma implementación.
 Visionero
incremental con
bases firmes.
  Comunicación clara y
continua
 Demostrar control

Otros métodos ágiles

Proceso Proceso Unificado Proceso Unificado

Crystal Lean Kanban Unificado Ágil Ecencial (Agile Abierto (Open
Clear Development Development (Agile Unified Unified Process) Unified Process)
Process)
Cuestionario del capítulo

1. ¿Cuál de las siguientes opciones NO es una característica común de la gestión adaptable de

proyectos (adaptive Project management)
A. Desarrollo iterativo del producto
B. Grandes cantidades de planificación por adelantado
C. Tiempo reducido para la comercialización
D. Entrega flexible del producto

2. Usted es el CEO de una empresa que opera cuatro proyectos distintos. ¿Para cuál
implementaría las metodologías ágiles?
A. La construcción de una unidad habitacional de cinco pisos con seis departamentos
en cada nivel.
B. Trabajos en la décima etapa de un proyecto a largo plazo de implementación de
software en el cual los requerimientos de dicho proyecto estuvieron claramente
definidos y la entrega ha cumplido hasta el momento con dichos requerimientos.
C. El desarrollo de una tecnología de software para un cliente que busca un ejercicio
de gestión de cambio que implica una identificación de las prácticas actuales, así
como el desarrollo de un plan de acción del proceso a realizarse, dependiendo de
la visión del equipo de administración.
D. La producción de un automóvil en una fábrica con base en un un prototipo
previamente desarrollado.

3. ¿Cuáles de las siguientes NO es parte del Manifiesto Ágil?

A. Promover individuos sobre procesos.
B. Responder al cambio en vez de hacer planes a largo plazo.
C. Contar con un equipo especializado en vez de un equipo interfuncional.
D. Un software funcionando es más importante que la documentación integral.

4. Como Project Manager que implementa prácticas ágiles en su organización, ¿Cuál de los
siguientes principios NO implementaría?
A. Los empleados técnicos y de negocio deben trabajar juntos.
B. Documentar cada detalle del nuevo software antes de permitir su lanzamiento.
C. Mantener equipos co-ubicados y promover la comunicación frente a frente.
D. Aceptar requerimientos cambiantes, aun durante el desarrollo.

5. ¿Cuál de las siguientes opciones NO es verdadera respecto a las metodologías ágiles?

A. Las metodologías ágiles hacen énfasis en las personas en vez de los procesos.
B. Las metodologías ágiles promueven una mínima documentación, a diferencia de la
técnica de cascada.
C. Las metodologías ágiles recomiendan un estilo de liderazgo basado en el mando.
D. Las técnicas ágiles se enfocan en la adaptabilidad del proyecto.
 DESCRIPCIÓN DE SCRUM
Scrum es un framework ágil para la gestión de proyectos. Emplea un enfoque adaptivo e iterativo
para la gestión de proyectos y el desarrollo de productos. Fue formulado como un medio más rápido
y más flexible para la entrega del mayor ___________ en la menor cantidad de ____________.

Según la Guía para Cuerpo de conocimiento de Scrum (Guía SBOK™, 3era Edición), el framework de
Scrum se puede entender mejor a través de principios, proceso y aspectos base.

Principios de Scrum

1. Control del proceso empírico

Scrum prescribe la toma de decisiones basada en la observación y experimentación en vez
de la planificación detallada por adelantado.

2. Auto – organización
A diferencia del estilo tradicional de gestión de comando y control, Scrum enseña que los
trabajadores de hoy en día cuentan con mucho más conocimiento para ofrecer que solo su
experiencia técnica y que entregan mayor valor cuando se auto-organizan.

3. Colaboración
Scrum enseña que el desarrollo de productos es un proceso de creación de valor compartida
que necesita que todos los stakeholders trabajen e interactúen juntos para entregar el
mayor valor.
 4. Priorización basada en valor (Value-based Prioritization)
La entrega del mayor valor en la menor cantidad de tiempo requiere priorizar y dividir lo que
habrá de hacerse de lo que necesita hacerse.

5. Time-boxing
El tiempo se considera un obstáculo limitante y el time-boxing se utiliza como el ritmo al que
deben trabajar y contribuir los stakeholders.

6. Desarrollo iterativo
En los proyectos complejos, donde el cliente tal vez no pueda definir requerimientos muy
concretos, o no está seguro de lo que pudiera ser el producto final, el modelo iterativo es
más flexible que asegurar que cualquier cambio que solicite el cliente se pueda incluir como
parte del proyecto.

Un principio clave de Scrum es el hecho de que los requerimientos exactos a largo plazo relacionados
a cada proyecto no se pueden entender en su totalidad ni definirse al principio del proyecto,
especialmente en mercados volátiles que cambian rápidamente y donde el enfoque debe radicar en
hacer que el equipo sea lo suficientemente flexible a fin de incorporar los requerimientos
cambiantes. Los métodos de desarrollo tradicionales y predecibles (tales como los métodos de
cascada) no tienen la capacidad para manejar tales cambios. Por lo tanto, Scrum beneficia
especialmente a proyectos complejos con mayor _________________________ donde el pronóstico
a largo plazo sería de alto riesgo.

Aspectos de Scrum

Durante un proyecto Scrum, se deben atender y administrar sus aspectos. Los cinco aspectos de
Scrum son los siguientes:

1. Organización
2. Justificación del negocio
3. Calidad
4. Cambio
5. Riesgo
 Procesos de Scrum

Los procesos de Scrum abordan actividades específicas y el flujo de un proyecto Scrum. Existe un
total de diecinueve procesos que aplican a todos los proyectos.

Capítulo Fase Procesos fundamentales de Scrum

SBOK

1. Crear la visión del proyecto

2. Identificar al Scrum Master y stakeholder (s)
3. Formar Equipos Scrum
4. Desarrollar épica(s)
8 Inicio 5. Crear el Backlog Priorizado del Producto
6. Realizar la planificación de lanzamiento

7. Crear historias de usuario

8. Estimar historias de usuario
9. Comprometer historias de usuario
10. Identificar tareas
9 11. Estimar tareas
Planificación y estimación 12. Crear el Sprint Backlog

13. Crear entregables

14. Realizar Daily Standup
10 Implementación 15. Refinar el Backlog Priorizado del Producto

16. Demostrar y validar el Sprint

11 Revisión y retrospectiva 17. Retrospectiva del sprint

18. Enviar entregables

12 Lanzamiento 19. Retrospectiva del proyecto

Para los proyectos a grande escala que requieren de la coordinación entre varios equipos, existen
tres procesos de Scrum adicionales y también procesos específicos definidos cuando se implementa
Scrum a nivel de empresa. Dichos procesos adicionales se resumen en la siguiente tabla.

Capítulo Aplicabilidad Procesos adicionales de Scrum

1. Crear componentes de grandes

proyectos
13 Scrum para grandes proyectos 2. Realizar y coordinar sprints
3. Preparar el lanzamiento de grandes
proyectos
 4. Crear componentes de programa o
portafolio
5. Revisar y actualizar el Scrum
Guidance Body
14 Scrum para la empresa 6. Crear y refinar el backlog del
programa o portafolio
7. Coordinar los componentes del
programa o portafolio
8. Retrospectiva de los lanzamientos
del programa o portafolio

Ventajas de Scrum

Algunos de beneficios clave del uso de Scrum en cualquier proyecto son los siguientes:

1. _________________: El control del proceso empírico y el desarrollo iterativo hacen que los
proyectos sean adaptables y abiertos a la incorporación del cambio.

2. _________________: Todos los indicadores información tales como un Scrumboard y el

Sprint Burndown Chart se comparten, lo cual conduce a un ambiente de trabajo abierto.

3. _________________ continua: La retroalimentación continua se proporciona a través de los

procesos de Realizar Daily Standup y Demostrar y validar el Sprint.

4. _________________ continua: Los entregables se mejoran progresivamente sprint por

sprint a mediante el proceso de Refinar el Backlog Priorizado del Producto.

5. Entregar continua el valor: Los procesos iterativos permiten la entrega continua de valor
tan frecuentemente como el cliente lo requiera a través

6. Ritmo sostenible: Los procesos de Scrum están diseñados para que las personas
involucradas puedan trabajar a un ritmo sostenible que, en teoría, puede continuar
indefinidamente.

7. Entrega anticipada de alto valor: El proceso de Crear el Backlog Priorizado del Producto
asegura que los requisitos de mayor valor del cliente sean los primeros en cumplirse.

8. Proceso de desarrollo eficiente: El Time-boxing y la reducción al mínimo del trabajo que no

es esencial conducen a mayores niveles de eficiencia.

9. Motivación: Los procesos de Realizar Daily Standup y Retrospectiva del sprint conducen a
mayores niveles de motivación entre los empleados.
10. Resolución de problemas en forma más rápida: La colaboración y co-ubicación de equipos
interfuncionales conducen a la resolución de problemas con mayor rapidez.

11. Entregables efectivos: El proceso de Crear el Backlog Priorizado del Producto y las revisiones
periódicas después de la creación de entregables aseguran entregas eficientes al cliente.

12. Centrado en el cliente: Poner énfasis en el valor del negocio y tener el enfoque de
colaboración con los stakeholders asegura un marco orientado al cliente.
 13. Ambiente de alta confianza: Los procesos de Realizar Daily Standup y Retrospectiva del
sprint promueven la transparencia y colaboración, dando lugar a un ambiente de trabajo de
alta confianza que garantiza una baja fricción ente los empleados.

14. Responsabilidad colectiva: El proceso de Comprometer historias de usuario permite que los
miembros del equipo hagan suyo el proyecto y su trabajo lleve a una mejor calidad.

15. Alta velocidad: Un framework de colaboración permite a los equipos interfuncionales

altamente cualificados alcanzar su potencial y una alta velocidad.

16. Ambiente innovador: Los procesos de Retrospectiva de sprint y Retrospectiva del proyecto
crean un ambiente de introspección, aprendizaje y capacidad de adaptación que llevan a un
ambiente de trabajo innovador y creativo.
*Referencia: Guía SBOK ™, 3era Edición. Páginas 4-5.

Cuestionario del capítulo

1. El control de proceso empírico es un principio de Scrum que…

A. Se utiliza en casos donde las entradas están claramente definidas.
B. Se enfoca en ofrecer control por medio de inspecciones frecuentes y adaptaciones
de procesos que están perfectamente definidos.
C. Se implementa en situaciones donde el proceso genera salidas impredecibles.
D. Es útil cuando una entrada específica siempre ofrece una salida particular.

2. Todas las siguientes son parte de los principios de Scrum, EXCEPTO:

A. Auto-organización
B. Time-boxing
C. Priorización basada en valor
D. Control de proceso definido

3. ¿Para cuál de los siguientes entornos es más adecuado el framework Scrum?

A. El desarrollo de productos con tecnología de punta
B. Requerimientos que cambian frecuentemente
C. Mercados híper-competitivos y volátiles
D. Todos los anteriores

4. ¿Cuál es el resultado del so de Scrum para el desarrollo de un producto?

A. Transparencia en todo el Equipo Scrum y los stakeholders
B. Ambiente adaptable de desarrollo del producto
C. Se desarrolla primero la oferta del máximo valor del negocio
D. Todas las anteriores

5. ¿En Scrum qué significa la entrega priorizada?

A. Se completará primero las características más sencillas y que no requieran mucha
participación por parte del equipo.
B. Se concluirán primero las características con la menor independencia o sin
independencia alguna a fin de asegurar una entrega fluida e interrumpida.
C. Se concluirán primero las características que ofrecen el máximo valor del negocio.
D. Las características se desarrollan por orden de llegada (del inglés: first-in, first-out
basis).
 ROLES DE SCRUM
Los roles Scrum se clasifican en dos amplias categorías:

 Roles centrales: estos roles son obligatorios para el desarrollo del producto en un proyecto;
están _________________ con el proyecto y son, en última instancia, responsables del éxito
de cada sprint en el proyecto, así como del proyecto en su conjunto.

 Roles no centrales: estos roles no son obligatorios en los proyectos Scrum. Los roles no
centrales pueden ser miembros del equipo que están interesados en el proyecto, que no
cuentan con un rol formal en el mismo, que pudieran interrelacionarse con el equipo, pero
que tal vez no sean responsables del éxito del proyecto. Los roles no centrales también
deben tomarse en cuenta en cualquier proyecto Scrum.

Roles centrales

Existen tres roles centrales en Scrum que son, en última instancia, responsables de cumplir con los
objetivos del proyecto. Son: el Product Owner, el Scrum Master y el equipo Scrum. Juntos se les
conoce como el Equipo Principal de Scrum. Es importante destacar que, de estos tres roles, ninguno
tiene autoridad sobre los demás.
La siguiente figura presenta una imagen de los roles Scrum.

Guía SBOK™, Roles de Scrum – Descripción general

Rol central: Product Owner
El product Owner representa a los stakeholders y es el responsable encargado de asegurar que el
Equipo Scrum entregue valor. El Product Owner redacta el requerimiento del negocio en forma de
_______________ con aportes de los miembros del Equipo principal de Scrum y administra el
Backlog Priorizado del Producto. En algunos casos, los miembros del Equipo Scrum pueden escribir
historias del usuario bajo la supervisión del Product Owner. El Product Owner tiene también la
responsabilidad de asegurar que exista en el Equipo Scrum una clara comunicación de las
funcionalidades de producto y, por lo tanto, se le denomina comúnmente: ___________________.
La siguiente tabla enumera las responsabilidades del Product Owner durante los distintos procesos
de un proyecto Scrum.
Proceso Responsabilidades del Product Owner
Crear la visión del proyecto  Define la visión del proyecto
 Ayuda a crear el acta constitutiva del proyecto y su presupuesto
Identificar al Scrum Master  Ayuda a finalizar la elección del Scrum Master para el proyecto
y Stakeholder(s)  Identifica al (los) stakeholders(s)
Formar el Equipo Scrum  Ayuda a determinar quiénes serán los miembros del Equipo
Scrum
 Ayuda a desarrollar un plan de colaboración
 Ayuda a desarrollar el plan del equipo con el(los) Scrum Master(s)
Desarrollar épica(s)  Crea épica(s) y prototipos (personas)
Crear el Backlog Priorizado  Prioriza los elementos en el Backlog Priorizado del producto
del Producto  Define los criterios de terminado
Realizar la planificación del  Elabora el cronograma de planificación del lanzamiento
lanzamiento  Ayuda a determinar la duración del sprint
Crear historias de usuario  Ayuda a crear historias de usuario
 Define los criterios de aceptación para cada historia de usuario
Estimar historias de usuario  Aclara las historias de usuario
Comprometer historias de  Facilita el Equipo Scrum y compromete historias de usuario
usuario
Identificar tareas  Explica las historias de usuarios al Equipo Scrum mientras elabora
la lista de tareas
Estimar tareas  Brinda orientación y aclaraciones al Equipo Scrum en la
estimación de los esfuerzos para las tareas
Crear el Sprint Backlog  Aclara los requerimientos al Equipo Scrum mientras elabora el
Sprint Backlog.
Crear entregables  Aclara los requerimientos empresariales al Equipo Scrum
Refinar Backlog Priorizado  Refina (groom) el Backlog Priorizado del Producto
del Producto
Demostrar y validar el  Acepta/rechaza los entregables
sprint  Proporciona la retroalimentación necesaria al Scrum Master y a
los equipos Scrum
 Actualiza el plan de lanzamiento y el Backlog Priorizado del
Producto
Enviar entregables  Ayuda a enviar los lanzamientos del producto y se coordina con el
cliente.
Retrospectiva del proyecto  Participa en las reuniones de retrospectiva del sprint.
En lo correspondiente al rol del Product Owner en un determinado proyecto, puede haber un Chief
Product Owner en los grandes proyectos; un Program Product Owner en un programa; o un
Portafolio Product Owner para un portafolio.
Voz del cliente

 El cliente es el stakeholder más importante para cualquier empresa. Por lo tanto, es de suma
importancia entender sus necesidades y requerimientos. El término “voz del cliente” hace
referencia a las necesidades ______________ y ___________ del cliente, mismas que se
deben entender bien antes de diseñar cualquier producto o servicio.

 Para cualquier proyecto Scrum más importante, el cliente puede ser:

o Interno (dentro de la misma organización)
o Externo (fuera de la organización)
Rol central: Scrum Master
La principal responsabilidad del Scrum Master es garantizar que todos los miembros del equipo
principal de Scrum sigan correctamente el proceso Scrum, incluyendo el Product Owner. El Scrum
Master es la persona responsable de garantizar que la gestión del proyecto avance con fluidez y que
los miembros del Equipo Scrum tengan todas las herramientas necesarias para realizar el trabajo. El
rol del Scrum Master se basa en el concepto del _________________ en el cual los líderes logran
resultados mediante la atención que brindan a las necesidades de quienes dirigen.

La siguiente tabla presenta una lista de las responsabilidades del Scrum Master durante los
diferentes procesos de un proyecto Scrum.

Proceso Responsabilidades del Scrum Master

Identificar al Scrum Master y  Ayuda a identificar al(los) stakeholder(s) para el proyecto
Stakeholder(s)
Formar del Equipo Scrum  Facilita la selección del Equipo Scrum
 Facilita la creación del plan de colaboración y el plan de
desarrollo del equipo
 Garantizar que los recursos de respaldo estén disponibles
para el funcionamiento del proyecto sin problemas
Desarrollar de épica(s)  Facilita la creación de épica(s) y prototipos (Personas)
Crear el Backlog Priorizado del  Ayuda al Product Owner en la creación del Backlog
Producto Priorizado del Producto y en la definición de los criterios de
terminado
Realizar la planificación del  Coordinan la creación del cronograma de planificación del
lanzamiento lanzamiento
 Determina de la duración del Sprint
Crear historias de usuario  Ayuda al Equipo Scrum en la creación de historias de
usuario y sus criterios de aceptación
Estimar historias de usuario  Organiza las reuniones del Equipo Scrum para estimar
historias de usuario
Comprometer historias de  Organiza las reuniones del Equipo Scrum para estimar
usuario historias de usuario.
Identificar tareas  Ayuda al Equipo Scrum a crear lista de tareas para el
siguiente sprint
Estimar tareas  Ayuda al Equipo Scrum a estimar el esfuerzo necesario para
completar las tareas acordadas para el sprint
Crear el Sprint Backlog  Ayuda al Equipo Scrum a desarrollar el Sprint Backlog y
asegura del Sprint Burndown Chart
Crear entregables  Ayuda al Equipo Scrum a crear los entregables acordados
para el sprint
 Ayuda a actualizar el Scrumboard y el Impediment Log
Realizar Daily Standup  Se asegura de que el Scrumboard y el Impediment Log
permanezcan actualizados
Refinar el Backlog Priorizado del  Organiza las reuniones de revisión del Backlog Priorizado
Producto del Producto
Demostrar y validar sprints  Facilita la presentación de los entregables completados por
el Equipo Scrum para la aprobación del Product Owner
Retrospectiva del Sprint  Garantiza que exista un ambiente ideal para el Equipo
Scrum del proyecto en los sucesivos sprints
Retrospectiva del proyecto  Representa al equipo principal de Scrum para proporcionar
lecciones del proyecto actual en caso de ser necesario
Nótese que el rol de Scrum Master es muy distinto al rol que desempeña el Project Manager en un
modelo tradicional de cascada en la gestión de proyectos donde el manager trabaja como
administrador o líder del proyecto. El Scrum Master trabaja como facilitador y se encuentra en el
mismo nivel jerárquico que los demás en el Equipo Scrum.
El Scrum Master instruye también a todos aquellos preocupados con los valores y métodos de Scrum.
Esta responsabilidad es la más crítica e importante al principio, cuando se hace la transición al
framework de Scrum.
En lo correspondiente al rol del Scrum Master en un proyecto, puede haber un Chief Scrum Master
en los grandes proyectos; un Program Scrum Master para un programa, o un Portfolio Scrum Master
para un portafolio.
Rol central: Equipo Scrum
El Equipo es un grupo o equipo de ___________ personas responsables de entender los requisitos
del negocio que especifique el Product Owner, estimar las historias del usuario y crear los
___________________ del proyecto.

Características del Equipo Scrum

Auto-organizado:

 Scrum fomenta el concepto del equipo auto-organizado, donde este cuenta con
______________ colectiva de un proyecto.

 Los miembros del equipo participan en todas las decisiones relacionadas a la entrega del
proyecto y eligen la mejor forma de lograr el trabajo sin interferencia externa.

Interfuncional:

 El Equipo Scrum es interfuncional (cross-functional), de tal forma que todas las habilidades
y demás requerimientos necesarios para concluir el trabajo se encuentran disponibles
internamente sin depender de alguien ajeno al equipo.

 El modelo de Equipo Scrum está diseñado para optimizar la flexibilidad y la productividad.

 Un equipo interfuncional se enfoca más en una meta común.

Co-ubicación y comunicación frente a frente:

 Scrum permite la creación de equipos auto-organizados por medio del fomento a la co-
ubicación de todos los miembros del equipo y recomienda la comunicación frente a frente
entre todos los miembros del equipo.

 Un equipo co-ubicado conformado por expertos funcionales que colaboran para lograr una
meta en común logrará el éxito con mayor rapidez que un equipo separado por función.

Entrega iterativa del producto:

 Los equipos Scrum entregan productos en forma iterativa e incrementalmente,

maximizando las oportunidades de retroalimentación.

 La entrega incremental los productos “terminados”, asegura que siempre esté disponible
una versión de un producto funcional potencialmente enviable.
La siguiente tabla presenta una lista de las responsabilidades del Equipo Scrum durante los distintos
procesos de un proyecto Scrum.
Dinámicas del equipo

El enfoque particular de Scrum en su forma de hacer las cosas pudiera verse como algo sumamente
difícil para un nuevo Equipo Scrum. Un nuevo equipo pasa por un patrón de cuatro etapas a
medida que evoluciona durante un proyecto Scrum. A este patrón de dinámicas de grupo se le
conoce como Modelo Tuckman, propuesto por primera vez por Bruce Tuckman en 1965.

Las cuatro etapas del modelo son las siguientes:

________________ : Esto a menudo se experimenta como un escenario ameno, ya que todo es

nuevo y el equipo aún no ha encontrado ninguna dificultad con el proyecto.

Enfrentamiento: Durante esta etapa, el equipo trata de cumplir con el trabajo; sin embargo, puede
encontrar conflictos de poder y, con frecuencia, existe caos o confusión entre los miembros del
equipo.

______________ : Es cuando el equipo empieza a madurar, a resolver sus diferencias internas, y a

encontrar soluciones para así trabajar juntos. Se considera un período de ajuste.

Desempeño: Durante esta etapa, el equipo está unido y opera en su nivel más alto en términos de
rendimiento. Los miembros se han convertido en un equipo eficiente de profesionales que son
consistentemente productivos.

La siguiente figura muestra las etapas del modelo Tuckman para el desarrollo de grupos.
Selección del equipo

El equipo Scrum (equipo de desarrollo) es el único de cualquier proyecto Scrum. Es importante

seleccionar a los miembros adecuados a fin de mantener el desempeño de todo el equipo. Los
miembros del Equipo Scrum son generalistas- especialistas.

Los miembros ideales del Equipo Scrum son independientes, auto-motivados, se enfocan en el
cliente y tienen un alto sentido de responsabilidad y colaboración. El equipo debe ser capaz de
fomentar un ambiente de reflexión independiente y de tomar decisiones con el fin de extraer los
mayores beneficios de la estructura.

Al momento de seleccionar a los equipos, otro aspecto importante es establecer __________

(suplentes) para cada persona. Este procedimiento garantiza que no haya una gran pérdida de
productividad debido a la ausencia de miembros importantes. Cada integrante del equipo respaldará
a un miembro “especialista”, lo cual mejora la serie de habilidades de los miembros del equipo.

Ventajas de equipos interfuncionales

En Scrum se utiliza un método de equipo interfuncional debido a que ofrece las ventajas que se
describen a continuación:

 Toma de decisiones en forma rápida: un equipo interfuncional es un grupo pequeño que

consiste en expertos funcionales que pueden llegar a una meta en común con mayor
rapidez que los equipos tradicionales orientados en funciones.

 Comunicación mejorada: los equipos interfuncionales generalmente están ____________,

lo cual permite una comunicación fluida frente a frente entre los miembros del equipo. Por
lo tanto, el equipo interactúa con frecuencia, lo cual conduce a un proceso fluido que
permite compartir conocimientos.

 Orientación objetiva: Los equipos interfuncionales en Scrum están sumamente enfocados

en el resultado deseado. El Equipo Scrum cuenta con una serie de objetivos durante un
sprint y es lo suficientemente flexible para realizar cambios a dichos objetivos antes del
siguiente sprint.

 Responsabilidad colectiva: El equipo en un conjunto es responsable de la entrega de los

resultados. Cualquier éxito o fracaso se maneja a nivel de equipo.

 Innovación continua: El uso de expertos en distintas áreas como parte de un equipo

interfuncional permite un intercambio de ideas, lo cual fomenta el pensamiento creativo.
 Roles no centrales

Los roles no centrales son aquellos que no son obligatorios para un proyecto Scrum y pudieran estar
continua o directamente involucrados en el proceso de Scrum. Sin embargo, es importante
conocerlos, ya que juegan un papel importante en los proyectos Scrum.

Los roles no centrales pueden incluir a los siguientes:

1. Stakeholder es un término colectivo que incluye a clientes, usuarios y patrocinadores, que

generalmente interactúan con el Product Owner, el Scrum Master y el Equipo Scrum para
proporcionarles las _____________ y facilitar la creación del producto del proyecto, servicio,
o cualquier otro resultado. Los stakeholders influyen en el proyecto a lo largo del desarrollo
del mismo. Los stakeholders también pueden desempeñar un rol en los procesos
importantes de Scrum tales como: Desarrollar épica(s), Crear el Backlog Priorizado del
Producto, Realizar la planificación del lanzamiento y Retrospectiva del sprint.
 El cliente es la persona o la organización que adquiere el producto, servicio o
cualquier otro resultado del proyecto. Para cualquier organización, dependiendo
del proyecto, puede haber clientes internos (dentro de la misma organización)

 Los usuarios son las personas u organizaciones que utilizan directamente el

producto, servicio o cualquier otro resultado del proyecto. Al igual que los clientes,
para cualquier organización, puede haber usuarios internos y externos. En algunas
industrias los clientes y los usuarios pueden ser los mismos.

El patrocinado (sponsor) es la persona o la organización que provee recursos y apoyo para

el proyecto. El patrocinador es también el stakeholder a quien todos le deben rendir cuentas
al final.

En ocasiones, la misma persona u organización puede desempeñar múltiples roles de

stakeholders; por ejemplo, el patrocinador y el cliente pueden ser el mismo.

2. El concepto de vendedor incluye a individuos u organizaciones externas que ofrecen

productos y servicios que no están dentro de las competencias básicas de la organización
del proyecto.

3. El Scrum Guidance Body, o SGB por sus siglas en inglés, es un rol _______________, pero
altamente recomendado para formalizar las prácticas organizaciones relacionadas a Scrum.
Por lo general se compone de un grupo de documentos y/o un grupo de expertos
normalmente involucrados en la definición de los objetivos relacionados a la calidad,
regulaciones gubernamentales, seguridad y demás parámetros clave de la organización.
Estos objetivos guían el trabajo que lleva a cabo el Product Owner, el Scrum Master y el
Equipo Scrum. El Scrum Guidance Body también ayuda a captar las mejores prácticas que
deben utilizarse en todos los proyectos de Scrum en la organización.

El Scrum Guidance Body no toma decisiones relacionadas al proyecto. En cambio, actúa

como una estructura de consultoría u orientación para todos los niveles de la jerarquía en la
organización del proyecto: portafolio, programa y proyecto. Los equipos Scrum tienen la
opción de solicitar el apoyo del Scrum Guidance Body sobre cualquier recomendación que
requieran.
Cuestionario del capítulo

1. ¿Cuáles de los siguientes es el rol central de Scrum?

A. Product Owner
B. Stakeholder
C. Patrocinador del proyecto
D. Project Manager
2. ¿Quién es responsable de proporcionar al Equipo Scrum un ambiente favorable para la
elaboración de entregables?
A. Scrum Master
B. Product Owner
C. Scrum Guidance Body
D. Stakeholders externos
3. ¿Quién es responsable de dar a conocer las prácticas de Scrum a los miembros del Equipo
Scrum?
A. Scrum Master
B. Product Owner
C. Equipo Scrum
D. Scrum Guidance Body
4. ¿Quién es responsable de lograr al máximo valor del negocio del proyecto?
A. Scrum Master
B. Product Owner
C. Equipo Scrum
D. Stakeholders externos

5. ¿Quién es responsable de elaborar los entregables en el proceso de Crear entregables?

A. Chief Scrum Master
B. Portfolio Product Owner
C. Líder del Equipo Scrum
D. Equipo Scrum

6. Las ventajas de utilizar a un equipo interfuncional son:

A. Comunicación mejorada entre los miembros del equipo.
B. Toma de decisiones en forma rápida.
C. La responsabilidad individual se puede asignar a cada miembro del equipo,
dependiendo de su experiencia
D. A y B

7. ¿Quién es responsable de decidir sobre los criterios de aceptación de varias tareas?

A. Scrum Master
B. Product Owner
C. Líder del Equipo Scrum
D. Equipo Scrum

8. ¿Quién representa la voz del cliente?

A. Chief Scrum Master
B. Product Owner
 C. Líder del Equipo Scrum
D. Los miembros del Equipo Scrum

9. Juan es la persona responsable de resolver conflictos entre los miembros del equipo Scrum,
¿Qué rol tiene en el proyecto Scrum?
A. Scrum Master
B. Product Owner
C. Líder del Equipo Scrum
D. Equipo Scrum
 FASES DE SCRUM

La siguiente figura muestra el flujo de trabajo en Scrum.

 El ciclo de Scrum empieza con la fase de inicio, durante la cual se determina la visión del
proyecto y se elabora el Backlog Priorizado del Producto.

 Después, el trabajo se completa en una serie de sprints. Cada sprint inicia con una reunión
de planificación de sprint, durante la cual se determinan las tareas para el siguiente sprint
(los elementos en el Backlog Priorizado del Producto con mayor prioridad).

 El sprint generalmente tiene una duración de entre _____________ y produce un

incremento de producto potencialmente enviable.

 Los ____________ Standups se llevan a cabo durante el sprint, donde los miembros del
Equipo Scrum reportan el trabajo terminado, el trabajo por hacer y cualquier impedimento
que hayan experimentado los miembros.

 Al final del sprint se hace una reunión de revisión del sprint, durante la cual se presenta al
Product Owner una demostración de los entregables y decide aceptarla o rechazarla.

 El ciclo de sprint concluye con una reunión final de retrospectiva del sprint.
Un proyecto Scrum sigue un modelo de cinco fases. Las cinco fases son las siguientes:

1. Inicio
2. Planificación y estimación
3. Implementación
4. Revisión y retrospectiva
5. Lanzamiento
 Fases de inicio

La primera fase en un proyecto Scrum es la fase de inicio. Los procesos relacionados a la iniciación
de un proyecto son: Crear la visión del proyecto, Identificar al Scrum Master y stakeholder(s), Formar
el Equipo Scrum, Desarrollar de épica(s), Crear el Backlog Priorizado del Producto y Realizar la
planificación del lanzamiento.

Proceso 1: Crear la visión del proyecto

Un proyecto Scrum inicia con el proceso de Crear la visión del proyecto. La creación de la visión del
proyecto es responsabilidad del Product Owner. El Product Owner es responsable de obtener los
requerimientos de los stakeholders y transformarlos en la visión del producto. Dicha visión forma
parte de los cimientos del proyecto. No se requiere que la visión del proyecto sea integral y detallada,
y debe enfocarse en el problema en vez de la solución.

Hay varías de entradas en este proceso, tales como el Caso de negocio del proyecto, la Visión de la
empresa, la prueba del concepto, entre otros; sin embargo, la mayoría de estas entradas son
opcionales. La única entrada obligatoria en este proceso es el caso del negocio del proyecto (Project
Business Case), el cual expresa la lógica para arrancar el proyecto. El Product Owner debe entender
el caso del negocio del proyecto. El Product Owner también debe conocer y entender el escenario
del mercado.

La principal entrada del proceso de Crear la visión del proyecto es una ________________, formal y
bien estructurada, que explique la necesidad del negocio que el proyecto busca satisfacer.
Proceso 2: Identificar al Scrum Master y stakeholder (s)

El segundo paso al iniciar un proyecto Scrum es identificar al Scrum Master y stakeholder(s).

El Product Owner ayuda en la selección del Scrum Master. El Scrum Master ayuda al Product Owner
a lograr la visión del proyecto al ser el facilitador en jefe y mentor del Equipo Scrum. Es importante
seleccionar a un Scrum Master que esté comprometido en garantizar que el equipo cuente con un
ambiente de trabajo conductivo para la entrega satisfactoria del proyecto.

Importantes criterios de selección para el Scrum Master:

 Habilidades para resolver problemas: Es uno de los principales criterios a considerar al

seleccionar al(los) Scrum Master(s). El(los) Scrum Master(s) debe(n) tener las habilidades y
la experiencia necesarias para ayudar a eliminar cualquier impedimento que enfrente el
Equipo Scrum.

 Disponibilidad: El Scrum Master debe estar disponible para programar, supervisar y

organizar varias reuniones, incluyendo la reunión de planificación del lanzamiento, el Daily
Standup y otras reuniones relacionadas al sprint.

 Compromiso: El Scrum Master debe comprometerse a asegurar que el Equipo Scrum cuente
con un ambiente laboral conductivo para garantizar la entrega exitosa de proyectos Scrum.

 Estilo de ___________: El Scrum Master debe poseer las características esenciales que lo
conviertan en un líder servicial ideal. El Scrum Master debe implementar la escucha,
empatía, compromiso y percepción, y a la vez compartir el poder y la autoridad con los
miembros del equipo. Los líderes serviciales son administradores que logran resultados
enfocándose en el cumplimiento de las necesidades del equipo.

Es importante identificar a los stakeholders en el proyecto, tales como el patrocinador (sponsor), los
usuarios finales, los vendedores, etcétera, quienes experimentarán la necesidad del negocio o
ayudarán a cumplirla. Por lo tanto, una vez que está lista la visión del proyecto, el Product Owner
procede a identificar a todos los stakeholders en el proyecto actual.
Proceso 3: Formar el Equipo Scrum

Uno de los más importantes procesos en un flujo de Scrum es la formación del equipo Scrum, debido
a que es este, en última instancia, el que crea los entregables del proyecto, logrando, por lo tanto,
cumplir con la visión del proyecto.

Al equipo Scrum se le conoce también como equipo de ____________ . Un equipo Scrum ideal se
compone de entre seis a diez miembros. Tal como se analizó anteriormente, los miembros del Equipe
Scrum deben ser generalistas-especialistas; es decir, cada uno debe contar como conocimiento
general en distintas áreas y ser expertos en por lo menos una. No es únicamente la experiencia en la
materia lo que determina el éxito de los equipos auto-organizados, sino también las habilidades
interpersonales.

El Product Owner y el Scrum Master colaboran para formar el Equipo Scrum. Dicho equipo se forma
tomando en cuenta la visión del proyecto debido a que el tipo de proyecto y el tipo de industria son
factores cruciales al momento de seleccionar temas y expertos técnicos. No obstante, el Product
Owner y el Scrum Master pueden considerar una variedad de factores distintos, tales como
requerimientos de las personas, su disponibilidad y compromiso, así como la matriz de
requerimientos de habilidades.

Una vez seleccionado al Equipo Scrum, el equipo principal de Scrum: Product Owner, Scrum Master
y Equipo de Scrum, está completo. La principal salida de este proceso es un Equipo de Scrum
____________ y ____________.
Proceso 4: Desarrollar épica(s)

El cuarto proceso en la fase de inicio es Desarrollar épica(s). En la terminología de Scrum, una épica
se define como una ________________, amplia y sin refinar. Una épica es una amplia historia del
usuario, por lo general demasiado amplia como para completarse en un solo sprint, por lo que debe
fragmentarse en pequeñas historias del usuario en algún punto previo al desarrollo. El equipo
principal de Scrum inicia con la redacción de épicas basadas en la visión del proyecto. Dicho equipo
puede considerar otros factores tales como los requerimientos de cambio aprobados y rechazados,
leyes y regulaciones, contratos aplicables, etcétera.

El Product Owner es responsable de la creación de historias del usuario. Generalmente, el Product

Owner elabora las historias del usuario, aunque en algunos casos, las desarrolla el Equipo Scrum,
previa consulta con el Product Owner. Sin embargo, el Product Owner tiene la responsabilidad de
garantizar que los requerimientos del proyecto que presente el cliente se traduzcan en
requerimientos funcionales que el desarrollador pueda entender e implementar con facilidad.

Las dos principales salidas de este proceso son: ____________ y ______________ (del inglés
personas). Esta última es algo complementario para las épicas en el sentido de que ayudan al equipo
a entender mejor a los usuarios, sus requerimientos y metas. Los prototipos (persona) son personajes
ficticios muy detallados que representan a la mayoría de los usuarios y demás stakeholders que
pudieran no usar directamente el producto final.

Los prototipos se crean para identificar las necesidades de los usuarios. La creación de prototipos
específicos puede ayudar al equipo a entender mejor a los usuarios y sus necesidades y metas. Al
prototipo se le incluirán atributos muy específicos como su edad, género, nivel de educación,
ambiente, intereses y metas. Una cita que ilustre las necesidades del prototipo puede incluirse
también.

Ejemplos de prototipos en el portal de internet de una agencia de viajes:

Vanessa tiene 39 años y vive en San Francisco. Mateo es un empresario que viaja
Después de una exitosa carrera como abogada, constantemente alrededor del mundo. Planea
ahora se dedica a su pasión por viajar. Le gusta su itinerario durante sus viajes y no le gusta
tener opciones de alojamiento y viajes aéreos y perder mucho tiempo en los sitios de internet
así poder elegir las mejores y más económicas de agencias de viajes. Busca un acceso práctico
opciones. Le molestan las páginas de internet en aerolíneas, así como hospedaje en los
lentas y desordenadas. lugares que visita con mayor frecuencia.
VANESSA, 39 AÑOS. VIAJERA MATEO, 25 AÑOS. HOMBRE DE NEGOCIOS

“Mi mochila esta siempre lista para poder “Prefiero una página de internet sencilla y
lanzarme a explorar el mundo” práctica donde pueda planear rápidamente mi
itinerario”.
Proceso 5: Crear el Backlog Priorizado del Producto:

Una vez que el equipo principal de Scrum desarrolla las épicas y los prototipos, el Product Owner
elabora el Backlog Priorizado del Producto, que consiste en una lista de características y
funcionalidades necesarias para cumplir con el proyecto. Es priorizada en el sentido de que, a los
elementos más valiosos, es decir, los que ofrecen el máximo valor ____________, se les asigna una
mayor ________________.

El Backlog Priorizado del Producto es un listado que, al

momento de convertirse en funcionalidad del producto
potencialmente enviable, presentará la visión del producto.

Es responsabilidad del Product Owner presentar el primer Backlog Priorizado del Producto.

El Backlog Priorizado por lo general contiene épicas, pero en ocasiones incluye también información
relacionada a conclusiones clave, tales como errores que fueron informados, requerimientos
funcionales y no funcionales, etcétera. A los elementos del Backlog Priorizado del producto se les
asignan puntos de estimación para indicar el tiempo y los recursos necesarios para completarlos
basado en características tales como el tamaño, la complejidad y experiencia necesaria.

En la priorización se toman en cuenta tres factores primordiales: valor, riesgo e incertidumbre y

dependencias. El equipo principal de Scrum puede utilizar varios métodos de priorización, tales como
los que se presentan a continuación:

 Esquemas simples: Los esquemas implican etiquetar elementos como prioridad “1”, “2”, “3”
o “alta”, “media” y “baja”, y así sucesivamente. Aunque se trata de un método sencillo y
directo, puede llegar a ser problemático, ya que a menudo hay una tendencia en etiquetar
todo como prioridad “1” o “alta”. Incluso los métodos de priorización tales como “alta”,
“media” y “baja” pueden encontrarse con dificultades similares.

 Priorización MoSCoW: El esquema MoSCoW obtiene su nombre de la versión en inglés de

las frases: “Debe tener” (Must have), “Debería tener” (Should have), “Podría tener” (Could
have) y “No tendrá” (Won’t have).

o “Debe tener” (Must have) – Requerimientos o características importantes que

deben ser incluidas, de lo contrario el producto no funcionaría o no tendría valor.

o “Debería tener” (Should have) – Elementos importantes que deberían ser incluidos
a fin de que funcione correctamente. Las alternativas pudieran ser más costosas o
tardadas.

o “Podría tener” (Could have) – Requerimientos que se consideran deseables, pero

no necesarios (se podría hacer si el tiempo y los recursos lo permiten).

o “No tendrá” (Won´t have)- Representa requerimientos que sería bueno tener, pero
que probablemente no se incluyan de momento.

 El método de los 100 puntos: El método de los 100 puntos (100-pint Method) fue
desarrollado en el 2003 por Dean Leffingwell y Don Widrig. Dicho método implica otorgar
100 puntos al cliente a fin de que los pueda utilizar para votar por las características que
 consideren más importantes. El objetivo es dar más peso a las historias de usuario que son
de mayor prioridad en comparación con las otras historias de usuario disponibles. Cada
miembro del grupo asigna puntos a las diversas historias de usuarios, dando más puntos a
las que opinan son más importantes. Al finalizar el proceso de votación, la priorización se
determina calculando el total de puntos asignados a cada historia de usuario.

 Análisis de kano: El análisis fue desarrollado en 1984 por Noriaki Kano y consiste en clasificar
las características o requisitos en cuatro categorías con base en las preferencias del cliente:

o Calidad atractiva (Exiters/Delighters): Características que son nuevas o de gran

valor para el cliente

o Calidad unidimensional (Satisfiers): Características que le ofrecen valor al cliente.

o Calidad requerida (Dissatisfiers): Características que, si no están presentes,

pudieran causar la insatisfacción del cliente respecto al producto, pero que no
afectan el nivel de satisfacción si se cuenta con ellas.

o Calidad indiferente (Indifferent): Características que no afectarán al consumidor de

ninguna manera y deben ser eliminadas.

La siguiente figura muestra un ejemplo del Análisis de Kano:

  Comparación por pares – En esta técnica, la comparación por pares (Paired
Comparison) es una técnica donde se prepara una lista de todas las historias de
usuario en el Backlog Priorizado del Producto. Después, cada historia de usuario se
toma en forma individual y se compara con otras historias en la lista, una a la vez.
Cada vez que se comparan dos historias de usuario, se toma una decisión en cuanto
a cuál de las dos es más importante. Por medio de este proceso, se puede generar
una lista priorizada de historias de usuario.

Proceso 6: Conducir la planificación del lanzamiento

En este proceso, el equipo de Scrum trabaja en la creación de un cronograma de planificación de

lanzamiento para proporcionar incrementos del producto a los stakeholders. El cronograma de
planificación del lanzamiento señala cuáles entregables deben ser lanzados al cliente, junto con los
intervalos planeados y fechas de lanzamiento.

Aunado a lo anterior, el equipo principal de Scrum define también la duración del sprint para un
proyecto. Una vez que la duración queda fija, por lo general permanece constante durante el
proyecto. Tiempo después durante el proyecto, cualquier cambio en la duración del sprint significa
que puede ser reducido debido a las mejoras en el ambiente del proyecto y a la velocidad con la que
trabaja el equipo. El equipo principal de Scrum planea el cronograma de lanzamiento y fija la duración
de sprint basado en las varias entradas, tales como las aportaciones de los stakeholders, la
declaración de visión del proyecto, el Backlog Priorizado del Producto, los requerimientos del
negocio y el calendario de días festivos.

El cronograma de planificación del lanzamiento debe planearse de tal forma que garantice que cada
lanzamiento proporcione un valor significativo al cliente. Cada sprint debe contar con una
funcionalidad _________________ como su salida; sin embargo, el cronograma de la planificación
del lanzamiento determina la fecha en que el entregable del sprint será presentado al stakeholder.

Un sprint puede tener un time – box de 1 a 6 semanas. Sin embargo, para obtener los máximos
beneficios de un proyecto Scrum, siempre se recomienda mantener el sprint con un time-box de
cuatro semanas o menos, a menos que existan proyectos con requerimientos muy estables donde
los sprints se pueden extender hasta 6 semanas.

PROYECTO
PLAN DE LANZAMIENTO PLAN DE LANZAMIENTO

Iteraciones
 Fase de planificación y estimación

Como parte de esta fase, el equipo principal del Scrum elabora, calcula y se compromete a las
historias del usuario; identifica y estima las tareas y elabora el Sprint Backlog.

Proceso 1: Crear historias de usuario

Este es el primer proceso en la fase de Planificación y estimación.

Una historia de usuario es una declaración (o grupo de declaraciones) que expresan una
funcionalidad deseada para el usuario final. Generalmente se fragmenta en bloques consecutivos
de tareas.

El formato de historia de usuario es el siguiente:

Como < rol/ prototipo de cliente> yo debería < requerimiento > a fin de <beneficio>

Las historias de usuario son importantes tanto para el equipo principal de Scrum como para los
Stakeholders, debido a que ayudan a mejorar la comunicación entre estos dos grupos. Los
requerimientos expresados en las historias de usuarios se pueden entender fácilmente y permiten
realizar mejores estimaciones. Las historias de usuario eliminan la necesidad de una documentación
detallada de los requerimientos del cliente. Se escriben en un lenguaje empresarial. En ocasiones, el
equipo principal de Scrum trabaja en el desarrollo de “temas”. Un tema es una colección de historias
de usuario relacionadas. Pueden contener uno o más épicas. Los múltiples temas se pueden asociar
con un producto, pero un tema no se puede asociar con más de un producto a la vez.

La principal responsabilidad en la elaboración de historias de usuario recae sobre el

________________. Este generalmente elabora las historias del usuario, pero en algunos casos es el
Equipo de Scrum quien las desarrolla mediante su consulta con el Product Owner.

El equipo principal de Scrum debe garantizar que los requerimientos del negocio del cliente se
traduzcan en requerimientos funcionales que el desarrollador pueda implementar y entender con
facilidad. Por lo tanto, el equipo principal de Scrum debe ser experto en la redacción en la redacción
de historias de usuario evaluación, estimables y con las que se pueda trabajar. La habilidad de
elaborar buenas historias de usuario toma tiempo para dominar; sin embargo, el equipo principal de
Scrum puede reducir el tiempo asistiendo a talleres de redacción de historias de usuario. El equipo
Scrum puede también dar seguimiento al modelo INVEST (por sus siglas en inglés) para la redacción
de historias a fin de elaborar mejores historias de usuario.

INVEST, por sus siglas en inglés, es un acrónimo que significa: independiente, negociable, valioso,
estimable, pequeño y comprobable.

 Independiente: cada historia del usuario ene ser independiente de las demás. Las
historias interdependientes pueden causar problemas durante la estimación y
priorización.

 Negociable: Una historia de usuario debe dar oportunidad a la conversación o

negociación con el cliente. Una tarjeta con la historia debe contener una breve
descripción sin demasiados detalles.
  Valiosa: Cada historia debe ser valiosa para el cliente. A fin de garantizar que cada
historia sea valiosa, el cliente debe estar involucrado en la redacción de la historia.

 Estimable: Los desarrolladores deben entender fácilmente las historias a fin de

estimarlas; de esta forma no tendrán dificultad al momento de priorizar y planear.

 Pequeña: Una historia bien escrita debe ser pequeña en esfuerzo (no más de tres
semanas de esfuerzo humano). En caso de que se necesite más tiempo, hay una alta
posibilidad de errores de cálculo y alcance.

 Comprobable: A fin de confirmar que la historia está terminada, debe ponerse a

prueba. Cualquier cosa que no se pueda examinar, no puede ser desarrollada;
debido a que no puede ser comprobada, no se puede confirmar como terminada.
Por ejemplo, una historia que indique: “Como usuario, quiero hacer mi trabajo con
facilidad, por lo tanto, esta característica no debe ser muy complicada”, no se puede
poner a prueba.

Una historia de usuario incluye tres elementos sobre el requerimiento: ¿Quién? ¿Qué? Y ¿Por qué?
Los requerimientos expresados en las historias de usuario son oraciones breves, sencillas y fáciles de
entender.

Junto con las historias de usuario, el equipo principal de Scrum escribe los criterios de aceptación.
Las historias de usuario son por lo general subjetivas de tal forma que los criterios de aceptación
brindan la objetividad requerida para que las historias de usuario se consideren terminadas o no
terminadas durante la revisión del sprint.

Los criterios de aceptación brindan claridad al equipo respecto a los que se espera en una historia de
usuario; eliminan la ambigüedad de los requerimientos, ayudando a la alineación de las expectativas.
El Product Owner define y comunica los ________________________ al Equipo Scrum.
Proceso 2: Estimar historias de usuario

Después de crear las historias de usuario, deben ser estimadas por el Equipo Scrum.

Calcular con exactitud los plazos y requerimientos de mano de obra es un aspecto crítico para que
una empresa pueda garantizar una gran experiencia de entrega del proyecto para el cliente. Sin
embargo, las estimaciones, por su definición, no son ______________, pues varían con la
complejidad del proyecto, el tamaño del equipo y su disponibilidad, prioridad, volatilidad de los
requerimientos, etcétera. Scrum busca garantizar una mejor estimación utilizando actividades de
estimación en equipo, así como métodos de comparación.

Tamaño relativo/Puntos de historia (Relative Sizing/Story Points)

Se pueden utilizar puntos para estimar el tamaño general de una historia de usuario o característica.
Este método asigna un valor de punto de historia con base en una evaluación general del tamaño de
una historia de usuario tomando en cuenta el riego, la cantidad de esfuerzo necesario y el nivel de
complejidad. Esta evaluación la llevará a cabo el Equipo Scrum y se asignará un valor de punto de
historia. Una vez hecha la evaluación en una historia de usuario en el Backlog Priorizado de Producto,
el Equipo Scrum puede entonces evaluar otras historias de usuario relativas a esa primera historia.

Por ejemplo, una característica con un valor de historia de 2 puntos sería doblemente difícil
completar que una característica con una historia de 1 punto; una historia de 3 puntos sería tres
veces más difícil de completar que una de 1 punto.

Se pueden utilizar numerosos métodos de estimación para estimar historias de usuario. Algunas
herramientas importantes son:

1. Wideband Delphi

El Wideband Delphi es una técnica de estimación basada en grupo para determinar la

cantidad de trabajo necesario y el tiempo que tardará en completarse. Los individuos en el
equipo proporcionan estimaciones anónimas para cada artículo y las estimaciones iniciales
se trazan en una gráfica. Posteriormente, el equipo analiza los factores que influyeron en
sus estimaciones y proceden a una segunda ronda de estimación. Este proceso se repite
hasta que las estimaciones de los individuos quedan cerca una de la otra y se puede llegar a
un consenso para la estimación final.

2. Planning Poker

El planning Poker, conocido también como Estimación Poker, es un derivado de la técnica

Wideband Delphi. Esta técnica de estimación implementa el consenso para estimar los
tamaños relativos de las historias de usuario o el trabajo necesario para desarrollarlos.

En el planning Poker, a cada miembro del equipo se le asigna una baraja. Cada carta está
enumerada en forma secuencial y los números representan la complejidad del problema en
términos de tiempo o esfuerzo, según lo estimado por el miembro del equipo. Los miembros
del Equipo Scrum evalúan el artículo (tarea o historia de usuario) e intentan entenderlo
mejor antes de brindar su estimación para su desarrollo. Después, cada miembro elige una
carta de la baraja que represente su estimación para la historia de usuario. Si la mayoría, o
todos los miembros del equipo seleccionan la misma carta, entonces el cálculo que indique
 la carta será el estimado para el artículo. Si no hay un consenso, entonces los integrantes
del equipo discuten las razones de la selección de distintas caratas o estimaciones. Después
del análisis seleccionan nuevamente las cartas. Esta secuencia continúa hasta que se
entienden todas las presuposiciones; hasta que se resuelven los malentendidos o hasta que
se llega a un consenso o a un acuerdo.

El Planning Poker promueve una mayor interacción y una mejor comunicación entre los
participantes. Facilita el pensamiento independiente por parte de los participantes, evitando
con ello el fenómeno del pensamiento en grupo.

3. Puño de cinco (Fist of Five)

El puño de cinco, o Fist of Five, es un mecanismo sencillo y rápido que se puede utilizar como
práctica de estimación, así como técnica general de formación de consenso colectivo. Tras
el debate inicial sobre la estimación de un elemento, se les pide a los miembros del Equipo
Scrum que voten en una escala de 1 a 5 utilizando sus dedos. Al utilizarse como herramienta
de estimación, el número de dedos que se muestran indican el valor relativo de estimación.
Los integrantes del equipo con estimaciones atípicas (valores más altos o más bajos) explican
al grupo el motivo de su estimación para su análisis. Una vez que el equipo ha debatido, se
lleva a cabo otra ronda de Fist of Five o se toma una decisión colectiva.

El número de dedos utilizados para votar indica el nivel de acuerdo o deseo de discutir.

 Un dedo: No estoy de acuerdo con la conclusión del grupo y tengo grandes

inquietudes.

 Dos dedos: No estoy de acuerdo con la conclusión del grupo y me gustaría hablar
sobre algunos asuntos menores.

 Tres dedos: No estoy seguro y me gustaría sumarme a la conclusión de consenso del

grupo.

 Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y me gustaría discutir
algunos asuntos menores.

 Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo.

4. Estimación por afinidad (Affinity Estimation)

La estimación por afinidad (del inglés: Affinity Estimación) es una técnica que se utiliza para
estimar rápidamente un gran número de historias de usuarios con el uso de categorías.
Utilizando notas adhesivas o fichas y cinta, cada equipo coloca las historias de usuario en la
pared p en cualquier otra superficie en orden desde la más pequeña hasta la más grande.
Para ello, cada integrante del equipo inicia con un subconjunto de historias de usuario de
todo el Backlog Priorizado del Producto para colocarse por tamaño relativo. Esta colocación
inicial se hace en silencio. Una vez que todos han colocado en la pared sus historias de
usuario, el equipo las revisa y las puede mover según sea necesario.
 Esta segunda parte del ejercicio incluye discusiones. Por último, el Product Owner indicará
en la pared algunas categorías de tamaño. Dichas categorías pueden ser pequeñas,
medianas o grandes, o bien, pueden estar enumeradas utilizando valores de punto de la
historia (Point Story Values) para indicar el tamaño relativo. Después el equipo reubicará las
historias de usuario en dichas categorías en el paso final del proceso. Algunos de los
beneficios claves de este método son que el proceso es muy transparente, visible para todos
y fácil de llevar a cabo.

La principal salida de este proceso es Historias de usuario __________________.

Proceso 3: Comprometer historias de usuario

Después de la estimación, el Equipo Scrum se compromete a un subconjunto de historias de usuario

aprobadas y estimadas para el siguiente sprint. Esto se hace como parte de la reunión de la
planificación del sprint.

En las reuniones de planificación de tareas, el Equipo Scrum se reúne para planificar el trabajo que
se hará en el sprint. El equipo revisa las historias de usuario asignadas que encabezan el Backlog
Priorizado del Producto. El Product Owner se encuentra presente durante las reuniones en caso de
ser necesaria una aclaración relacionada a las historias de usuario o en las prioridades. Para ayudar
a garantizar que el equipo no se salga del tema, la reunión debe de tener un time-box con una
duración estándar limitada de dos horas por semana de duración del sprint. Esto ayuda a prevenir la
tendencia de desviarse hacia discusiones que deberían de realizarse en otras reuniones, tales como
en las de planificación del lanzamiento o en reuniones de revisión del sprint. Como parte de esta
reunión, todo el Equipo Scrum se comprometerá a entregar un subconjunto de historias de usuario
del Backlog Priorizado del Producto en el sprint.

Scrum promueve la comunicación precisa y eficaz primordialmente mediante la co-ubicación de

equipos Scrum. Scrum favorece también las interacciones informales cara a cara en de la
comunicación formal por escrito. Cuando un Equipo Scrum debe estar distribuido geográficamente,
el Scrum Master debe asegurar que existan técnicas eficaces de comunicación para que los equipos
se puedan auto organizar y trabajar eficientemente.

La principal salida de este proceso es Historias de usuario _____________. El Equipo Scrum se

compromete a su subconjunto de historias de usuario estimadas que consideran que se pueden
completar en el siguiente sprint con base en la velocidad. Las historias de usuario comprometidas se
seleccionarán siempre según las prioridades definidas por el Product Owner.
Proceso 4: Identificar tareas

Las historias de usuario son funcionales de alto nivel que deben desglosarse en tareas accionables a
implementar. Esto se hace como parte de la reunión de planificación del sprint después de haber
determinado las historias de usuario comprometidas. El equipo revisa cada historia de usuario
comprometida para el sprint e identifica actividades accionables o las tareas necesarias para
implementar los entregables necesarios para cumplir totalmente y cumplir los criterios de
aceptación de usuario.

El Product Owner se encuentra presente durante esta reunión en caso de que se necesita una
aclaración relacionada a las historias de usuario comprometidas a fin de ayudar al equipo a tomar
decisiones sobre diseño.

La principal salida de este proceso es la _______________. Es una lista integral que contiene todas
las tareas a las que se ha comprometido el Equipo Scrum en el actual sprint.

La lista de tareas, o Task list, debe incluir cualquier prueba o actividad de integración a fin de que el
incremento del producto del sprint puede integrarse con éxito en los entregables de previos sprints.
Aun cuando las tareas generalmente se basan en tareas, el nivel de granularidad al que se segmentan
las tareas lo decide el Equipo Scrum.
Proceso 5: Estimar tareas

Una vez que la lista de tareas está lista, el Equipo de Scrum hace las estimaciones necesarias. Es de
suma importancia que los equipos Scrum hagan las estimaciones sobre el esfuerzo necesario para
concluir las tareas a fin de planificar el curso de acción. Las estimaciones se realizan en términos de
duración y el esfuerzo necesario para convertir las tareas en entregables. El término “esfuerzo”
describe tanto a la mano de obra, como los demás recursos necesarios para concluir las tareas de un
determinado sprint.

El Equipo Scrum estima los riesgos en la reunión de planificación del sprint.

A fin de estimar tareas, el Equipo Scrum puede utilizar una variedad de técnicas de estimación. Es
importante que el Equipo Scrum llegue a un conceso sobre los criterios de estimación. El principal
objetivo del uso de criterios de estimación relativos y minimizar la necesidad de re-estimación.

Los criterios de estimación pueden expresarse de muchas formas. Dos ejemplos comunes son los
___________________ y el ______________________- Los valores de puntos de historia se utilizan
para representar el esfuerzo relativo o comparativo para completar tareas.
Proceso 6: Crear el Sprint Backlog

Este es el último proceso en la fase de Planificación y estimación. El sprint Backlog se elabora durante
l reunión de planificación del sprint. Una vez que está disponible la Effort Estimated Task List (lista
de tareas del esfuerzo estimado), el equipo principal de Scrum toma los elementos en la lista de
tareas para su discusión a detalle. Cada miembro del equipo selecciona las tareas que planea realizar
durante el sprint. Debido a que el Equipo Scrum es auto organizado, son los miembros del equipo
quienes toman la decisión de quién realizará ciertas labores. Ni el Product Owner, ni el Scrum Master
dirigen al equipo sobre los elementos en los que se debe trabajar ni en cómo realizar el trabajo. El
Product Owner es un puente entre el equipo Scrum y los stakeholders, mientras que el Scrum Master
es el jefe facilitador y mentor del Equipo Scrum.

Es importante dar seguimiento al progreso de un sprint y ver en qué lugar se encuentra el Equipo
Scrum en cuestión del avance de las tareas en el Sprint Backlog. Una de las herramientas más
comunes para dar seguimiento es el Scrumboard, conocido también como tablero de tareas o
gráficas de progreso.

El Scrumboard estándar tiene cuatro columnas para indicar el progreso de las tareas estimadas para
el sprint: una columna “por hacer” para las tareas que aún no se inician; una columna “en progreso”
para las tareas que ya iniciaron, pero o se han concluido; una columna “en prueba” para las tareas
concluidas pero que están en proceso de evaluación y una columna de “terminado” para las tareas
que se han concluido y evaluado satisfactoriamente.

Se puede agregar una quinta columna opcional para las “historias”. Al inicio de un sprint, todas las
tareas se colocan en la columna de “por hacer” y se transfieren subsecuentemente hacia adelante
según su progreso.

La siguiente figura muestra un ejemplo de un Scrumboard:

Las principales salidas de este proceso son el Sprint Backlog y Sprint Burndown Chart.

1. Sprint Backlog: la lista de tareas llevará a cabo el Equipo Scrum en el siguiente sprint se
denomina Sprint Backlog esté representado en un Scrumboard o tablero de tareas, el cual
proporciona una constante representación visual del estado de las historias de usuario en el
Backlog. En el Sprint Backlog también se incluye cualquier riesgo asociado a las varias tareas.
Cualquier actividad de mitigación de riesgos para atender los riesgos identificados también
se incluirán como tareas en el Sprint Backlog. Una vez que el Equipo Scrum finaliza y se
compromete al Sprint Backlog no se deben agregar nuevas historias de usuario; sin embargo,
las tareas que pudieron haberse pasado por alto o ignoradas de las historias de usuario
comprometidas pudieran ser agregadas. Si durante un sprint surgen nuevos requerimientos,
estos serán agregados al Backlog Priorizado del Producto e incluidos en un futuro sprint.

2. Sprint Burndown Chart: el Sprint Burndown es una gráfica que muestra la cantidad de
trabajo pendiente en el actual sprint. El Sprint Burndown Chart inicial se acompaña de un
Planned Burndown. El Sprint Burndown Chart debe actualizarse al final de cada día conforme
se concluye el trabajo. Dicha gráfica muestra el progreso que ha realizado el Equipo Scrum
y permite también la detección de estimaciones que pudieron haberse hecho
incorrectamente. Si el Sprint Burndown Chart muestra que el Equipo Scrum no va por el
rumbo correcto en la conclusión a tiempo del sprint, el Scrum Master debe identificar
cualquier obstáculo o impedimento de una conclusión satisfactoria e intentar eliminarlos.

3. La siguiente figura muestra un ejemplo de un Sprint Burndown Chart

 Muestra la cantidad de trabajo estimado pendiente (en el eje vertical) sobre el tiempo (en
el eje horizontal).

 La línea punteada en la gráfica indica una tendencia ideal, y la línea sólida muestra la
tendencia real. La región por encima de la línea punteada es la zona de peligro que indica
un retraso en la conclusión de la tarea. La región debajo de la línea punteada indica que el
equipo pudo haber sobreestimado el esfuerzo necesario y quizá tenga capacidad sobrante
en el sprint.
  El Sprint Burndown Chart es un buen indicador de la ______________ del equipo en el sprint
activo y permite hacer una proyección para ver s el equipo podrá completar todas las
historias de usuario comprometidas.

 de implementación
Fase

La fase de implementación está relacionada a la ejecución de las tareas y actividades para crear el
producto de un proyecto. Tales actividades incluyen la creación de varios entregables, la realización
de Daily Standups y el refinamiento (revisiones, ajustes y actualizaciones periódicas) del Backlog
Priorizado del Producto en intervalos frecuentes.

Proceso 1: Crear entregables

El desarrollo principal se lleva a cabo en el proceso de Crear entregables. El Equipo Scrum es

responsable de la creación de los entregables del sprint, mientras que el Product Owner y el Scrum
Master juegan un papel importante en el proceso de su creación.

 El Product Owner actúa como puente entre el Equipo Scrum y los stakeholders,
proporcionando a los miembros del Equipo Scrum el aporte necesario y la información que
necesitan mientras desarrollan los entregables del sprint.

 El Scrum Master es responsable de garantizar que exista para el equipo un ambiente de

trabajo conductivo en el desarrollo de los entregables.

El principal esfuerzo de desarrollo recae sobre el Equipo de Scrum, y debido a que es un equipo
interfuncional y auto organizado, los miembros del equipo deciden cómo desarrollar ciertas tareas.
Ni los stakeholders ni el Scrum Master o el Product Owner pueden dirigir al equipo en la forma de
desarrollar los entregables. Los miembros del Equipo Scrum son expertos en sus áreas, y su juicio y
experiencia se aplican a todos los aspectos técnicos y de gestión de un proyecto durante este
proceso.

La principal salida de este proceso son los entregables del sprint, conocidos también como
_______________________________ que deben contar con todas las características y
funcionalidades definidas en las historias de usuario para el sprint. Si los miembros del Equipo Scrum
enfrentan algún obstáculo durante el proceso de conclusión de los entregables del Sprint, deben
anotarlos en el registro de impedimentos (Impediment Log). El Scrum Master deben actualizar dicha
lista y es su responsabilidad resolver problemas y eliminar impedimentos.

Una vez que el sprint inicia en la fase de implementación, el alcance del sprint no debe ser
modificado. ¿Qué haría si el Product Owner quiere hacer cambios a mitad de un sprint? Si los cambios
que se requieren son de tal importancia debido a que, sin estos, los resultados del sprint resultarían
inútiles, entonces el sprint debe terminarse y empezar uno nuevo donde se incorporen los cambios.
De lo contrario, el cambio se traslada a un futuro sprint.

M..NÑÑÑ
Proceso 2: Realizar el Daily Standup

La colaboración se fomenta entre los miembros del Equipo Scrum y entre el quipo principal de Scrum
y entre los stakeholders mediante las reuniones llamadas Daily Standup. Daily Standup una reunión
breve que generalmente se limita a _____ minutos. En esta breve reunión, los miembros del Equipo
Scrum comunican al resto del equipo su actual situación de trabajo y sus planes para las próximas 2
horas. Esto se lleva a cabo mediante la revisión del trabajo terminado desde el último Daily Standup
y mediante el pronóstico del trabajo que se puede realizar antes de la siguiente.

La reunión es muy breve y se espera que estén presentes todos los miembros del Equipo Scrum. Sin
embargo, la reunión no se cancela o se retrasa si uno o más miembros no pueden asistir. En la
reunión, cada miembro del equipo Scrum proporciona respuesta a tres preguntas diarias:

 ¿Qué he hecho desde la última reunión?

 ¿Qué tengo planeado hacer antes de la siguiente reunión?

 ¿Qué impedimentos u obstáculos (si los hubiera) estoy enfrentando en la actualidad?

Además de fomentar la colaboración, el Daily StandUp también promueve la transparencia entre los
momentos del equipo principal de Scrum. El Scrum Master ayuda a los miembros del equipo a
resolver problemas o impedimentos y es únicamente un facilitador y no está a cargo de presidir la
reunión. El Daily StandUp es únicamente un foro para el intercambio de información. Cualquier
plática o resolución de problemas, en caso de ser necesaria, se presenta después de la reunión. El
Scrum Master simplemente recopila información sobre los impedimentos que enfrenta el Equipo
Scrum en la conclusión satisfactoria de los entregables del Sprint y resuelve dichos impedimentos
después de la reunión.

El Sprint Burndown Chart actualizado y el Impediment Log actualizado son las ____________ salidas
de este proceso.
Proceso 3: Refinar el Backlog Priorizado del Producto

El tercer proceso en la fase de Implementación es el proceso de Refinar el Backlog Priorizado del

Producto. Para garantizar que los elementos en el Backlog Priorizado del Producto sean refinados,
se recomienda que se utilice del 7 al 10% de cada sprint para refinar el Backlog.

El Product Owner es responsable de refinar el Backlog Priorizado del Producto, que incluye agregar
o cambiar elementos de dicho Backlog para cumplir con los requerimientos modificados y
proporcionar historias de usuario más detalladas para el siguiente sprint.

El refinamiento garantiza que el Backlog Priorizado del Producto sea refinado mucho antes del
siguiente sprint a fin de que el Equipo Scrum cuente con una serie de historias bien analizadas y
claramente definidas que se puedan fácilmente fragmentar en tareas y subsecuentemente
estimarlas. El refinamiento permite que el desarrollo sea más flexible mediante la incorporación de
los más recientes requerimientos técnicos y empresariales en el siguiente sprint. El Backlog
Priorizado del Producto se vuelve a priorizar con base en las opiniones del cliente, los cambios
externos en el mercado y en el conocimiento obtenido del actual y previos sprints.

Scrum no asigna un tome-box en los ejercicios de refinamiento. El refinamiento del Backlog

Priorizado del Producto es una tarea constante del Product Owner.

Debido a que el Product Owner es responsable del refinamiento del Backlog Priorizado del Producto,
debe realizar múltiples reuniones con los stakeholders correspondientes, con el Scrum Master y con
el Equipo Scrum a fin de recopilar información y requerimientos.

Debido a que el Producto Owner es responsable del refinamiento del Backlog Priorizado del Product,
debe realizar múltiples reuniones con los stakeholders correspondientes, con el Scrum Master y con
el Equipo Scrum a fin de recopilar información y requerimientos.

Las herramientas que se utilizan para refinar (groom) el Backlog Priorizado del Product son las
siguientes:

1. Reuniones de revisión del Backlog Priorizado del Producto: El Product Owner puede tener
varias reuniones por separado con los stakeholders relevantes, con el Scrum Master y con
el Equipo Scrum a fin de asegurarse de contar de contar con la información suficiente para
actualizar el Backlog Priorizado del Producto en el proceso de su refinamiento.

La intención de las reuniones de revisión del Backlog Priorizado del Producto es asegurarse
de que se entiendan las historias de usuario y los criterios de Aceptación y de que el Product
Owner la escriba adecuadamente reflejando los requerimientos y prioridades actuales del
stakeholder (cliente); que todos en el Equipo Scrum entienda las historias de usuario y que
las historias de usuario de mayor prioridad sean bien refinadas de tal forma que el Equipo
Scrum las pueda estimar adecuadamente y avocarse a ellas.

Las reuniones de revisión del Backlog Priorizado del Producto garantizan también que se
eliminen historias de usuario irrelevantes y que se incorporen las solicitudes de cambio
aprobadas o los riesgos identificados en el Backlog Priorizado del Producto.

2. Técnicas de comunicación: Scrum promueve la comunicación precisa y eficaz

primordialmente mediante la co-ubicación de equipos Scrum. Scrum favorece también las
interacciones informales cara a cara en vez de la comunicación formal por escrito. Cuando
un equipo Scrum debe ser distribuido geográficamente, el Scrum Master debe asegurar que
 existan técnicas eficaces de comunicación para que los equipos se puedan auto organizar y
trabajar eficientemente.

La principal salida del proceso de Refinar el Backlog Priorizado del Producto es el Backlog
Priorizado de Producto actualizado; El Backlog Priorizado del Producto se puede actualizar con
nuevas historias de usuario; nuevas solicitudes de cambio, nuevos riesgos identificados o
historias de usuario actualizadas o bien, la re priorización de las historias de usuario ya
existentes.

Fases de revisión y retrospectiva

La fase de revisión y retrospectiva aborda la revisión de los entregables y del trabajo que se ha
realizado y determina las formas para mejorar las prácticas y métodos implementados para realizar
el trabajo del proyecto.

Proceso 1: Demostrar y validar el sprint

En este proceso, el Equipo Scrum presenta o demuestra los entregables del sprint al Product Owner
quien valida y decide si cumplen los requerimientos de los criterios de aceptación. Esto se hace como
parte de la reunión de revisión del sprint al final de cada sprint. Esto ofrece una oportunidad para
que le Product Owner y los stakeholders inspeccionen lo que se ha completado hasta el momento y
determinen si deben hacerse cambios al proyecto o a los procesos en subsecuentes sprints.

El resultado de la reunión de revisión del sprint es la ___________ o __________ de los elementos

del Backlog por parte del Product Owner. Los artículos rechazados permanecen en el Backlog
Priorizado del Producto.

Es responsabilidad del Scrum Master asegurar que el Product Owner no cambie los requerimientos
o criterios de aceptación durante el sprint y que rechace los elementos terminados del Backlog por
no cumplir con los requerimientos modificados. Si estos han cambiado, se debe crear una nueva
tarea para abordar los cambios en otro sprint.

Únicamente se pueden presentar las funcionalidades del producto que se apegan a la definición de
terminado y las funcionalidades del trabajo en progreso se incluyen en un futuro sprint. Los
miembros del equipo presentan el trabajo terminado durante el sprint, responden a las preguntas
del stakeholder y toman nota de los cambios sugeridos.
Proceso 2: Retrospectiva del sprint

Después de la reunión de revisión del sprint, el Equipo Scrum lleva a cabo una reunión de
retrospectiva del sprint. Es una oportunidad para que el equipo analice y examine el sprint anterior
a fin de identificar posibles mejoras en el proceso. Estas reuniones pueden resultar no solo en un
simple acuerdo entre los integrantes del equipo a fin de hacer las cosas diferentes en lo sucesivo,
sino en la definición de __________________ para el Backlog Priorizado del Producto.

A la reunión de retrospectiva del sprint asisten el Scrum Master y los miembros del Equipo Scrum. El
Product Owner puede asistir, pero no es obligatorio. Los miembros del equipo presentan cualquier
problema que hayan enfrentado durante el sprint anterior y cómo pueden abordarlos. Los miembros
del equipo discuten lo que salió bien y lo que salió mal durante el sprint anterior. El equipo define
también posibles mejoras y sugiere mejoramientos a la definición de mejorado basado en su
experiencia.

Para una reunión de retrospectiva eficiente, el evento se puede dividir en cinco etapas:

 Preparación el caso: El equipo de la bienvenida, conoce el propósito de la reunión y mide el

estado de ánimo generalizado de los participantes.

 Recopilación de información: El equipo comparte datos e información sobre el sprint

anterior y analiza las fortalezas y habilidades. El escenario permite presentar las situaciones
más importantes que sucedieron en el sprint.

 Generación de información: este paso se enfoca en la pregunta: “¿Por qué?” (Por qué
algunas cosas funcionaron bien y por qué otras necesitan cambiar). Esto ayuda a los
participantes a obtener una perspectiva y llegar a la raíz de los problemas.

 Acción: el equipo define las acciones para mejorar y prevenir o reducir errores.

 Círculo de preguntas y clausura: cada miembro del equipo tiene la oportunidad de hacer
preguntas o presentar cualquier duda. E esta etapa se dejan en claro los elementos de acción
para el siguiente sprint. Por último, el equipo agradece a los demás y clausura la sesión.

La principal salida del proceso de Retrospectiva del sprint son los: Agreed Actionable Improvements.
Es una lista de actionable ítems (elementos accionables) que ha elaborado el equipo para hacer
frente a los problemas y mejorar los procesos a fin de mejorar también su desempeño en futuros
sprints.
 Fase de lanzamiento

La fase de lanzamiento hace énfasis en la entrega al cliente de los entregables aceptados, así como
en la identificación, documentación e internalización de las elecciones aprendidas durante el
proyecto.

Proceso 1: Enviar entregables

Después de que el Product Owner valida los ___________ del sprint según los criterios definidos de
aceptación y terminado, los entregables aceptados quedan listos para su lanzamiento a los
stakeholders. Sin embargo, no todos los sprints concluyen con el lanzamiento. La fecha de
lanzamiento del incremento de un producto potencialmente enviable se realiza durante el proceso
de Realizar la planificación del lanzamiento.

El Cronograma de planificación del lanzamiento (Release Planning Schedule) documenta cuándo y

cuáles entregables serán lanzados. Por lo tanto, en el proceso de Enviar entregables, las principales
entradas en este proceso son los entregables aceptados y el Cronograma de planificación del
lanzamiento.

Los entregables se envían utilizando métodos de desplazamiento organizacional. Cada organización

tiene sus propios métodos de despliegue. Dichos métodos guían la forma de cómo y cuánto se
habrán de enviar los entregables a los stakeholders. Las principales salidas de este proceso son los
entregables funcionales, el acuerdo de entregables funcionales y los lanzamientos de producto.
Proceso 2: Retrospectiva del proyecto

El último proceso en el flujo de Scrum es la Retrospectiva del proyecto, la cual resulta análoga al
proceso de Retrospectiva del sprint, pero a un nivel de proyecto. Una vez que todos los incrementos
del producto han sido satisfactoriamente enviados a los stakeholders, el equipo principal de Scrum
o los equipos se reúnen para revisar, analizar e identificar lo que salió bien y mal durante el ciclo de
vida del actual proyecto.

La reunión de retrospectiva del proyecto se lleva a cabo buscando identificar las _______________,
mejorar accionables aceptadas y recomendaciones para el Scrum Guidance Body. Esto no solamente
ayuda a mejorar la colaboración y eficiencia del equipo, sino que define también las mejoras a la
implementación general de Scrum. Las sugerencias, opiniones y conocimientos recopilados en la
reunión de retrospectiva del proyecto se registran para poder usarlas como material de consulta en
un futuro.
Cuestionario del capítulo

1. La serie priorizada de trabajo a realizarse es capturada por el Product Owner en:

A. Una historia de usuario
B. El Backlog Priorizado del Producto
C. Un Burndown Chart
D. Los entregables aceptados

2. ¿Cuáles de las siguientes opciones define mejor una historia del usuario?
A. Declaración que describe la visión del producto
B. Documento que describe la prioridad de las tareas que deben completarse en el
proyecto
C. Declaración que expresa la funcionalidad deseada del usuario final
D. Historia que proporciona información en tareas similares que deben ser
completadas en proyectos de implementación de Scrum previos.

3. ¿Cómo se organizan los elementos del Backlog Priorizado del Producto?

A. Los elementos más pequeños se colocan al principio
B. Los elementos con las menores interdependencias van al principio
C. Los elementos más complejos se colocan al principio
D. Los elementos con el mayor valor empresarial al principio

4. ¿Quién es responsable de elaborar las historias de usuario en el proceso de Desarrollar

historias de usuario?
A. Scrum Master
B. Product Owner
C. Equipo Scrum
D. Stakeholders

5. ¿Sobre quién recae la responsabilidad de estimar los elementos del Backlog Priorizado del
Producto en la fase de Planificación y estimación?
A. Equipo Scrum
B. Scrum Master
C. Product Owner
D. Un equipo externo con experiencia considerable

6. ¿Cuál de las siguientes NO es una entrada del proceso de Enviar entregables?

A. Entregables aceptados
B. Cronograma de planificación del lanzamiento
C. Product Owner
D. Impediment Log
7. ¿Con qué frecuencia se cambian las prioridades del Backlog Priorizado del Product?
A. Nunca
B. Cuando el Product Owner decida que un elemento debe tener una mayor prioridad
C. Cuando el Scrum Master considere que se debe agregar un elemento
D. Cuando la alta gerencia considera que se debe agregar un elemento

8. ¿Cuál de las siguientes herramientas utiliza el Equipo Scrum para estimar tareas en el
proceso de Estimar tareas?
A. Experiencia en la redacción de historias de usuario
B. Wideband Delphi
C. Comparación por pares
D. Sesiones JAD

9. ¿Cuáles de los siguientes enunciados NO es verdadero?

A. La velocidad del equipo es una medida de la cantidad de trabajo que un equipo
puede completar en un sprint.
B. La velocidad histórica del equipo se utiliza como indicador al asignar tareas para
cada sprint
C. La velocidad del equipo es independiente de la composición del equipo.
D. La velocidad del equipo se utiliza para decidir sobre los plazos de lanzamiento

10. ¿Qué es lo que NO se discute en un Daily Standup?

A. Lo que el miembro del equipo ha logrado desde la última reunión
B. Lo que el miembro del equipo planea hacer en tanto se lleve a cabo la próxima
reunión
C. Lo que el miembro del equipo ha aprendido a partir de su trabajo
D. Los obstáculos que enfrenta el miembro del equipo

11. ¿Cuánto dura un típico Daily Standup?

A. 5 minutos
B. 1 hora
C. 15 minutos
D. Los Daily Standups no tienen time-box

12. ¿De quién es la responsabilidad de garantizar que los Daily Standup se realicen en forma
oportunidad y estructurada?
A. Scrum Master
B. Product Owner
C. Líder del equipo Scrum
D. Responsabilidad colectiva del grupo
13. ¿Para qué utilizan el Sprint Burndown Chart los equipos?
A. Para medir el trabajo completado durante el proyecto
B. Para medir el trabajo restante que debe ser completado durante un sprint
C. Para calcular la cantidad del presupuesto restante del equipo
D. Para identificar el bajo desempeño de los miembros del equipo

14. ¿Cómo se le conoce a la reunión donde equipo analiza las tareas a completarse en el
siguiente sprint?
A. Reunión de visión del proyecto
B. Reunión de planificación del sprint
C. Reunión de revisión del sprint
D. Reunión de retrospectiva del sprint

15. ¿Cómo se le conoce a la reunión al final del sprint donde el equipo presenta su trabajo al
Product Owner?
A. Reunión de visión del proyecto
B. Reunión de planificación del sprint
C. Reunión de revisión del sprint
D. Reunión de retrospectiva del sprint

16. ¿Cómo se le llama a la reunión donde el equipo analiza los sprints anteriores e identifica
procesos potenciales de mejoramientos?
A. Reunión de visión del proyecto
B. Reunión de planificación del sprint
C. Reunión de revisión del sprint
D. Reunión de retrospectiva del sprint

17. Durante una reunión de revisión del sprint, __________________________.

A. El equipo presenta entre sí el producto final
B. El Scrum Master puede aceptar o rechazar el producto final entregable
C. El equipo presenta el proyecto final entregable al Product Owner
D. Cada miembro del equipo puede aceptar o rechazar el producto final entregable.
18. ¿Cuál actividad NO es parte de la reunión de retrospectiva del sprint?
A. El equipo analiza lo positivo y lo negativo de los sprints anteriores
B. El equipo identifica los problemas que se enfrentaron en sprint previo y discuten la
forma de mitigar ichos problemas en sprints futuros.
C. El equipo revisa e identifica mejoras potenciales a sus funcionales.
D. Basado en los cambios sugeridos, el equipo procede a dar nuevas prioridades al
Backlog Priorizado del Producto.

19. ¿Cuáles son las ventajas del proceso Refinar el Backlog Priorizado del Producto?
A. En conocimiento obtenido de sprints anteriores se incorpora a futuros sprints.
B. Se agregan al siguiente sprint los últimos requerimientos técnicos y empresariales.
C. El refinamiento garantiza que el Backlog Priorizado del Producto sea refinado antes
de la reunión de planificación del sprint a fin de que el equipo cuento con una mejor
idea de los requerimientos previo a la reunión.
D. Todas las anteriores

20. ¿Quién tiene la responsabilidad de refinar el Backlog Priorizado del Producto?

A. Product Owner
B. Scrum Master
C. Equipo Scrum
D. Stakeholders externos

21. ¿Qué actividad se puede realizar en forma conjunta durante la reunión de planificación del
sprint?
A. Estimación de tareas y planificación del lanzamiento
B. Refinar el Product Backlogs y Planificar tareas
C. Planificación y estimación de tareas
D. Planificación de lanzamiento y refinamiento del Backlog Priorizado del Producto

22. ¿Cuál de las siguientes opciones NO forma parte de la reunión de planificación del sprint?
A. El Product Owner explica al equipo los elementos principales del Backlog Priorizado
del Producto
B. El Equipo Scrum, consultando con el Product Owner, estima las tareas para un sprint
determinado.
C. Basándose en estimaciones, el equipo se compromete a completar algunas tareas
en el próximo sprint.
D. El equipo obtiene la retroalimentación de los stakeholders.
23. Usted es miembro de un equipo Scrum y el gerente general de su empresa le pide que
trabaje en una tarea urgente que no forma parte del actual sprint. ¿Qué haría usted?
A. Asumir la responsabilidad de la tarea y decirle al Product Owner que posponga la
fecha límite del actual sprint.
B. Hablar con los demás miembros del Equipo Scrum y reasignar tus tareas a alguien
más.
C. Hablar con el Product Owner y decirle que reasigne sus tareas a alguien más.
D. Informar la situación al Scrum Master y que él/ella discuta la situación con el
gerente general.
E. No hacer nada porque ya está muy ocupado.

24. ¿Cuándo se pueden agregar nuevas historias de usuario en un sprint en curso?

A. Cuando el Scrum Master agrega las historias de usuario al Sprint Backlog
B. Cuando el Product Owner aprueba la historia de usuario
C. Cuando el Equipo Scrum aprueba la historia de usuario
D. Nunca se pueden agregar nuevas historias de usuario al sprint

25. Los criterios de aceptación

A. Aumentan la ambigüedad sobre los requerimientos
B. Ayudan al equipo a apegarse a las normas de calidad sobre la funcionalidad
C. Son determinados por el Scrum Master consultando con los miembros del equipo
D. Son determinados por el Scrum Master consultando con el Product Owner.

26. ¿En cuál proceso en la fase de inicio se determina la duración del sprint?
A. Crear la visión del proyecto
B. Desarrollar épica(s)
C. Crear el Backlog Priorizado del Producto
D. Realizar la planificación del lanzamiento
 ESCALAMIENTO DE SCRUM

Escalamiento de Scrum en grandes proyectos

Para ser eficaces, los equipos Scrum deben tener idealmente de seis a diez miembros. Esta
práctica resulta en la idea errónea de que el framework de Scrum sólo se puede utilizar para
proyectos pequeños. Sin embargo, este marco se puede aumentar fácilmente para utilizarse de
manera eficaz en grandes proyectos. En situaciones donde el tamaño del Equipo Scrum excede
las diez personas, se pueden formar diversos equipos Scrum para trabajar en el proyecto.

Con frecuencia, los proyectos grandes o complejos se implementan como parte de un programa
o portafolio. El framework de Scrum también puede aplicarse para gestionar programas y
portafolios. El enfoque lógico de las directrices y los principios de este marco pueden utilizarse
para gestionar proyectos en cualquier tamaño, que abarcan grandes geografías y
organizaciones. Los grandes proyectos pueden tener múltiples equipos Scrum trabajando de
forma paralela, por lo que es necesario sincronizarse y facilitar el flujo de información y mejorar
la comunicación.

Al gestionar grandes proyectos que generalmente cuentan con cuatro o más equipos Scrum,
además de los procesos definidos en los capítulos del 8 al 12, tal vez sean necesarios algunos
procesos adicionales para abordar la coordinación adicional y los esfuerzos de sincronización. La
definición de “grandes proyectos” dependerá de la empresa y de la complejidad del proyecto
emprendido. La principal regla de un proyecto grande en comparación a uno pequeño es contar
con varios Scrum Masters y/o Product Owners. Los procesos adicionales relacionados al
escalamiento de Scrum en grandes proyectos son los siguientes:

 Crear componentes de grandes proyectos

 Realizar y coordinar sprints
 Preparar el lanzamiento de grandes proyectos

Escalamiento de Scrum para la empresa

El SBOK define los siguientes cinco procesos adicionales necesarios para escalar Scrum en las
empresas:

 Crear componentes de programa o portafolio

 Revisare y actualizar el Scrum Guidance Body
 Crear y refinar el Backlog del programa o portafolio
 Coordinar los componentes del programa o portafolio
 Retrospectiva de lanzamientos del programa o portafolio
Proyectos

Los roles importantes para gestionar grandes proyectos de Scrum son:

1. Chief Product Owner: Coordina el trabajo de múltiples Product Owner. Con la ayuda el
Product Owner, el Chief Product Owner prepara y mantiene el Backlog general
priorizado del producto para los grandes proyectos, utilizándolo para coordinar el
trabajo mediante los Product Owners y Equipos Scrum.

2. Chief Scrum Master: asegura una adecuada colaboración entre los Equipos Scrum.
Coordina el trabajo de varios Equipos Scrum en un proyecto mediante la reunión de
Scrum de Scrums.

Programas

Los roles importantes para gestionar programas de Scrum son los siguientes:

Program Product Owner: Define los objetivos estratégicos y prioridades del programa

Program Scrum Master: Resuelve problemas, elimina impedimentos, y conoce las reuniones
del programa.

Estos roles son similares a los del Product Owner y del Scrum Master, a excepción de que
cumplen las necesidades de su programa o unidad empresarial en vez de los de un solo Equipo
Scrum.

Portafolios

De igual forma, los roles importantes para gestionar portafolios Scrum son los siguientes:
1. Portfolio Product Owner: Define los objetivos estratégicos y prioridades del portafolio.
2. Portfolio Scrum Master: Resuelve problemas, elimina impedimentos, facilita y conduce
reuniones del portafolio.
La siguiente figura muestra cómo funciona Scrum en la organización de proyectos, programas
y portafolios.

Trabajar con equipos de portafolio y programas

Al aplicar Scrum para gestionar proyectos en el contexto de un programa o un portafolio, se

recomienda enfáticamente el apego a los principios generales de Scrum que se presentan en
esta publicación. Sin embargo, se entiende que, a fin de adaptar el programa en su totalidad o
actividades relacionadas con el portafolio y las interdependencias, pueden ser necesarios
pequeños ajustes en el conjunto de herramientas, así como a la estructura organizacional. Si
existe Scrum Guidance Body, éste puede ser responsable de examinar la organización en
diferentes niveles a fin de entender y definir la aplicación adecuada de Scrum, y actuar como
facilitador de consulta para todos los que trabajan en un proyecto, programa o portafolio.

Los portafolios y los programas cuentan con equipos separados y con diferentes series de
objetivos. Los equipos de gestión de programas tienen por objetivo ofrecer capacidades y llevar
a cabo ciertas metas que contribuyan a objetivos específicos del programa. Por el contrario, el
equipo del portafolio tiene que equilibrar los objetivos de los distintos programas para alcanzar
los objetivos estratégicos de la organización en su totalidad.

El capítulo aborda a detalle lo relacionado a escalar Scrum para la empresa.

Gestionar la comunicación con equipos de portafolios y programas

Los problemas y los asuntos que se enfrentan al utilizar Scrum dentro de un programa o
portafolio implican principalmente la coordinación entre los numerosos equipos. Esto puede
conducir al fracaso si no se maneja con cuidado. Las herramientas que se utilizan para la
comunicación deben ampliarse para que coincidan con los requisitos de los varios equipos que
participan en un programa o portafolio. Cada Equipo Scrum debe atender no sólo la
comunicación interna, sino también la comunicación externa con otros equipos y los
stakeholders relevantes del programa o portafolio.
 Transición a Scrum

Dos métodos básicos de transición a Scrum son _______________ y de _______________. En el

método de arriba abajo, la comunicación se transmite ampliamente. Existe una iniciativa para
informar acerca del cambio a todas las personas involucradas. Esta comunicación puede ser la
fuente de resistencia al cambio. La otra posibilidad es cambiar gradualmente las cosas dentro
de la cultura organizacional. Después, la transición a Scrum será en forma gradual. Con una
introducción de arriba hacia abajo, pudieran surgir problemas en cuanto a la comunicación, En
uno de casos, por ejemplo, el jefe de ingeniería impuso Scrum en su organización sin la
aceptación del gerente de producción o de ventas. Esto llevó a grandes problemas con la función
del Product Owner, así como sus tareas tales como la creación del Backlog Priorizado del
Producto.

Otro aspecto de transición a considerarse es qué cantidad de la organización requiere de una

transición a los métodos de Scrum. Toda la organización puede hacer la transición al mismo
tiempo. Sin embargo, este método es más susceptible a los problemas que pudieran resultar al
interrumpirse las actividades que generan ganancias. Por lo tanto, típicamente es preferible
diferentes divisiones en una forma iterativa a fin de reducir riesgo y proporcionar las lecciones
aprendidas a futuras iteraciones.

Resistencia al cambio
Como en cualquier cambio, habrá resistencia durante la transición hacia Scrum. Los gerentes
intermedios por lo general temen a perder sus funciones o su autoridad. Tal vez no puedan
entender su nueva función o su forma de contribuir al éxito del equipo. Las personas que ya
están habituadas en la metodología antigua por lo general se resistirán también al cambio. Estas
personas pueden ser los ingenieros del sistema o demás posiciones similares que temen a
perder su puesto a consecuencia del cambio a Scrum.

Mapeo de los roles tradicionales a Scrum

En Scrum, el rol tradicional del Project Manager se divide en tres roles: ______________,
_______________ y ________________. El Product Owner es el rol exterior.

 El Product Owner se comunica con los stakeholders y establece las prioridades del
proyecto. El Scrum Master desempeña las tareas del Project Manager mediante la
eliminación de impedimentos.

 El Scrum Master, tal como el Project Manager, es responsable de garantizar el

seguimiento de los procesos de Scrum.

 Los miembros del equipo desempeñan también ciertas funciones tradicionales del
Project Manager, ya que administran sus propias funciones y su propio tiempo. Esto
permite al equipo obtener un sentido de propiedad de su propio éxito.
 Mantener la participación de los stakeholders

Un aspecto importante de Scrum es que requiere de un sólido apoyo de los stakeholders. Los
siguientes pasos se recomiendan para mantener su participación:

 Formar un acuerdo de trabajo entre todos los stakeholders y promover la colaboración

efectiva y participación.

 Evaluar constantemente los cambios en el proyecto que afectan a los stakeholders y

asegurar que los nuevos stakeholders estén involucrados apropiadamente.

 Comunicar el avance del equipo y el desarrollo de capacidades a fin de ayudar a los

stakeholders a tomar decisiones informadas estén involucrados apropiadamente.

 Gestionar con precisión las expectativas de los stakeholders en torno a los resultados
mínimos/más probables/ópticos de forma que los stakeholders tengan la seguridad que
tales resultados les ayudarán a cumplir los objeticos de su negocio.

Importancia del apoyo ejecutivo

Los ejecutivos son aquellas personas que ________________ el proyecto. Por lo tanto, para que
cualquier ´proyecto de Scrum sea exitoso, los ejecutivos deben respaldarlo. Para mantener el
apoyo ejecutivo, se debe hacer lo siguiente:

 Comunicarse regularmente con los ejecutivos

 Mantener a los ejecutivos alerta sobre los últimos avances.
 Informar a los ejecutivos sobre cualquier problema y posibles retrasos en la entrega del
proyecto a fin de minimizar el shock.

Es importante que los ejecutivos que financian el proyecto tengan claridad respecto a las
siguientes inquietudes:

 ¿Cuál es el beneficio de implementar el framework Scrum?

o ¿En qué forma genera beneficios y/o previene pérdidas para la organización
este cambio?
o ¿En qué forma es esencial ser adaptivo en el actual clima empresarial?

 ¿Cuáles son las fechas límites y costos de la transición?

o ¿Cuáles son las fechas esperadas de conclusión y los costos de la transición?
o ¿Cuáles son los posibles objetivos a cumplir en el camino?
o ¿Con qué frecuencia se van a reunir los ejecutivos respecto al progreso del
proyecto?
  ¿Cuáles son los riesgos que implica la transición?
o ¿Cuáles son los posibles obstáculos o riesgos en la implementación?
o ¿Cuáles son los costos adicionales y el tiempo que se requiere para mitigar cada
uno de estos riesgos?

Cuestionario del capítulo

1. ¿Cuál de las siguientes opciones NO es verdadera sobre la implementación de Scrum en

grandes proyectos?
A. Se requiere que múltiples equipos trabajen en sincronía.
B. Un Backlog Priorizado del Producto no es necesario para dar seguimiento al
progreso de todos los proyectos.
C. Un Chief Product Owner es necesario para, monitorear todos los proyectos.
D. Las tareas pudieran no ser interdependientes entre equipos.

2. ¿Cuál de los siguientes es parte del Scrum de Scrum?

A. Resumen de las tareas a completarse en el sprint
B. Si cualquiera de sus decisiones puede afectar a otros equipos
C. Discutir problemas que pudieran haber surgido para cualquier de los equipos
Scrum.
D. Resolver impedimentos que pudieran haber surgido.

3. ¿Cuál de los siguientes enunciados es FALSO sobre Scrum en grandes proyectos?

A. Los grandes equipos tienen Chief Scrum Master y Chief Product Owners para
monitorear el avance del proyecto.
B. El Chief Product Owner es responsable de la asignación de recursos.
C. El Chief Product Owner facilita el Scrum de Scrum.
D. El Chief Product Owner es responsable del éxito o el fracaso del proyecto.

4. ¿Cuál de las siguientes opciones es responsabilidad del Programa Product Owner?

A. Comunicar las metas y objetivos del sprint a los miembros del equipo del
proyecto Scrum.
B. Definir los objetivos estratégicos y prioridades del programa
C. Establecer los criterios mínimos de terminado para los equipos.
D. Resolver problemas, eliminar impedimentos y facilitar y conducir las reuniones
del programa.
MATERIAL DE REFERENCIA