Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SMC Cuaderno de Trabajo
SMC Cuaderno de Trabajo
com
INTRODUCCIÓN
Acerca de SCRUMstudy
SCRUMstudy es la entidad de certificación global para las certificaciones Scrum y Agile. Una
gran cantidad de información acerca de SCRUMstudy y sus programas de certificación y
membresía está disponible en SCRUMstudy.com. En la parte inferior se proporciona un
resumen de las certificaciones que otorga SCRUMstudy.
© 2016 SCRUMstudy.com 1
Membresía Básica - Gratuita
Esta membresía provee acceso a las principales páginas de información, foros de discusión general y
blogs limitados y recursos en línea. Los candidatos a la certificación deben tener por lo menos una
Membresía Básica para poder dar un examen de certificación de SCRUMstudy.
© 2016 SCRUMstudy.com 2
RESUMEN DE AGILE
El término agile (ágil) generalmente se refiere a ser capaz de moverse o responder rápidamente y
fácilmente. En cualquier tipo de disciplina de gestión, ser ágil es una cualidad, por lo tanto esto debe
ser una meta que se debe tratar de alcanzar. La gestión de Proyectos Agile especialmente, implica la
adaptabilidad durante la creación de un Producto, Servicio o cualquier otro Resultado.
Es importante entender que a pesar de que el desarrollo de los métodos ágiles es altamente adaptable,
de todos modos es necesario tener en cuenta la estabilidad en sus procesos de adaptación.
El permiso para copiar fue proporcionado por los autores mencionados mediante aviso en http://agilemanifesto.org/.
© 2016 SCRUMstudy.com 3
Las cuatro compensaciones de The Agile Manifesto se elaboran de la siguiente manera:
1. Individuos e interacciones sobre procesos y herramientas
2. Software funcionando sobre la documentación extensiva
3. Colaboración con el Cliente sobre la negociación contractual
4. Responder ante el cambio en vez de seguir un plan
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para que
como consecuencia procedan a ajustar y perfeccionar su comportamiento.
© 2016 SCRUMstudy.com 4
Métodos Agile
Una serie de metodologías ágiles se crearon y ganaron fuerza en la década de 1990 y principios del
2000. Si bien difieren en una variedad de aspectos, lo que tienen en común se deriva de su adhesión
a The Agile Manifesto.
Los siguientes métodos ágiles se discuten brevemente a continuación:
1. Lean Kanban
2. Extreme Programming (XP)
3. Crystal Methods
4. Dynamic Systems Development Methods (DSMD)
5. Feature Driven Development (FDD)
6. Test Driven Development (TDD)
7. Adaptive Software Development (ASD)
8. Agile Unified Process (AUP)
9. Domain-Driven Design (DDD)
Lean Kanban
El concepto de Lean optimiza el sistema de una organización para producir resultados valiosos sobre
la base de sus recursos, necesidades y alternativas, mientras reduce las pérdidas. Las pérdidas, por
ejemplo, podrían ser la construcción incorrecta de un Producto, el no saber aprender, o las prácticas
que impiden que el proceso fluya. Debido a que estos factores son de naturaleza dinámica, una
organización ágil evalúa la totalidad de su sistema y continuamente hace ajustes a sus procesos. El
fundamento de Lean es que la reducción de la duración de cada ciclo (es decir, una iteración) conduce
a un aumento de Productividad mediante la reducción de los retrasos, ayuda en la detección de errores
en una etapa temprana, y en consecuencia reduce la cantidad total de esfuerzo requerido para terminar
una tarea. Los principios de software Lean se han aplicado con éxito en el desarrollo de software.
Kanban significa literalmente un "cartel" o "cartelera” y enfatiza el uso de ayudas visuales para ayudar
y realizar un seguimiento de la producción. El concepto fue introducido por Taiichi Ohno, considerado
como el padre de los sistemas Toyota Proudction Systems (TPS).
Extreme Programming
Extreme Programming (XP), que se originó en Chrysler Corporation, ganó fuerza en la década de
1990. XP hace que sea posible mantener el costo de cambiar el software sin que éste aumente
radicalmente con el tiempo. Los atributos claves de XP incluyen el desarrollo gradual, horarios flexibles,
pruebas automatizadas de código, la comunicación verbal, el diseño en constante evolución,
Colaboración cercana y la vinculación de las unidades, de largo como de corto plazo, de todos los
involucrados.
Crystal Methods
Las metodologías de desarrollo de software Crystal fueron presentadas por Alistair Cockburn a
principios de 1990. Los métodos Crystal se centran en las personas, son ligeros y fáciles de adaptar.
Porque la gente es lo primordial, los procesos y las herramientas de desarrollo no son fijos sino que se
ajustan a las necesidades y características específicas del Proyecto.
Todos los métodos de Crystal tienen cuatro roles – patrocinador, diseñador principal, desarrolladores
y usuario experto. Los métodos Crystal recomiendan diversas estrategias y técnicas para lograr
agilidad. Un ciclo de proyectos Crystal consta de gráficos, ciclo de entrega y de recapitulación.
© 2016 SCRUMstudy.com 5
Dynamic Systems Development Methods (DSDM)
El marco Dynamic Systems Development Methods (DSDM) se publicó inicialmente en 1995 y es
administrado por el Consorcio DSDM. DSDM establece la calidad y el esfuerzo en términos de costo y
el tiempo desde el principio y ajusta los entregables del proyecto para cumplir con los criterios
establecidos, dando prioridad a las prestaciones en las siguientes categorías: lo que "deben tener",
"deberían tener", "podrían tener", y "no tendrán" (mediante la técnica Priorización MoSCoW). DSDM
es un método orientado al sistema con seis distintas fases de pre-proyecto; Viabilidad; Fundamentos;
Exploración e Ingeniería; Despliegue y Evaluación de Beneficios.
© 2016 SCRUMstudy.com 6
Scrum vs Gestión de Proyectos Tradicional
En la tabla se resumen muchas de las diferencias entre los modelos tradicionales de gestión de
proyectos y Scrum.
Gestión de Proyectos
Enfoque Scrum
Tradicional
© 2016 SCRUMstudy.com 7
Los proyectos Scrum se completan de manera iterativa entregando valor a lo largo del ciclo de vida del
proyecto. El beneficio del desarrollo iterativo es que permite la corrección a medida que todas las
personas involucradas obtengan una mejor comprensión de lo que debe ser entregado como parte del
proyecto, e incorporen lo aprendido de manera iterativa. Así, el tiempo y el esfuerzo requerido para
alcanzar el punto final definitivo, se reduce considerablemente y el equipo produce entregables que se
adaptan mejor al entorno empresarial.
Lanzamiento
© 2016 SCRUMstudy.com 8
Capítulo Visión de Agile y Scrum - Preguntas
1. ¿Cuál de las siguientes NO es una característica común de la gestión adaptativa de
proyectos?
A. Desarrollo iterativo del producto
B. Alto esfuerzo en la planificación adelantada (al inicio del proyecto)
C. Reduce el tiempo de lanzamiento al mercado
D. Entrega del producto flexible
2. Usted es el CEO de una empresa que maneja cuatro proyectos diferentes. ¿En qué
proyecto implementaría metodologías Ágiles?
A. Construcción de un edificio de departamentos multifamiliares de 5 plantas con 6
departamentos por piso.
B. Trabajo en la décima etapa de un proyecto de implementación a largo plazo de un software
en el que los requerimientos del proyecto fueron claramente definidos y la entrega, hasta
el momento, cumple con estos requerimientos.
C. El desarrollo de un aplicativo de software para un cliente para un ejercicio de gestión del
cambio que implica la identificación de las prácticas del estado actual y el desarrollo de
una hoja de ruta para el proceso del estado futuro en función de la visión del equipo de
gestión.
D. La construcción de un automóvil en una fábrica basada en un prototipo desarrollado con
anterioridad.
© 2016 SCRUMstudy.com 9
INFORMACIÓN GENERAL DE SCRUM
Scrum es una de las metodologías ágiles más populares. Emplea un enfoque adaptativo e iterativo
para gestionar proyectos y desarrollo de productos. Ha sido diseñada para ser una manera rápida,
flexible y eficaz para ofrecer _____ significativo de forma _________ en todo el proyecto.
El marco de Scrum, tal como se define en la Guía SBOK™, puede ser mejor entendido a través de sus
principios, procesos y aspectos.
Principios Scrum
1. Control del Proceso Empírico —Scrum establece que la toma de decisiones basada en la
observación y experimentación es mejor que la planificación detallada al inicio del proyecto.
2. Auto-organización —Este principio se centra en los miembros del equipo, quienes entregan
un valor significativamente mayor cuando son auto-organizados, lo cual genera equipos muy
comprometidos y con un alto nivel de responsabilidad; a su vez, esto produce un entorno
innovador y creativo que es más propicio para el crecimiento.
3. Colaboración —Este principio se centra en las tres dimensiones básicas relacionadas con el
trabajo colaborativo: conciencia, articulación y apropiación.
4. Priorización basada en el valor —Este principio pone de relieve el enfoque de Scrum para
ofrecer el máximo valor de negocio, desde el principio del proyecto hasta su conclusión.
© 2016 SCRUMstudy.com 10
5. Time-boxing —Este principio describe cómo el tiempo es considerado como una restricción
limitante en Scrum, y cómo se utiliza para ayudar a manejar eficazmente la planificación y
ejecución del proyecto.
6. Desarrollo Iterativo — Este principio define el desarrollo iterativo y enfatiza cómo manejar
mejor los cambios y crear productos que satisfagan las necesidades del Cliente. También
delinea las responsabilidades del Product Owner y de la organización relacionadas con el
desarrollo iterativo.
Un principio esencial de Scrum es que los requerimientos de cualquier proyecto de largo plazo no
pueden ser entendidos completamente o definidos al inicio del proyecto, especialmente si el mercado
sufre cambios constantemente, por lo que este enfoque debe permitir que el equipo sea flexible para
incorporar cambios de requerimientos. En el enfoque tradicional, el método predictivo de desarrrollo
no puede manejar tales cambios. En cambio, Scrum es especialmente útil para proyectos complejos
con gran ____________ en los cuales los pronósticos de largo plazo podrían conllevar a riesgos
críticos.
Scrum guía a través de la transparencia, inspección y adaptación para alcanzar los resultados más
valiosos de negocio.
Aspectos Scrum
Los aspectos de Scrum se deben abordar y gestionar a lo largo de un proyecto Scrum. Los cinco
aspectos de Scrum son:
1. Organización
2. Justificación de Negocio
3. Calidad
4. Cambio
5. Riesgo
© 2016 SCRUMstudy.com 11
Procesos de Scrum
Los procesos de Scrum abordan las actividades y el flujo específico de un proyecto Scrum. En total
hay diecinueve procesos que se agrupan en cinco fases.
© 2016 SCRUMstudy.com 12
El término "Producto" en la Guía SBOK™ puede referirse a un Producto o, Servicio, o cualquier otra
prestación. Scrum se puede aplicar de manera efectiva a cualquier proyecto en cualquier industria-
desde proyectos pequeños o equipos con tan sólo seis miembros, hasta proyectos grandes y complejos
con varios cientos de miembros por equipo.
© 2016 SCRUMstudy.com 13
¿Por qué utilizar Scrum?*
Algunas de las ventajas principales de la utilización de Scrum en cualquier proyecto son:
1. ______________ — El Control del Proceso Empírico y la Entrega Iterativa hacen que los
proyectos sean adaptables y abiertos a la incorporación de cambios.
2. ______________ —Todos los radiadores de información tales como el Scrumboard y el Sprint
Burndown Chart son compartidos, lo que promueve un ambiente de trabajo abierto.
3. _________________ Continua — Se proporciona a través de los procesos: Ejecutar
Reuniones Diarias y Demostrar y Validar.
4. ___________ Continua —Los entregables se mejoran progresivamente Sprint por Sprint a
través del proceso de Mantenimiento del Product Backlog.
5. Entrega Continua de Valor—los procesos iterativos permiten la entrega continua de valor tan
frecuentemente como el Cliente lo requiere a través del proceso Enviar los Entregables.
6. Ritmo Sostenible — Los procesos Scrum están diseñados de tal manera que las personas
involucradas pueden trabajar a un mismo ritmo que, en teoría, se puede continuar
indefinidamente.
7. Entrega Temprana de Alto Valor—El proceso de Crear el Product Backlog Priorizado
asegura que los requisitos de mayor valor del Cliente sean los primeros en satisfacerse.
8. Proceso de Desarrollo Eficiente— El time-boxing y la reducción al mínimo el trabajo que no
es esencial conduce a mayores niveles de eficiencia.
9. Motivación—Los procesos de Ejecutar la Reunión Diaria y la Retrospectiva del Sprint
conducen a mayores niveles de motivación entre los empleados.
10. Resolución de Problemas de forma más Rápida— Colaboración y la coubicación de equipos
multi-funcionales conducen a la resolución de problemas con mayor rapidez.
11. Entregables Efectivos—El procesos de Crear el Product Backlog Priorizado y revisiones
periódicas después de la creación de entregables asegura entregas efectivas para el Cliente.
12. Centrado en el Cliente — El poner énfasis en el valor del negocio y tener un enfoque de
colaboración con los interesados asegura un marco orientado al Cliente.
13. Entorno de Alta Confianza—Los procesos de Ejecutar la Reunión Diaria y la Retrospectiva
del Sprint promueven transparencia y colaboración, dando lugar a un ambiente de trabajo de
alta confianza, asegurando así una baja fricción entre los empleados.
14. Responsabilidad Colectiva—El proceso de Aprobar, Estimar y Comprometerse con Historias
de Usuario permite que los miembros del equipo se sientan responsables del proyecto, así su
trabajo tiene una mejor calidad.
15. Alta Velocidad—Un marco de colaboración que le permite a los equipos multi-funcionales
altamente calificados alcanzar su potencial y alta velocidad.
16. Medio Ambiente Innovador—Los procesos Retrospectiva del Sprint y Retrospectiva del
Proyecto crean un ambiente de introspección, aprendizaje y capacidad de adaptación que lleva
a un entorno de trabajo innovador y creativo.
© 2016 SCRUMstudy.com 14
Capítulo Visión General Agile y Scrum - Preguntas
1. El control del proceso empírico es un principio de Scrum que:
A. Es utilizado en casos en los que las entradas están claramente definidas.
B. Se centra en proporcionar control a través de inspecciones y adaptaciones frecuentes de
los procesos que están perfectamente definidos.
C. Se utiliza en situaciones en las que los procesos generan salidas impredecibles e
irrepetibles.
D. Se utiliza cuando una entrada particular ofrece siempre una salida específica.
2. Todos los siguientes son parte de los principios del Scrum EXCEPTO:
A. La auto-organización
B. Time-boxing
C. Priorización basada en valor
D. Control de procesos definidos
© 2016 SCRUMstudy.com 15
LOS ROLES DE SCRUM
Roles Básicos —Los Roles Básicos son las funciones que obligatoriamente se requieren para
producir el producto o servicio del proyecto, estos están ____________ con el proyecto, y son los
responsables del éxito de cada Sprint y del proyecto en su totalidad.
Roles no Básicos: son las funciones que no son obligatoriamente necesarias para el proyecto
Scrum, y pueden incluir miembros de los equipos que están interesados en el proyecto, pero no
tienen ningún papel formal en el equipo del proyecto. Ellos pueden interactuar con el equipo, pero
no son responsables del éxito del proyecto. Estos roles no esenciales también deben tenerse en
cuenta en cualquier proyecto de Scrum.
Core Roles
Hay tres Roles Básicos (roles/funciones principales) en Scrum que son los responsables de cumplir
con los objetivos del proyecto. Los roles básicos son el Product Owner, Scrum Master, y el Equipo
Scrum. Juntos se les conoce como el Equipo Central/Principal de Scrum (Scrum Core Team). Es
importante tener en cuenta que, de estos tres roles, ninguno tiene autoridad sobre los otros.
La figura presenta un resumen de los roles principales del Equipo Core de Scrum.
© 2016 SCRUMstudy.com 16
Core Role: Product Owner (Dueño del Producto)
El Product Owner representa a los interesados y es responsable de asegurar que el Equipo Scrum
entregue valor, a través del producto, al proyecto. El Product Owner escribe los requerimientos de
negocio en la forma de ________________ con apoyo de los miembros del Equipo Core Scrum;
también gestiona el Product Backlog (cartera de pendientes) en el proceso Priorizar el Product Backlog.
En algunos casos, los miembros del Equipo Scrum podrían escribir las User Stories (Historias de
Usuario) bajo la supervisión del Product Owner. El Product Owner es también responsable de asegurar
la comunicación clara de las funcionalidades del producto al Equipo Scrum, por lo que también es
conocido como la ___________________.
De la misma forma que existe un rol de Product Owner en un proyecto, podría haber un Product Owner
del Programa en un Programa, o un Product Owner del Portafolio en un Portafolio.
© 2016 SCRUMstudy.com 17
Proceso Responsabilidades del Product Owner
Identify Scrum Master and Ayuda a elegir al Scrum Master para el proyecto
Stakeholder(s) Identifica a los interesados
© 2016 SCRUMstudy.com 18
Core Role: Scrum Master
La responsabilidad principal del Scrum Master es asegurarse que los procesos Scrum sean aplicados
correctamente por todos los miembros del Equipo Core Scrum, incluyendo al Product Owner. El Scrum
Master es la persona responsable de garantizar que la gestión de proyectos avance sin problemas y
que los miembros del Equipo Scrum tengan todas las herramientas necesarias para hacer su trabajo.
El rol del Scrum Master se basa en el concepto de ________________ en el cual los líderes logran
resultados atendiendo a las necesidades de aquellos a quienes lideran.
De la misma forma que existe un rol de Scrum Master en un proyecto, podría haber un Scrum Master
del Programa en un Programa, o un Scrum Master del Portafolio en un Portafolio.
La tabla resume las responsabilidades del Scrum Master en los diferentes procesos de Scrum.
© 2016 SCRUMstudy.com 19
Procesos Responsabilidades del Scrum Master
Identify Scrum Master and Ayuda a identificar a los interesados del proyecto
Stakeholder(s)
Create Prioritized Product Ayuda al Product Owner en la creación del Product Backlog
Backlog Priorizado y en la definición de los Criterios de Terminado
Approve, Estimate and Facilita reuniones del Equipo Scrum para estimar y Crear
Commit User Stories Historias de Usuarios
© 2016 SCRUMstudy.com 20
Core Role: Scrum Team- Equipo Scrum
El Equipo Scrum es un grupo o equipo de personas que son responsables de la comprensión de los
requerimientos de negocio especificados por el Product Owner, de la estimación de Historias de
Usuarios y de la creación de los _________________ del proyecto.
Auto-organizados:
Les permiten a los miembros del equipo enfocarse en los resultados deseados del Sprint.
El equipo tiene un conjunto definido de objetivos durante cada Sprint y la flexibilidad para dar
cuenta de un cambio en los objetivos antes de comenzar el siguiente Sprint.
Garantiza que los miembros del Equipo Scrum decidan por sí mismos la forma de hacer el
trabajo del proyecto sin la microgestión de las tareas llevadas a cabo por un jefe.
Multi-funcionales:
Este modelo de equipo en Scrum está diseñada para optimizar la flexibilidad y la productividad.
Un equipo coubicado conformado por expertos funcionales que colaboran para alcanzar un
objetivo común tendrá mayor probabilidad de éxito que un equipo que trabaja separado
físicamente de acuerdo a la función que realiza.
Cuando un Equipo Scrum necesita ser distribuido, el Scrum Master debe garantizar que las
técnicas de comunicación eficaces estén disponibles para que los equipos puedan auto-
organizarse y trabajar con eficacia.
Entrega Iterativa de Producto:
La siguiente tabla muestra las responsabilidades del Equipo Scrum durante los diferentes procesos
de Scrum.
© 2016 SCRUMstudy.com 21
Proceso Responsabilidades del Scrum Team
Create Prioritized Product Se asegura de entender las Historias de Usuario del Product Backlog
Backlog Priorizado.
Acuerda con los miembros del Equipos Core Scrum la duración del
Sprint.
Conduct Release Planning Solicita aclaración de los nuevos productos o cambios al producto
existente en el Product Backlog Priorizado y Refinado.
Crea Entregables.
Identifica riesgos e implementa acciones de mitigación a los riesgos si
Create Deliverables es necesario.
Actualiza el Registro de Impedimentos y sus dependencias.
Actualiza el gráfico Sprint Burndown, el Scrumboard y el Registro de
Impedimentos.
Discute problemas que enfrentan los miembros y busca soluciones
Conduct Daily Standup para motivar al equipo.
Identifica riesgos si existiesen.
Presenta solicitudes de cambio si se requiere.
Demonstrate and Validate Presenta los entregables completos al Product Owner para su
Sprints aprobación.
© 2016 SCRUMstudy.com 22
Etapas de Desarrollo de Equipos
El método de Scrum inicialmente pueden parecer muy diferente y difícil para un nuevo Equipo Scrum.
Un nuevo Equipo Scrum, al igual que cualquier otro equipo nuevo, por lo general se desenvuelve a
través de un proceso de cuatro etapas. Este proceso se conoce como Modelo de Dinámica de Equipo
de Tuckman (Tuckman, 1965).
Las cuatro etapas del modelo son las siguientes:
____________________ Este a menudo se experimenta como un escenario divertido porque todo es
nuevo y el equipo aún no ha encontrado ninguna dificultad con el proyecto.
Storming (Turbulencia) Durante esta etapa, el equipo trata de cumplir con el trabajo. Sin embargo,
puede encontrar conflictos de poder y con frecuencia hay caos o confusión entre los
miembros del equipo.
____________________ En esta fase es cuando el equipo comienza a madurar, resolver sus
diferencias internas y encontrar soluciones para así trabajar juntos.
Performing (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.
© 2016 SCRUMstudy.com 23
Selección del Equipo
El Equipo Scrum es la base de cualquier Proyecto de Scrum y el tener a los miembros adecuados para
el equipo es vital para la entrega exitosa del proyecto. Los miembros del Equipo Scrum son
especialistas generalistas ya que cuentan con conocimiento de diversos campos y son expertos en al
menos uno. Más allá de la experiencia en la materia, son las habilidades interpersonales de cada
miembro del equipo que determinará el éxito de los equipos auto-organizados.
Los miembros ideales del Equipo Scrum son independientes, auto-motivados, enfocados al cliente y
tienen un sentido alto de responsabilidad y de colaboración.
Cuando se selecciona el equipo, un aspecto importante es crear _________ para cada miembro del
equipo. Esto asegura evitar que haya una disminución importante de la productividad debido a la
pérdida de miembros críticos.
© 2016 SCRUMstudy.com 24
Cliente
Usuarios
El usuario es el individuo o la organización que utiliza directamente el Producto, servicio, o
cualquier otro resultado del proyecto. Al igual que los Clientes, para cualquier organización
pueden haber usuarios internos y externos. También, en algunos proyectos los Clientes y los
usuarios pueden ser los mismos.
Patrocinador
© 2016 SCRUMstudy.com 25
Capítulo Roles de Scrum - Preguntas
A. Product owner
B. Interesado
C. Patrocinador del proyecto
D. Administrador del proyecto
A. Scrum Master
B. Product Owner
C. Cuerpo de Asesoramiento de Scrum (SGB)
D. Interesados externos
A. Scrum Master
B. Product Owner
C. Equipo de Scrum
D. Cuerpo de Asesoramiento de Scrum (SGB)
© 2016 SCRUMstudy.com 26
6. Las ventajas de utilizar un equipo multi-funcional son:
A. Scrum Master
B. Product Owner
C. Líder Equipo Scrum
D. Equipo Scrum
9. Miguel es responsable de resolver los conflictos entre los miembros del equipo de Scrum.
¿Qué rol está ejerciendo en un proyecto Scrum?
A. Scrum Master
B. Product Owner
C. Líder Equipo Scrum
D. Equipo Scrum
© 2016 SCRUMstudy.com 27
FASES SCRUM
La figura a continuación proporciona una visión general del flujo de un proyecto Scrum.
• El ciclo de Scrum comienza con la Fase de Inicio, durante la cual se determina la Visión del
Proyecto y se crea el Product Backlog (Cartera de Necesidades) priorizado.
• Luego el trabajo es completado en varios Sprints. Cada Sprint comienza con una Reunión de
Planificación del Sprint (Sprint Planning Meeting) durante la cual son escogidas las tareas (los
elementos con prioridad alta del Product Backlog) para el Sprint próximo a comenzar.
• Un Sprint suele durar entre ________ semanas en el cual el Equipo Scrum trabaja en la
elaboración Entregables (Deliverables) potencialmente listos en incrementos de producto.
• Las reuniones diarias (Daily Stand-up Meeting) se llevan a cabo durante el _______, donde Los
miembros del Equipo Scrum reportan el trabajo avanzado, el trabajo que se proponen terminar y
los impedimentos que están afrotando.
• Al final del Sprint, se lleva a cabo una reunión de revisión del Sprint (Sprint Review Meeting) en el
cual se le presenta una demostración del trabajo terminado al Product Owner y a los interesados
relevantes. El Product Owner acepta o rechaza los entregables presentados.
• El ciclo de Sprint termina con una Reunión de la Retrospectiva del Sprint (Retrospect Sprint
Meeting).
© 2016 SCRUMstudy.com 28
Fase Procesos
© 2016 SCRUMstudy.com 29
FASE: INICIAR
La primera fase de método Scrum es la fase Iniciar. Los procesos relacionados con la iniciación de un
proyecto son los siguientes:Crear la Visión del Proyecto, Identificar al Scrum Master e interesados,
Formar el Equipo Scrum, Desarrollar Epic(s), Crear la Lista de Pendientes del Producto Priorizada,
Realizar la Planificación de las Entregas (Release).
© 2016 SCRUMstudy.com 30
Reunión de la Visión del Proyecto
Reunión de la Visión del Proyecto es una reunión con los interesados del Programa, el Product Owner
del Programa, el Scrum Master del Programa y el jefe del Product Owner. Ayuda a identificar el contexto
empresarial, Requisitos del Negocio y las expectativas de los interesados con el fin de desarrollar una
Declaración de la Visión del Proyecto eficaz. Scrum cree en la participación y colaboración cercana
con todos los representantes de las compañía para que estén convencidos de apoyar al Proyecto.
Uno de los resultados de este proceso es identificar al Product Owner. El Product Owner es la persona
responsable de lograr el valor máximo empresarial para el Proyecto. Él o ella también es responsable
de la articulación de requisitos por parte de los Clientes y de mantener la Justificación de Negocio para
el Proyecto. El Product Owner representa la voz del Cliente.
Cada Equipo Scrum tendrá un Product Owner designado. Un pequeño Proyecto puede tener sólo un
Product Owner, mientras que los Proyectos más grandes pueden tener varios. Estos Product Owners
son responsables de la gestión del Product Backlog Priorizado. Ellos escriben los Historias de Usuarios
y gestionan el mantenimiento del Product Backlog.
El resultado clave del proceso Crear la Visión del Producto es la Declaración de la Visión del Proyecto.
Una buena visión del Proyecto explica la necesidad del negocio y que es lo que el Proyecto tiene como
objetivo satisfacer, en lugar de cómo se va a satisfacer la necesidad.
El Declaración de la Visión del Proyecto no debería ser muy específico y debe ser flexible. Es posible
que el conocimiento actual sobre el Proyecto esté basado en suposiciones que luego van a cambiar
conforme avanza el Proyecto, por lo que es importante que la visión del Proyecto sea lo suficientemente
flexible como para adaptarse a estos cambios. La visión del Proyecto debe centrarse en el problema y
no en la solución.
© 2016 SCRUMstudy.com 31
Proceso 2: Identificar al Scrum Master y a los Interesados
Un proyecto Scrum empieza cuando una necesidad de negocio y la visión son identificadas; entonces
se puede continuar con la identificación de los interesados del proyecto tales como el patrocinador,
usuarios finales, proveedores, etc, quienes estarán impactados por la necesidad de negocio o
ayudarán a llevarla a cabo. Por lo tanto, una vez que la Visión del Proyecto esté lista, el Product Owner
procede a identificar todos los interesados del proyecto. Dentro de este proceso, el Product Owner
identifica al Scrum Master, quien ayuda al Product Owner a cumplir con la Visión del Proyecto siendo
el jefe facilitador y mentor del Equipo Scrum.
Es importante que cuando el Product Owner seleccione al Scrum Masters tenga en cuenta sus
habilidades de resolución de conflictos, que encarne el estilo de gestión : ______________, y que se
comprometa a brindar al Equipo Scrum un ambiente propicio para la entrega exitosa del proyecto.
Criterios de selección
La selección adecuada del Scrum Master y la identificación de los interesados adecuados es crucial
para el éxito de cualquier proyecto. En algunos proyecto puede haber pre-condiciones que estipulen
determinados miembros del equipo y sus roles.
Cuando hay flexibilidad en la elección del Scrum Master, se deben considerar los siguientes criterios
de selección:
© 2016 SCRUMstudy.com 32
1. Habilidades para la resolución de problemas—Es uno de los principales criterios a considerar al
seleccionar al Scrum Master. El Scrum Master debe tener las habilidades y experiencia necesarias
para ayudar a eliminar cualquier Impedimento que encare el Equipo Scrum.
2. Disponibilidad—El Scrum Master debe estar disponible para agendar, supervisar y facilitar las
reuniones, incluyendo Release Planning Meeting, Daily Standup Meeting, y otras reuniones
relacionadas al Sprint.
3. Compromiso—El Scrum Master se debe comprometer a que el Equipo Scrum esté dotado de un
ambiente de trabajo propicio para asegurar la entrega exitosa del proyecto Scrum.
4. Líder Servicial
En la identificación de los Interesados es importante recordar que los Interesados incluyen a todos los
clientes, los usuarios y patrocinadores, quienes a menudo interactúan con el Product Owner, Scrum
Master y Equipo Scrum para proveer entradas y facilitar la creación de los productos del Proyecto. Los
Interesados influyen en el proyecto a lo largo de su ciclo de vida.
Scrum Master Identificado
Un Scrum Master es un facilitador y Líder Servicial que se asegura de que el Equipo Scrum esté dotado
de un ambiente propicio para completar el Proyecto con éxito. El Scrum Master guía, facilita y enseña
prácticas de Scrum a todos los involucrados en el Proyecto; elimina impedimentos que encara el
equipo; y asegura que se estén siguiendo los procesos de Scrum. Es la responsabilidad del Product
Owner identificar al Scrum Master para un proyecto Scrum.
Interesados Identificados
Los interesados, término colectivo que incluye a los Clientes, los usuarios y los patrocinadores, quienes
con frecuencia interactúan con el Equipo Core Scrum, influyen en el Proyecto durante todo el proceso
de desarrollo de Productos.
© 2016 SCRUMstudy.com 33
Proceso 3: Formar el Equipo Scrum
Form Scrum Team
Uno de los procesos más importantes en el flujo Scrum es la formación del Equipo Scrum, porque éste
es el que crea los entregables del proyecto, y con estos se logra satisfacer la Visión del Proyecto.
El Equipo Scrum es también conocido como el Equipo de __________. Un Equipo ideal Scrum tiene
entre 6 a 10 miembros. Los miembros del Equipo Scrum son especialistas generalistas, donde cada
uno debe poseer un conocimiento general de diversos campos y son expertos en al menos uno. Más
allá de ser expertos técnicos, son las habilidades interpersonales de cada miembro del equipo que
determinará el éxito de los equipos auto-organizados.
El Product Owner y el Scrum Master colaboran para formar el Equipo Scrum. El Equipo Scrum es
formado teniendo en cuenta la Visión del Proyecto porque el tipo de proyecto y el tipo de industria son
factores cruciales en la selección de expertos técnicos. Sin embargo el Product Owner y el Scrum
Master podría considerar otros factores como los requerimientos de personal, disponibilidad y
compromiso de las personas y la matriz de destrezas requeridas.
Una vez que el Equipo Scrum es seleccionado, el Equipo Core Scrum (Product Owner, Scrum Master
y Equipo Scrum) está completo. La salida más importante de este proceso es un equipo
____________ y ________________.
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.
© 2016 SCRUMstudy.com 34
Objetivos de un equipo auto-organizado
© 2016 SCRUMstudy.com 35
1. Scrum Core Team* 1. Reunión de Grupo de 1. Epic(s) *
2. Declaración de la Visión del Usuarios * 2. Personas *
Proyecto * 2. Talleres de Historia de 3. Campos Aprobados
3. Interesados
Usuario 4. Riesgos Identificados
4. Product Backlog del
Programa 3. Reunión de Grupos de
5. Solicitudes de Cambio Opinión (Focus Group)
Aprobadas 4. Entrevista a Usuarios o
6. Solicitud de Cambio no Clientes
Aprobadas 5. Cuestionarios
7. Riesgos del Portafolio y del 6. Técnicas de Identificación
Programa
de Riesgos
8. Leyes y Regulaciones
9. Contractos 7. Juicio Experto del Cuerpo
10. Información Previa del de Asesoramiento de
Proyecto Scrum
11. Recomendaciones del
Cuerpo de Asesoramiento
de Scrum
La Reunión de Grupo de Usuarios involucre a los interesados del proyecto, principalmente los usuarios
o Clientes del Producto. Ellos proporcionan al Equipo Core de Scrum información de primera mano
acerca de las expectativas del usuario. Esto ayuda en la formulación de los Criterios de Aceptación
para el Producto y proporciona información valiosa para el desarrollo de Epics.
Creación de una Persona
Esto implica la asignación al personaje de un nombre ficticio y preferentemente una foto. A la Persona
se le incluirán atributos muy específicos como su edad, género, nivel de educación, entorno, intereses
y metas. Una cita que ilustra las necesidades de la persona puede ser incluida también. A continuación
se muestra un ejemplo de una Persona para un sitio web de viajes.
© 2016 SCRUMstudy.com 36
Proceso 5: Crear la Lista de Requerimientos Pendientes del Producto
Priorizada
© 2016 SCRUMstudy.com 37
1. Scrum Core Team* 1. Métodos de Priorización de 1. Product Backlog Priorizado
2. Epic(s) * Historias de Usuarios * (Prioritized Product
3. Personas * 2. Talleres de Historia de Backlog)*
4. Interesados 2. Criterio de Terminado
Usuario
5. Declaración de la Visión del (Done Criteria)*
Proyecto 3. Planificación de Valor
6. Product Backlog del 4. Técnicas de Evaluación de
Programa Riesgo
7. Requisitos del Negocio 5. Estimación de Valor del
8. Solicitudes de Cambio Proyecto
Aprobadas 6. Métodos de Estimación de
9. Riesgos Identificados
Historias de Usuario
10. Contratos
11. Recomendaciones del 7. Juicio Experto del Cuerpo
Cuerpo de Asesoramiento de Asesoramiento de
de Scrum Scrum
© 2016 SCRUMstudy.com 38
Esquema de Priorización MoSCoW—El esquema de priorización MoSCoW deriva su nombre
de las primeras letras de las frases "Must have" (Debe tener), “Should have” (Debería tener),
"Could have” (Podría tener), y "Would like to have, but not at this time” (Quisiera tenerlo, pero
no ahora). Las etiquetas están en orden decreciente de prioridad. "Debo tener" estas Historias
de Usuarios: son aquellas que si no son incluidas en el producto, este no tendrá valor y
"Quisiera, pero no ahora" estas Historias de Usuarios: son aquellas que, a pesar de que sería
bueno tenerlas, no es necesario incluirlas.
Comparación por Pares (Paired Comparison)— En esta técnica se prepara una lista de
todas las Historias de Usuarios del Product Backlog Priorizado. Luego, cada Historia de
Usuario se toma de forma individual y se compara con las otras Historias de Usuarios en la
lista, uno a la vez. Cada vez que dos Historias de Usuarios se comparan, se toma una decisión
sobre cuál de los dos es más importante. A través de este proceso, se puede obtener una lista
priorizada de las Historias de Usuarios.
Método de los 100 Puntos (100-point method) — Fue desarrollado por Dean Leffingwell y
Don Widrig (2003). Se trata de dar al Cliente 100 puntos que puede usar para votar por las
Historias de Usuarios más importantes. El objetivo es dar más peso a las Historias de Usuarios
que son de mayor prioridad en comparación con las otras Historias de Usuarios disponibles.
Cada miembro del grupo asigna puntos a las diversas Historias de Usuarios, dando más puntos
a aquellas que consideran 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.
Criterios de Terminado (“Done”)
Es un conjunto de reglas que se aplican a todas los Historias de Usuarios. Una definición clara de
“Done” es crítica, ya que elimina la ambigüedad de los requisitos y ayuda a que el equipo se adhiera a
las normas de calidad obligatorias. Esta definición se utiliza para crear los Criterios de Terminado, que
son un resultado del proceso de Crear la Lista de Requerimientos Pendientes del Producto. Una
Historia de Usuario se considera Terminada (“Done”) cuando se le muestra y es aprobada por el
Product Owner que juzga sobre la base de los Criterios de Terminado y los Criterios de Aceptación de
la Historia del Usuario.
© 2016 SCRUMstudy.com 39
Proceso 6: Realizar la Planificación de los Entregables
© 2016 SCRUMstudy.com 40
FASE: PLANEAR Y ESTIMAR
Como parte de esta fase, el Equipo Core de Scrum crea, aprueba, estima y se compromete con un
grupo de Historias de Usuarios, adicionalmente crea y estima tareas, finalmente crea el Sprint Backlog.
© 2016 SCRUMstudy.com 41
El formato de una Historia de Usuario es el siguiente:
Como <rol del usuario> deseo <descripción del requerimientos> para <beneficio>.
Junto con las Historias de Usuario, el Equipo Core Scrum escribe los Criterios de Aceptación. Las
Historias de Usuario son a veces subjetivas, por lo que los Criterios de Aceptación brinda la objetividad
requerida para las Historias de Usuario para ser consideradas como Terminadas o no Terminadas
durante la Revisión de un Sprint.
Los Criterios de Aceptación ayudan al equipo a entender qué se espera de una Historia de Usuario,
eliminan la ambigüedad de los requerimientos y ayuda a alinear expectativas. El Product Owner define
y comunica el ________________ al Equipo Scrum. En los Sprint Review Meetings, el Critero de
Aceptación brinda el contexto para que el Product Owner decida si la Historia de Usuario ha sido
completada satisfactoriamente. Es importante, y es responsabilidad del Scrum Master, asegurar que
el Product Owner no cambie los Criterios de Aceptación de una Historia de Usuario, mientras este se
esté ejecutando, que ya está comprometida a un Sprint,.
.
© 2016 SCRUMstudy.com 42
Proceso 2: Aprobar, Estimar y Comprometerse con las Historias de Usuarios
Algunas herramientas conocidas que se pueden utilizar para este proceso son:
Wideband Delphi
Es una técnica de estimación grupal para determinar cuánto trabajo está involucrado y cuánto
tiempo tomará completarlo. Los participantes de forma anónima proveen estimaciones de cada
funcionalidad, y estas estimaciones iniciales son graficadas en un cuadro. El equipo entonces
discute sobre los factores que influenciaron en sus estimations y se procede a realizar una
segunda ronda de estimación. Este proceso se repite hasta que el estimado de los participantes
© 2016 SCRUMstudy.com 43
converja y se llegue a un consenso en el estimado final. La información de cada participantes se
recolecta de forma que se evite el problema de pensamiento de grupo (group think).
Planificación Poker (Planning Poker)
También llamada Estimación Poker, es una forma de aplicar Wideband Delphi. Es una técnica de
estimación donde se utiliza el consenso para estimar tamaños relativos de Historias de Usuario o
el esfuerzo requerido para crearlos.
En Planificación Poker, a cada miembro se le asigna una baraja de cartas, cada carta está
numerada en una secuencia. Estos números representan la complejidad del problema, en
términos de tiempo o esfuerzo. El Product Owner escoge una Historia de Usuario del Product
Backlog Priorizado y lo presenta al equipo. Los miembros del Equipo Scrum evalúan la Historia
de Usuario y tratan de entenderla mejor antes de dar su estimación para desarrollarla. Entonces
cada miembro elige una carta de la baraja que represente su estimado para la Historia de Usuario.
Si la mayoría o todos los miembros del equipo eligen la misma carta, entonces esta será la
estimación de la Historia de Usuario. Si no hay consenso, entonces los miembros del equipo
discuten las razones por la que seleccionaron diferentes cartas o estimaciones. Después de la
discusión, vuelven a escoger una carta. Se siguen los mismos pasos hasta que los supuestos
sean comprendidos y los malentendidos sean resueltos, de esta forma se alcanzará consenso en
la estimación. La Planificación Poker promueve la interacción entre los participantes y mejora la
comunicación. También permite el pensamiento independiente de los participantes evitando el
fenómeno de pensamiento de grupo.
© 2016 SCRUMstudy.com 44
El número de dedos usados para votar indica cuán de acuerdo está el participante con el tema
propuesto y si tiene observaciones que desea discutir con el grupo:
Dos dedos: Estoy en desacuerdo con la conclusión del grupo y quisiera revisar con el
grupo algunas preocupaciones menores.
Tres dedos: No estoy seguro pero elijo estar de acuerdo con la conclusión del grupo.
Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y quisiera discutir algunos
temas menores.
© 2016 SCRUMstudy.com 45
Proceso 3: Crear Tareas
Crear Tasks
En las fases iniciales donde se ponen por escrito los requerimientos, la mayoría de las Historias de
Usuario recaban información de funcionalidades de alto nivel, por lo que éstas tienen que ser
desglosadas en __________ realizables y simples.
Reunión de Planificación de Tareas (Task Planning Meeting)
Como parte de esta reunión, los miembros del Equipo Scrum revisan las Historias de Usuario
Comprometidas a detalle para eliminar ambigüedades resolver todas las preguntas. Aunque no es
mandatoria la presencia del Product Owner en esta reunión, es importante su participación porque
ayudará al Equipo Scrum a entender mejor las Historias de Usuario, lo que hará que la reunión sea
más eficiente. La creación de tareas se realiza durante la Reunión de Planificación de Tareas. Esta
reunión está dividida en dos partes:
•El Product Owner sugiere Historias de Usuario que deben formar parte del
Sprint.
•El Equipo Scrum determina cuántas Historias de Usuario pueden ser
Primera ejecutadas en un Sprint.
•Se alcanza consenso en las Historias de Usuario de serán incluídas en el Sprint.
Parte
© 2016 SCRUMstudy.com 46
1. Scrum Core Team* 1. Reunión de Planificación 1. Lista de Tareas *
2. Historias de Usuario de Tareas* 2. Historias de Usuarios
Aprobadas, Estimadas y 2. Tarjetas Aprobadas, Estimadas,
Comprometidas * 3. Descomposición Comprometidas y
4. Determinación de Actualizadas
Dependencias 3. Dependencies
© 2016 SCRUMstudy.com 47
El Tiempo Ideal (Ideal Time) normalmente describe el número de horas que un miembro del Equipo
Scrum trabaja exclusivamente en el desarrollo de los entregables del proyecto, sin incluir el tiempo
dedicado a otras actividades o trabajos que están fuera del proyecto.
Es importante monitorear el progreso del Sprint y conocer el avance del Equipo Scrum midiendo
las tareas completadas del Sprint Backlog. Una de las herramientas de seguimiento es el
Scrumboard, conocido como Tablero de tareas y Cuadro de Avance.
Un Scrumboard estándar contiene 4 columnas que indican el progreso de las treas estimadas
para el Sprint: la columna “Pendiente” (“To Do”) para las tareas que aún no empiezan, la columna
“En Progreso” (“In Progress”) para tareas que empezaron pero no han sido completadas aún, la
columna “En Pruebas” (“Testing”) para tareas que han sido completadas pero se encuentran en
el proceso de ser probadas y la columna “Terminado” (“Done”) para tareas terminadas y probadas
exitosamente. Una columna opcional es la quinta: “Stories”. Al inicio del Sprint, todas las tareas
se colocan en la columna “To Do” y se van moviendo a las columnas siguientes de acuerdo al
avance.
© 2016 SCRUMstudy.com 48
La siguiente figura muestra un ejemplo de un Scrumboard:
Las principales salidas de este son el Sprint Backlog y el Gráfico Sprint Burndown.
1. Sprint Backlog (Lista de Pendientes del Sprint) – Es la lista de las tareas a ser ejecutadas por
el Equipo Scrum en el próximo Sprint. Es una práctica común que el Sprint Backlog se muestre en
un Scrumboard o tablero de tareas, este proporciona una representación visible y constante de la
situación de las Historias de Usuarios en el backlog. También se incluyen en el Sprint Backlog
algunos Riesgos asociados con las diversas tareas. Las actividades de mitigación a los riesgos
identificados podrían ser incluidas como tareas en el Sprint Backlog.
Una vez que el Sprint Backlog se haya finalizado y el Equipo Scrum se haya comprometido al
mismo, no deben añadirse nuevas Historias de Usuarios; sin embargo, puede ser necesario añadir
las tareas que pueden haberse pasado por alto o ignorado. Si surgen nuevas necesidades durante
un Sprint, se añadirán al Product Backlog Priorizado y se incluirán en un Sprint posterior.
2. Sprint Burndown Chart – Es un gráfico que muestra la cantidad de trabajo que queda por hacer
en el Sprint actual. El Gráfico Sprint Burndown inicial es acompañado por un Burndown planeado.
El Gráfico Sprint Burndown debe actualizarse al final de cada día laborable.
La siguiente figura muestra un ejemplo del Sprint Burndown Chart:
© 2016 SCRUMstudy.com 49
Este gráfico muestra el trabajo estimado pendiente (en el eje Y) y el tiempo (en el eje X).
Al final del día, los miembros del Equipo Scrum actualizan el gráfico con el trabajo
completado.
© 2016 SCRUMstudy.com 50
FASE: IMPLEMENTAR
La fase de Implementar abarca las ejecución de las tareas y actividades para crear el producto, servicio
o resultado del proyecto. Estas actividades incluyen la creación de varios entregables, llevar a cabo la
Reunión diaria y el mantenimiento del Product Backlog (es decir revisar, ajustar y actualizar
periodicamente).
El esfuerzo principal de desarrollo recae en el Equipo Scrum, y como este es auto-organizado y multi-
funcional, la decisión de cómo desarrollar algunas tareas recae en los miembros del Equipo Scrum. Ni
los interesados, ni el Scrum Master, tampoco el Product Owner puede dirigir al equipo en la forma de
desarrollar los entregables. Los miembros del Equipo Scrum son expertos en sus dominios, y su juicio
y experiencia son aplicadas a todos los aspectos técnicos y de gestión del proyecto durante este
proceso.
La salida más importante de este proceso es el entregable del Sprint, también conocido como el
_______________, el cual satisface todas las características y funcionalidades definidas en las
Historias de Usuario del Sprint. Si los miembros del Equipo Scrum enfrentan cualquier obstáculo
mientras completan los entregables del Sprint, ellos los registran en el Impediment Log. Un Impediment
Log es mantenido por el Scrum Master, y es su responsabilidad resolver los problemas y eliminar los
impedimentos.
Cuando el Product Owner quiere hacer cambios en medio del Sprint, el alcance del Sprint en curso no
es modificado. Si el cambio que se requiere es tan importante que el resultado del Sprint en curso
podría ser inútil sin hacer estas modificaciones, entonces el actual Sprint debería ser terminado, y un
nuevo Sprint que incorpora el cambio debe ser iniciado. Caso contrario, el cambio será incluido en un
Sprint posterior.
© 2016 SCRUMstudy.com 51
Proceso 2: Realizar la Reunión Diaria
Aparte de la colaboración, las Reuniones Diarias promueven la transparencia entre los miembros del
Equipo Core Scrum. El Scrum Master ayuda a los miembros del equipo a resolver problemas e
impedimentos. El Scrum Master sólo es un facilitador, no dirige la reunión. El Daily Standup Meeting
solo es un foro de intercambio de información. Cualquier discusión sobre la resolución de un problema,
si es necesaria, se realiza después de la reunión diaria. El Scrum Master recolecta información de los
impedimentos que los miembros del Equipo Scrum están enfrentando al realizar los trabajos del Sprint
y los resuelve después de la reunión.
© 2016 SCRUMstudy.com 52
Proceso 3: Mantenimiento de los Pendientes Priorizados del Producto
El tercer proceso en la fase de Implementar es el proceso Groom Prioritized Product Backlog. Para
asegurar que los elementos priorizados del Product Backlog estén refinados, es recomendable que
entre el 7% al 10% de cada Sprint sea destinado para refinar el backlog. El Product Owner es
responsable de refinar el Product Backlog Priorizado, lo que conlleva a añadir o cambiar algunos
elementos para satisfacer cambios de requerimientos y para detallar Historias de Usuario para el
siguiente Sprint.
Este proceso asegura que el Product Backlog Priorizado esté refinado bien antes del siguiente Sprint,
así el Equipo Scrum tendrá un grupo de historias bien analizadas y claramente definidas que permitirá
agilizar el desglose de tareas y el proceso de estimación. También permite que el desarrollo sea más
flexible porque se podrá incorporar requerimientos recientes técnicos y de negocio en el siguiente
Sprint. De acuerdo a la informacón del cliente, cambios externos del mercado y conocimiento ganado
del Sprint actual y de los anteriores, el Product Backlog Priorizado es repriorizado.
Scrum no considera que este tipo de reuniones tenga una restricción de tiempo (timebox). Este proceso
es una tarea permanente del Product Owner.
© 2016 SCRUMstudy.com 53
FASE: REVISIÓN Y RETROSPECTIVA
La fase Revisión y Retrospectiva se ocupa de la revisión de los entregables y del trabajo que se ha
hecho, y determina las mejores prácticas y métodos utilizados para hacer el trabajo relacionado al
proyecto. En las grandes organizaciones, el proceso de Revisión y Retrospectiva puede incluir la
convocatoria de Reunión de Scrum de Scrums.
5. Impediment Log
6. Dependencias
7. Salidas de la Retrospectiva
del Sprint
© 2016 SCRUMstudy.com 54
Cada representante de los Equipos Scrum proporcionará actualizaciones de su equipo. Estas
actualizaciones se proporcionan generalmente en forma de respuestas a cuatro preguntas específicas:
1) ¿En qué ha estado trabajando mi equipo desde la última reunión?
2) ¿Qué va a hacer mi equipo hasta la próxima reunión?
3) ¿Qué consideraban otros equipos que mi equipo termine que no se ha hecho?
4) ¿Qué está planeando hacer nuestro equipo que pueda afectar a otros equipos?
La salida principal de las Reuniones Scrum de Scrum es la mejor coordinación entre varios equipos
trabajando en el mismo proyecto.
© 2016 SCRUMstudy.com 55
Proceso 3: Retrospectiva del Sprint
Retrospect Sprint
Luego de la Reunión de Revisión del Sprint (Sprint Review Meeting) el Equipo Scrum se reúne en la
Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting). Esta es una oportunidad para que el
Equipo Scrum se tome un momento para mirás hacia atrás y examinar el Sprint que acaba de terminar
para identificar mejoras potenciales en el proceso. Estas mejoras pueden resultar no solo en un simple
acuerdo entre miembros del equipo para hacer las cosas de otra forma, también puede definir
elementos no funcionales para el Product Backlog Prioritizado.
En la Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting) participan el Scrum Master y los
miembros del Equipo Scrum. El Product Owner podría asistir pero no es obligatoria su presencia.
Los miembros del equipo revisan qué se hizo bien y qué no en el Sprint que acaba de terminar.
Plantean los problemas que enfrentaron durante el Sprint y discuten cómo se podrían direccionar estos
temas. El Equipo identifica mejoras potenciales en la forma de trabajo y también sugiere mejoras en la
definición de Done basándose en su experiencia.
Para llevar a cabo una reunión efectiva de Retrospectiva, el evento puede tener estos 5 pasos:
Gather data (Obtener información): El equipo comparte información sobre el Sprint que
acaba de terminar y discuten sobre las fortalezas y debilidades. Este estado permite que
los participantes se enteren sobre las cosas más importantes que sucedieron en el Sprint.
Generate insight (Generar ideas): Este paso está enfocado en la pregunta “Por qué”?
(¿por qué algunas cosas funcionaron bien y por qué otras necesitan cambiar?) Este ayuda
a los participantes a tener perspectiva y a saber la causa raíz de los problemas.
© 2016 SCRUMstudy.com 56
Action (Acción): El equipo descubre la solución para mejorar el trabajo que se viene
haciendo y para reducir o prevenir errores.
Circle of questions and Closing (Círculo de preguntas y Cierre): Cada miembro del equipo
tiene la oportunidad de preguntar o compartir sus preocupaciones. En esta etapa se
clarifican las acciones que se realizarán en el siguiente Sprint. Finalmente, los miembros
del equipo se agradecen entre si y se cierra la reunión.
La información, opiniones, discusiones y los puntos acordados que son expuestos en la Reunión
de Retrospectiva del Sprint (Retrospect Sprint Meeting) son registradas en el Retrospect Sprint Log.
© 2016 SCRUMstudy.com 57
FASE: LANZAMIENTO
La fase de lanzamiento (release) destaca la entrega de los Entregables Aceptados al Cliente y la
identificación, documentación e internalización de las lecciones aprendidas del proyecto.
Ship Deliverables
Después que el Product Owner valida los ____________ del Sprint basándose en los Criterios de
Aceptación y de Terminado, los Entregables Aceptados están listos para la entrega o lanzamiento a
los Interesados. Sin embargo, no todos los Sprints terminan en un lanzamiento. La decisión de cuándo
la entrega es un incremento de producto potencialmente comercializable para los interesados es hecha
en el proceso Conduct Release Planning.
El Cronograma de Planificación de Entrega (Release Planning Schedule) documenta qué entregables
serán liberados y cuándo. De este modo, las entradas principales para este proceso son los
Entregables Aceptados y el Cronograma de Planificación de Entrega.
Los entregables son lanzados utilizando los Métodos de Despliegue de la Organización. Cada
organización tiene sus propios Métodos de Despliegue. Estos guían cómo y cuándo los entregables
serán liberados a los interesados. Las principales salidas de este proceso son los Entregables
Trabajados, Acuerdos de Entregables Trabajados y Lanzamientos de Producto.
© 2016 SCRUMstudy.com 58
Proceso 2: Retrospectiva del Proyecto
Retrospect Project
El último proceso del flujo Scrum es la Retrospectiva del Proyecto, la cual es similiar al proceso
Retrospectiva del Sprint, pero a nivel de proyecto. Después que todos los incrementos de producto son
entregados exitosamente a los interesados, el Equipo Core Scrum o los equipos revisan, analizan e
identifican qué se hizo bien y que no durante el ciclo del proyecto.
La reunión de Retrospectiva del Proyecto (Retrospect Project Meeting) tiene el objetivo de identificar
las mejores _______________ y recomendaciones para el Cuerpo de Asesoramiento Scrum (Scrum
Guidance Body). No solo ayuda a mejorar la colaboración y eficiencia del equipo, también identifica
mejoras para toda la implementación Scrum. Las sugerencias, opiniones y conocimientos obtenidos
en la reunión de Retrospectiva del Proyecto son registrados para referencias futuras.
© 2016 SCRUMstudy.com 59
Capítulo Flujo Scrum - Preguntas
1. El conjunto de prioridades de trabajo a realizar se conoce como
A. Una historia de usuario.
B. La Cartera priorizada del producto.
C. Un gráfico Burndown.
D. Aceptado entregables.
6. ¿Cuál de los siguientes NO es una entrada para el proceso de Envío de Entregables (Ship
Deliverables)?
A. Entregables Aceptados
B. Crnonograma de Planificación de Entregas
C. Product Owner
D. Impediment Log
© 2016 SCRUMstudy.com 60
8. ¿Cuál de las siguientes herramientas es utilizada por el Equipo Scrum para estimar en el
proceso de Estimación de Tareas?
A. Experiencia en la escritura de Historias de Usuario
B. Wideband Delphi
C. Comparativo por Pares
D. Sesiones JAD
A. Velocidad del equipo es una medida de la cantidad de trabajo que un equipo puede
completar en un Sprint.
B. Velocidad histórica del equipo que se utiliza como un indicador en la asignación de tareas
para cada Sprint.
C. La velocidad del equipo es independiente de la composición del equipo.
D. La velocidad del equipo se utiliza en la decisión de los plazos de entrega.
10. ¿Cuál de los siguientes no es discutido en una reunión Standup diaria (Daily Standup
Meeting)?
A. Lo que el miembro del equipo ha avanzado desde la última reunión
B. Lo que el miembro del equipo tiene previsto trabajar hasta la próxima reunión
C. Lo que el miembro del equipo ha aprendido al completar su trabajo
D. Las barreras que el miembro del equipo enfrenta
11. ¿Cuál es la duración normal de una reunión Standup diaria (Daily Standup Meeting)?
A. 5 minutos
B. 1 hora
C. 15 minutos
D. Reuniones de stands-up no tienen límite de tiempo.
12. Asegurar que las reuniones diarias de Standup se ejecutan de manera oportuna y
estructurada es la responsabilidad de
A. Scrum Master
B. Product Owner
C. Scrum Team Leader
D. Del grupo a nivel colectivo
13. El Sprint Burndown Chart es una herramienta utilizada por los equipos para
A. Medir el trabajo completado durante un Sprint.
B. Medir el trabajo que queda por realizar durante un Sprint.
C. Calcular el remanente del presupuesto del equipo.
D. Identificar los miembros de bajo rendimiento del equipo.
14. La reunión en la que el equipo discute las tareas a realizar en el próximo Sprint es conocido
como la:
A. Reunión de Visión de Producto (Product Vision Meeting).
B. Reunión de Planificación del Sprint (Sprint Planning Meeting).
C. Reunión de Revisión de Sprint (Sprint Review Meeting).
D. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting).
© 2016 SCRUMstudy.com 61
15. La reunión al final del Sprint en el que el equipo presenta su trabajo al Product Owner es
conocido como la:
A. Reunión de Visión de Producto (Product Vision Meeting).
B. Reunión de Planificación del Sprint (Sprint Planning Meeting).
C. Reunión de Revisión de Sprint (Sprint Review Meeting).
D. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting).
16. La reunión en la que el equipo analiza el Sprint anterior e identifica mejoras potenciales
en los procesos se conoce como la:
A. Reunión de Visión de Producto (Product Vision Meeting).
B. Reunión de Planificación del Sprint (Sprint Planning Meeting).
C. Reunión de Revisión de Sprint (Sprint Review Meeting).
D. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting).
18. ¿Cuál de las siguientes actividades NO es parte de la Reunión de Retrospectiva del Sprint
(Retrospect Sprint Meeting)?
A. El equipo discute los aspectos positivos y negativos del Sprint anterior.
B. El equipo identifica los problemas que enfrentaron en el Sprint anterior y discute cómo
mitigar estos temas en Sprints futuros.
C. El equipo revisa e identifica posibles mejoras en su trabajo.
D. Sobre la base de los cambios propuestos, el equipo procede a cambiar la prioridad de la
Pila de Producto priorizada (Prioritized Product Backlog).
19. Las ventaja del proceso Grooming the Prioritized Product Backlog (Mantenimiento de los
Pendientes Priorizados del Producto) es la siguiente:
A. El conocimiento ganado a partir de un Sprint anterior se incorpora en Sprints futuros.
B. Los últimos requisitos técnicos y de negocio se agregan al siguiente Sprint.
C. El mantenimiento del Product Backlog priorizado asegura tenerlo refinado antes de la
reunión de planificación de Sprint para que el equipo tiene una mejor idea de los requisitos
antes de la reunión.
D.Todas las anteriores.
21. ¿Cuál de las siguientes actividades se pueden realizar en conjunto durante la reunión de
planificación del Sprint (Sprint Planning Meeting)?
A. Estimación Tareas y Planificación de Entregas
B. Mantenimiento de la Pila de Producto y Planificación de Tareas
C. Planificación de Tareas y Tareas de Estimación
D. Planificación de Entregas y Mantenimiento de la Pila de Producto
© 2016 SCRUMstudy.com 62
22. ¿Cuál de las siguientes no es parte de la reunión de planificación de Sprint?
A. El Product Owner, explica los principales elementos de la Pila de Producto priorizada para
el equipo.
B. El Equipo Scrum, en colaboración con el Product Owner, estima las tareas de un Sprint
dado.
C. Sobre la base de las estimaciones, el equipo se compromete en algunas tareas que deben
completarse en el próximo Sprint.
D. El equipo recibe la retroalimentación de las partes interesadas.
23. Usted es miembro de un equipo Scrum y se le indica que el gerente general de la empresa
ha solicitado que se desarrolle una tarea urgente que no forma parte del Sprint actual.
¿Qué debe hacer?
A. Hacerse responsable de la tarea, y hablar con el Product Owner para ampliar el plazo del
Sprint actual.
B. Hablar con el Scrum Master para volver a asignar las tareas a otra persona.
C. Hablar con el Product Owner para volver a a asignar las tareas a otra persona.
D. Informar al Scrum Master de la situación para que revise la situación con el gerente
general.
E. No realizar ninguna acción porque ya está ocupado.
24. Para cualquier Sprint en curso, ¿cuándo se pueden agregar nuevas historias de usuarios?
A. Cuando el Scrum Master agrega la historia de usuario a la Pila de Sprint (Sprint Backlog)
B. Cuando el Product Owner (propietario del producto) aprueba la historia de usuario
C. Cuando el equipo Scrum aprueba la historia de usuario
D. Nuevas historias de los usuarios nunca pueden ser añadidas al Sprint
26. ¿En cuál de los siguientes procesos de la fase Iniciar se determina la duración del Sprint?
A. Crear Visión del Proyecto
B. Desarrollar Epics
C. Crear la Pila de Producto Priorizada
D. Realizar la Planificación de las Entregas (Conduct Release Planning)
© 2016 SCRUMstudy.com 63
ESCALANDO SCRUM
Escalabilidad de Scrum
Para ser eficaz, los Equipo Scrums deben tener idealmente de seis a diez miembros. Esta práctica
podría llevar a la idea errónea de que el método de Scrum sólo se puede utilizar para proyectos
pequeños. Sin embargo, se puede escalar fácilmente para el uso eficaz en proyectos grandes. En
situaciones donde el tamaño del Equipo Scrum excede los diez miembros, múltiples Equipo Scrums
se pueden formar para trabajar en el proyecto. El proceso Convocar Scrum of Scrum facilita la
coordinación entre los Equipo Scrums lo que permite una aplicación efectiva en los proyectos grandes.
Los proyectos grandes o complejos a menudo se implementan como parte de un Programa o Portafolio.
El método de Scrum también se puede aplicar para gestionar Programas y Portafolios. El enfoque
lógico de las directrices y los principios de este marco pueden utilizarse para gestionar proyectos de
cualquier tamaño, que abarcan distintas geografías y organizaciones. Los proyectos grandes pueden
tener varios Equipos Scrums trabajando de forma paralela por lo que es necesario sincronizarse y
facilitar el flujo de información y mejorar la comunicación.
El proceso Convocar _________ asegura esta sincronización. Los diversos Equipos Scrums están
representados en esta reunión y el objetivo es proporcionar actualizaciones sobre del progreso, discutir
los retos que enfrentan durante el proyecto y coordinar las actividades. No hay reglas fijas en cuanto a
la frecuencia de estas reuniones. Los factores que determinan la frecuencia son el nivel de
dependencia entre los equipos, el tamaño del proyecto, el nivel de complejidad y las recomendaciones
del Cuerpo de Asesoramiento de Scrum.
Programas
En los Programas, los roles principales para la gestión de Scrum son:
1. Product Owner del Programa —define los objetivos y las prioridades estratégicas para el Programa.
2. Scrum Master del Programa —Resuelve problemas, remueve Impedimentos, facilita y lleva a cabo
reuniones para el Programa.
Estas funciones son similares a las del Product Owner y Scrum Master excepto que satisfacen las
necesidades del Programa o unidad de negocio en lugar de las de un sólo Equipo Scrum.
Portafolios
En Portafolios, los roles importantes para la gestión de Scrum son:
1. Product Owner del Portafolio —Define los objetivos estratégicos y las prioridades del Portafolio.
2. Scrum Master del Portafolio —Resuelve problemas, elimina Impedimentos, facilita y lleva a cabo
reuniones para el Portafolio.
© 2016 SCRUMstudy.com 64
La siguiente figura ilustra cómo el método Scrum se puede utilizar en toda la organización para los
Portafolio, Programa o Proyectos.
Los problemas 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 gestiona con cuidado. Las herramientas utilizadas para la comunicación deben ser escaladas
para que coincida con los requisitos de los equipos que participan en un Programa o un 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 interesados del Programa o Portafolio.
© 2016 SCRUMstudy.com 65
Reuniones de Scrum of Scrums (SoS) Scrum of Scrums Meeting
Un Scrum of Scrums (SoS) Meeting es un elemento importante al escalar o ajustar Scrum a proyectos
___________. Por lo general, hay un representante en la reunión de cada uno de los Equipo Scrums.
Por lo general el representante es el Scrum Master, pero también puede asistir cualquier miembro del
Equipo Scrum si es necesario. Esta reunión es usualmente facilitada por el Jefe Scrum Master y su
objetivo es centrarse en las áreas de coordinación e integración entre los diferentes Equipo Scrums.
Tal reunión se lleva a cabo en intervalos predeterminados o cuando lo requieran los Equipo Scrums.
En organizaciones donde hay varios Equipo Scrums trabajando en varias partes de un proyecto de
forma simultánea, SoS se puede escalar a otro nivel, esta se conoce como Scrum of Scrum of Scrums
Meeting. En esta situación, una Reunión SoS mantiene la coordinación de cada grupo de los Equipo
Scrums.
Transición a Scrum
Los dos métodos básicos para hacer la transición a Scrum son de ________________ y
de______________. En el método de arriba hacia abajo, la transición es comunicada en toda la
organización. Existe un esfuerzo por proveer capacitación del cambio a todos los involucrados. Esta
comunicación puede ser fuente de resistencia al cambio. La otra posibilidad es cambiar las cosas
gradualmente dentro de la cultura de la organización. Después, la transición a Scrum será de forma
incremental.
Con una implementación de arriba hacia abajo, podrían haber conflictos de comunicación. Por ejemplo,
un líder de ingeniería implantó Scrum en su organización sin el consentimiento por parte del área de
ventas. Esto llevaría a grandes conflictos con el mismo Product Owner.
Otro aspecto a considerar de la transición es saber el impacto de la transición de la organización a los
métodos Scrum. Toda organización puede hacer la transición al mismo tiempo. Sin embargo, este
método es más susceptible a problemas que pueden resultar en la interrupción de actividades que
generan ganancias. Por lo tanto, es generalmente preferible hacer la transición en diferentes secciones
de forma iterativa para reducir el riesgo y proveer lecciones aprendidas para futuras iteraciones.
© 2016 SCRUMstudy.com 66
Mapeo de Roles tradicionales a Scrum
Los roles tradicionales del gestión de proyecto son divididos en tres roles en Scrum : ___________,
______________ y ________________.
El Product Owner se comunica con los interesados y establece las prioridades del proyecto.
El Scrum Master ejecuta los deberes del jefe de proyecto porque remueve los impedimentos.
El Scrum Master, como el jefe de proyecto, es responsable de asegurar que los procesos
Scrum sean ejecutados adecuadamente.
Los miembros del Equipo también ejecutan algunos roles tradicionales del jefe de proyecto,
dado que ellos se autogestionan y son dueños de su tiempo. Esto permite que el equipo tenga
un sentido de pertenencia para que busque su propio éxito.
Evaluar continuamente los cambios del proyecto que afectan a los interesados para asegurar
que nuevos interesados del proyecto estén comprometidos.
Es importante que los ejecutivos que financian el proyecto tengan claridad respecto a los siguientes
temas:
© 2016 SCRUMstudy.com 67
Capítulo Escalando Scrum - Preguntas
1. ¿Cuál de los siguientes NO es cierto con respecto a la implementación de Scrum para
grandes proyectos?
A. Se requieren varios equipos para trabajar en sincronía.
B. Una Cartera priorizada del producto no es necesaria para monitorear el progreso de todos
los proyectos.
C. Un Jefe Product Owner es necesario para supervisar todos los proyectos.
D. Las tareas pueden no ser interdependientes entre los equipos.
© 2016 SCRUMstudy.com 68