Академический Документы
Профессиональный Документы
Культура Документы
1
INTRODUCCIN
2014 SCRUMstudy.com 1
Acerca de SCRUMstudy
SCRUMstudy es la entidad de certificacin global para las certificaciones Scrum y Agile. Una
gran cantidad de informacin acerca de SCRUMstudy y sus programas de certificacin y
membresa est disponible en SCRUMstudy.com. En la parte inferior se proporciona un
resumen de las certificaciones que otorga SCRUMstudy.
ESMCTM SCTTM
Expert Level Expert Scrum SCRUMstudy
Master
Certified
SDCTM
Foundation Level
Scrum Developer Certified
Esta membresa provee acceso a las principales pginas de informacin, foros de discusin general y
blogs limitados y recursos en lnea. Los candidatos a la certificacin deben tener por lo menos una
Membresa Bsica para poder dar un examen de certificacin de SCRUMstudy.
2014 SCRUMstudy.com 2
RESUMEN DE AGILE
El trmino agile (gil) generalmente se refiere a ser capaz de moverse o responder rpidamente y
fcilmente. En cualquier tipo de disciplina de gestin, ser gil es una cualidad, por lo tanto esto debe
ser una meta que se debe tratar de alcanzar. La gestin de Proyectos Agile especialmente, implica la
adaptabilidad durante la creacin de un Producto, Servicio o cualquier otro Resultado.
Es importante entender que a pesar de que el desarrollo de los mtodos giles es altamente adaptable,
de todos modos es necesario tener en cuenta la estabilidad en sus procesos de adaptacin.
El permiso para copiar fue proporcionado por los autores mencionados mediante aviso en http://agilemanifesto.org/.
2014 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 documentacin extensiva
3. Colaboracin con el Cliente sobre la negociacin contractual
4. Responder ante el cambio en vez de seguir un plan
2. Aceptamos que los requisitos cambien, incluso en etapas tardas del desarrollo. Los
procesos giles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.
12. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para que
como consecuencia procedan a ajustar y perfeccionar su comportamiento.
2014 SCRUMstudy.com 4
Mtodos Agile
Una serie de metodologas giles se crearon y ganaron fuerza en la dcada de 1990 y principios del
2000. Si bien difieren en una variedad de aspectos, lo que tienen en comn se deriva de su adhesin
a The Agile Manifesto.
Los siguientes mtodos giles se discuten brevemente a continuacin:
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 organizacin para producir resultados valiosos sobre
la base de sus recursos, necesidades y alternativas, mientras reduce las prdidas. Las prdidas, por
ejemplo, podran ser la construccin incorrecta de un Producto, el no saber aprender, o las prcticas
que impiden que el proceso fluya. Debido a que estos factores son de naturaleza dinmica, una
organizacin gil evala la totalidad de su sistema y continuamente hace ajustes a sus procesos. El
fundamento de Lean es que la reduccin de la duracin de cada ciclo (es decir, una iteracin) conduce
a un aumento de Productividad mediante la reduccin de los retrasos, ayuda en la deteccin 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 produccin. 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 dcada 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 cdigo, la comunicacin verbal, el diseo en constante evolucin,
Colaboracin cercana y la vinculacin de las unidades, de largo como de corto plazo, de todos los
involucrados.
Crystal Methods
Las metodologas de desarrollo de software Crystal fueron presentadas por Alistair Cockburn a
principios de 1990. Los mtodos Crystal se centran en las personas, son ligeros y fciles 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 caractersticas especficas del Proyecto.
Todos los mtodos de Crystal tienen cuatro roles patrocinador, diseador principal, desarrolladores
y usuario experto. Los mtodos Crystal recomiendan diversas estrategias y tcnicas para lograr
agilidad. Un ciclo de proyectos Crystal consta de grficos, ciclo de entrega y de recapitulacin.
2014 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 trminos 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 categoras: lo que "deben tener",
"deberan tener", "podran tener", y "no tendrn" (mediante la tcnica Priorizacin MoSCoW). DSDM
es un mtodo orientado al sistema con seis distintas fases de pre-proyecto; Viabilidad; Fundamentos;
Exploracin e Ingeniera; Despliegue y Evaluacin de Beneficios.
2014 SCRUMstudy.com 6
Scrum vs Gestin de Proyectos Tradicional
En la tabla se resumen muchas de las diferencias entre los modelos tradicionales de gestin de
proyectos y Scrum.
Gestin de Proyectos
Enfoque Scrum
Tradicional
2014 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 correccin a medida que todas las
personas involucradas obtengan una mejor comprensin 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
2014 SCRUMstudy.com 8
Captulo Visin de Agile y Scrum - Preguntas
1. Cul de las siguientes NO es una caracterstica comn de la gestin adaptativa de
proyectos?
A. Desarrollo iterativo del producto
B. Alto esfuerzo en la planificacin adelantada (al inicio del proyecto)
C. Reduce el tiempo de lanzamiento al mercado
D. Entrega del producto flexible
2014 SCRUMstudy.com 9
INFORMACIN GENERAL DE SCRUM
Scrum es una de las metodologas giles ms populares. Emplea un enfoque adaptativo e iterativo
para gestionar proyectos y desarrollo de productos. Ha sido diseada para ser una manera rpida,
flexible y eficaz para ofrecer _____ significativo de forma _________ en todo el proyecto.
El marco de Scrum, tal como se define en la Gua SBOK, puede ser mejor entendido a travs de sus
principios, procesos y aspectos.
Principios Scrum
1. Control del Proceso Emprico Scrum establece que la toma de decisiones basada en la
observacin y experimentacin es mejor que la planificacin detallada al inicio del proyecto.
2. Auto-organizacin 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 ms propicio para el crecimiento.
3. Colaboracin Este principio se centra en las tres dimensiones bsicas relacionadas con el
trabajo colaborativo: conciencia, articulacin y apropiacin.
4. Priorizacin basada en el valor Este principio pone de relieve el enfoque de Scrum para
ofrecer el mximo valor de negocio, desde el principio del proyecto hasta su conclusin.
2014 SCRUMstudy.com 10
5. Time-boxing Este principio describe cmo el tiempo es considerado como una restriccin
limitante en Scrum, y cmo se utiliza para ayudar a manejar eficazmente la planificacin y
ejecucin del proyecto.
6. Desarrollo Iterativo Este principio define el desarrollo iterativo y enfatiza cmo manejar
mejor los cambios y crear productos que satisfagan las necesidades del Cliente. Tambin
delinea las responsabilidades del Product Owner y de la organizacin 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 mtodo predictivo de desarrrollo
no puede manejar tales cambios. En cambio, Scrum es especialmente til para proyectos complejos
con gran ____________ en los cuales los pronsticos de largo plazo podran conllevar a riesgos
crticos.
Scrum gua a travs de la transparencia, inspeccin y adaptacin para alcanzar los resultados ms
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. Organizacin
2. Justificacin de Negocio
3. Calidad
4. Cambio
5. Riesgo
2014 SCRUMstudy.com 11
Procesos de Scrum
Los procesos de Scrum abordan las actividades y el flujo especfico de un proyecto Scrum. En total
hay diecinueve procesos que se agrupan en cinco fases.
2014 SCRUMstudy.com 12
El trmino "Producto" en la Gua SBOK puede referirse a un Producto o, Servicio, o cualquier otra
prestacin. Scrum se puede aplicar de manera efectiva a cualquier proyecto en cualquier industria-
desde proyectos pequeos o equipos con tan slo seis miembros, hasta proyectos grandes y complejos
con varios cientos de miembros por equipo.
2014 SCRUMstudy.com 13
Por qu utilizar Scrum?*
Algunas de las ventajas principales de la utilizacin de Scrum en cualquier proyecto son:
1. ______________ El Control del Proceso Emprico y la Entrega Iterativa hacen que los
proyectos sean adaptables y abiertos a la incorporacin de cambios.
2. ______________ Todos los radiadores de informacin tales como el Scrumboard y el Sprint
Burndown Chart son compartidos, lo que promueve un ambiente de trabajo abierto.
3. _________________ Continua Se proporciona a travs de los procesos: Ejecutar
Reuniones Diarias y Demostrar y Validar.
4. ___________ Continua Los entregables se mejoran progresivamente Sprint por Sprint a
travs del proceso de Mantenimiento del Product Backlog.
5. Entrega Continua de Valorlos procesos iterativos permiten la entrega continua de valor tan
frecuentemente como el Cliente lo requiere a travs del proceso Enviar los Entregables.
6. Ritmo Sostenible Los procesos Scrum estn diseados de tal manera que las personas
involucradas pueden trabajar a un mismo ritmo que, en teora, se puede continuar
indefinidamente.
7. Entrega Temprana de Alto ValorEl 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 reduccin al mnimo el trabajo que no
es esencial conduce a mayores niveles de eficiencia.
9. MotivacinLos procesos de Ejecutar la Reunin Diaria y la Retrospectiva del Sprint
conducen a mayores niveles de motivacin entre los empleados.
10. Resolucin de Problemas de forma ms Rpida Colaboracin y la coubicacin de equipos
multi-funcionales conducen a la resolucin de problemas con mayor rapidez.
11. Entregables EfectivosEl procesos de Crear el Product Backlog Priorizado y revisiones
peridicas despus de la creacin 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
colaboracin con los interesados asegura un marco orientado al Cliente.
13. Entorno de Alta ConfianzaLos procesos de Ejecutar la Reunin Diaria y la Retrospectiva
del Sprint promueven transparencia y colaboracin, dando lugar a un ambiente de trabajo de
alta confianza, asegurando as una baja friccin entre los empleados.
14. Responsabilidad ColectivaEl 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 VelocidadUn marco de colaboracin que le permite a los equipos multi-funcionales
altamente calificados alcanzar su potencial y alta velocidad.
16. Medio Ambiente InnovadorLos procesos Retrospectiva del Sprint y Retrospectiva del
Proyecto crean un ambiente de introspeccin, aprendizaje y capacidad de adaptacin que lleva
a un entorno de trabajo innovador y creativo.
2014 SCRUMstudy.com 14
Captulo Visin General Agile y Scrum - Preguntas
1. El control del proceso emprico es un principio de Scrum que:
A. Es utilizado en casos en los que las entradas estn claramente definidas.
B. Se centra en proporcionar control a travs de inspecciones y adaptaciones frecuentes de
los procesos que estn 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 especfica.
2. Todos los siguientes son parte de los principios del Scrum EXCEPTO:
A. La auto-organizacin
B. Time-boxing
C. Priorizacin basada en valor
D. Control de procesos definidos
2014 SCRUMstudy.com 15
LOS ROLES DE SCRUM
Core RolesLos Core Roles son las funciones que obligatoriamente se requieren para producir
el producto o servicio del proyecto, estos estn ____________ con el proyecto, y son los
responsables del xito de cada Sprint y del proyecto en su totalidad.
Non-core Roles: son las funciones que no son obligatoriamente necesarias para el proyecto
Scrum, y pueden incluir miembros de los equipos que estn interesados en el proyecto, pero no
tienen ningn 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 tambin deben tenerse en
cuenta en cualquier proyecto de Scrum.
Core Roles
Hay tres Core Roles (roles/funciones principales) en Scrum que son los responsables de cumplir con
los objetivos del proyecto. Los core roles 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.
2014 SCRUMstudy.com 16
Core Role: Product Owner (Dueo del Producto)
El Product Owner representa a los interesados y es responsable de asegurar que el Equipo Scrum
entregue valor, a travs 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;
tambin gestiona el Product Backlog (cartera de pendientes) en el proceso Priorizar el Product Backlog.
En algunos casos, los miembros del Equipo Scrum podran escribir las User Stories (Historias de
Usuario) bajo la supervisin del Product Owner. El Product Owner es tambin responsable de asegurar
la comunicacin clara de las funcionalidades del producto al Equipo Scrum, por lo que tambin es
conocido como la ___________________.
De la misma forma que existe un rol de Product Owner en un proyecto, podra haber un Product Owner
del Programa en un Programa, o un Product Owner del Portafolio en un Portafolio.
2014 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
2014 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 gestin 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 lderes 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, podra 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.
2014 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 creacin del Product Backlog
Backlog Priorizado y en la definicin de los Criterios de Terminado
Approve, Estimate and Facilita reuniones del Equipo Scrum para estimar y Crear
Commit User Stories Historias de Usuarios
2014 SCRUMstudy.com 20
Core Role: Scrum Team- Equipo Scrum
El Equipo Scrum es un grupo o equipo de personas que son responsables de la comprensin de los
requerimientos de negocio especificados por el Product Owner, de la estimacin de Historias de
Usuarios y de la creacin de los _________________ del proyecto.
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 microgestin de las tareas llevadas a cabo por un jefe.
Multi-funcionales:
Este modelo de equipo en Scrum est diseada para optimizar la flexibilidad y la productividad.
Un equipo coubicado conformado por expertos funcionales que colaboran para alcanzar un
objetivo comn tendr mayor probabilidad de xito que un equipo que trabaja separado
fsicamente de acuerdo a la funcin que realiza.
Cuando un Equipo Scrum necesita ser distribuido, el Scrum Master debe garantizar que las
tcnicas de comunicacin eficaces estn 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.
2014 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 duracin del
Sprint.
Conduct Release Planning Solicita aclaracin de los nuevos productos o cambios al producto
existente en el Product Backlog Priorizado y Refinado.
Crea Entregables.
Identifica riesgos e implementa acciones de mitigacin a los riesgos si
Create Deliverables es necesario.
Actualiza el Registro de Impedimentos y sus dependencias.
Actualiza el grfico 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 aprobacin.
2014 SCRUMstudy.com 22
Etapas de Desarrollo de Equipos
El mtodo de Scrum inicialmente pueden parecer muy diferente y difcil para un nuevo Equipo Scrum.
Un nuevo Equipo Scrum, al igual que cualquier otro equipo nuevo, por lo general se desenvuelve a
travs de un proceso de cuatro etapas. Este proceso se conoce como Modelo de Dinmica 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 an 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 confusin 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 (Desempeo) Durante esta etapa, el equipo est unido y opera en su nivel ms alto en
trminos de rendimiento. Los miembros se han convertido en un equipo eficiente de
profesionales que son consistentemente productivos.
2014 SCRUMstudy.com 23
Seleccin 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. Ms 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 colaboracin.
Cuando se selecciona el equipo, un aspecto importante es crear _________ para cada miembro del
equipo. Esto asegura evitar que haya una disminucin importante de la productividad debido a la
prdida de miembros crticos.
Es un trmino colectivo que incluye a los Clientes, los usuarios y patrocinadores, que a menudo
interactan con el Product Owner, Scrum Master y Equipo Scrum para proporcionarles
informacin y para ayudar en la creacin del producto, servicio, o cualquier otro resultado del
proyecto. Los interesados influyen en el proyecto a lo largo del desarrollo del proyecto.
Tambin pueden desempear un papel en los procesos importantes de Scrum tales como:
Desarrollo de Epic(s), Crear Product Backlog Priorizados, Ejecutar la Planificacin de la
Entrega, Retrospectiva del Sprint.
2014 SCRUMstudy.com 24
Cliente
El Cliente es la persona o la organizacin que adquiere el producto, servicio, o cualquier otro
resultado del proyecto. Para cualquier organizacin, dependiendo del proyecto, pueden haber
Clientes internos (es decir, dentro de la misma organizacin) o Clientes externos (es decir,
fuera de la organizacin).
Usuarios
Patrocinador
El patrocinador es la persona o la organizacin que provee recursos y apoyo para el proyecto.
El patrocinador es tambin el interesado, a quien todos le deben rendir cuentas al final.
A veces, la misma persona u organizacin pueden desempear mltiples funciones el
interesado, por ejemplo, el patrocinador y el cliente puede ser el mismo.
2014 SCRUMstudy.com 25
Captulo 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)
2014 SCRUMstudy.com 26
6. Las ventajas de utilizar un equipo multi-funcional son:
A. Scrum Master
B. Product Owner
C. Lder 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. Lder Equipo Scrum
D. Equipo Scrum
2014 SCRUMstudy.com 27
FASES SCRUM
La figura a continuacin proporciona una visin general del flujo de un proyecto Scrum.
El ciclo de Scrum comienza con la Fase de Inicio, durante la cual se determina la Visin 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 Reunin de
Planificacin del Sprint (Sprint Planning Meeting) durante la cual son escogidas las tareas (los
elementos con prioridad alta del Product Backlog) para el Sprint prximo a comenzar.
Un Sprint suele durar entre ________ semanas en el cual el Equipo Scrum trabaja en la
elaboracin 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 estn afrotando.
Al final del Sprint, se lleva a cabo una reunin de revisin del Sprint (Sprint Review Meeting) en el
cual se le presenta una demostracin 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 Reunin de la Retrospectiva del Sprint (Retrospect Sprint
Meeting).
2014 SCRUMstudy.com 28
Fase Procesos
2014 SCRUMstudy.com 29
FASE: INICIAR
La primera fase de mtodo Scrum es la fase Iniciar. Los procesos relacionados con la iniciacin de un
proyecto son los siguientes:Crear la Visin 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 Planificacin de las Entregas (Release).
2014 SCRUMstudy.com 30
Reunin de la Visin del Proyecto
Reunin de la Visin del Proyecto es una reunin 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
Declaracin de la Visin del Proyecto eficaz. Scrum cree en la participacin y colaboracin cercana
con todos los representantes de las compaa para que estn 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 mximo empresarial para el Proyecto. l o ella tambin es responsable
de la articulacin de requisitos por parte de los Clientes y de mantener la Justificacin de Negocio para
el Proyecto. El Product Owner representa la voz del Cliente.
Cada Equipo Scrum tendr un Product Owner designado. Un pequeo Proyecto puede tener slo un
Product Owner, mientras que los Proyectos ms grandes pueden tener varios. Estos Product Owners
son responsables de la gestin del Product Backlog Priorizado. Ellos escriben los Historias de Usuarios
y gestionan el mantenimiento del Product Backlog.
El resultado clave del proceso Crear la Visin del Producto es la Declaracin de la Visin del Proyecto.
Una buena visin del Proyecto explica la necesidad del negocio y que es lo que el Proyecto tiene como
objetivo satisfacer, en lugar de cmo se va a satisfacer la necesidad.
El Declaracin de la Visin del Proyecto no debera ser muy especfico 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 visin del Proyecto sea lo suficientemente
flexible como para adaptarse a estos cambios. La visin del Proyecto debe centrarse en el problema y
no en la solucin.
2014 SCRUMstudy.com 31
Proceso 2: Identificar al Scrum Master y a los Interesados
Un proyecto Scrum empieza cuando una necesidad de negocio y la visin son identificadas; entonces
se puede continuar con la identificacin de los interesados del proyecto tales como el patrocinador,
usuarios finales, proveedores, etc, quienes estarn impactados por la necesidad de negocio o
ayudarn a llevarla a cabo. Por lo tanto, una vez que la Visin 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 Visin 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 resolucin de conflictos, que encarne el estilo de gestin : ______________, y que se
comprometa a brindar al Equipo Scrum un ambiente propicio para la entrega exitosa del proyecto.
Criterios de seleccin
La seleccin adecuada del Scrum Master y la identificacin 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 eleccin del Scrum Master, se deben considerar los siguientes criterios
de seleccin:
2014 SCRUMstudy.com 32
1. Habilidades para la resolucin de problemasEs 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. DisponibilidadEl 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. CompromisoEl 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. Lder Servicial
En la identificacin de los Interesados es importante recordar que los Interesados incluyen a todos los
clientes, los usuarios y patrocinadores, quienes a menudo interactan con el Product Owner, Scrum
Master y Equipo Scrum para proveer entradas y facilitar la creacin 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 Lder Servicial que se asegura de que el Equipo Scrum est dotado
de un ambiente propicio para completar el Proyecto con xito. El Scrum Master gua, facilita y ensea
prcticas de Scrum a todos los involucrados en el Proyecto; elimina impedimentos que encara el
equipo; y asegura que se estn siguiendo los procesos de Scrum. Es la responsabilidad del Product
Owner identificar al Scrum Master para un proyecto Scrum.
Interesados Identificados
Los interesados, trmino colectivo que incluye a los Clientes, los usuarios y los patrocinadores, quienes
con frecuencia interactan con el Equipo Core Scrum, influyen en el Proyecto durante todo el proceso
de desarrollo de Productos.
2014 SCRUMstudy.com 33
Proceso 3: Formar el Equipo Scrum
Form Scrum Team
Uno de los procesos ms importantes en el flujo Scrum es la formacin del Equipo Scrum, porque ste
es el que crea los entregables del proyecto, y con estos se logra satisfacer la Visin del Proyecto.
El Equipo Scrum es tambin 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. Ms
all de ser expertos tcnicos, 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 Visin del Proyecto porque el tipo de proyecto y el tipo de industria son
factores cruciales en la seleccin de expertos tcnicos. Sin embargo el Product Owner y el Scrum
Master podra 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 ms 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 colaboracin. El equipo debe ser capaz de fomentar un
ambiente de reflexin independiente y de tomar decisiones con el fin de extraer los mayores beneficios
de la estructura.
2014 SCRUMstudy.com 34
Objetivos de un equipo auto-organizado
2014 SCRUMstudy.com 35
1. Scrum Core Team* 1. Reunin de Grupo de 1. Epic(s) *
2. Declaracin de la Visin 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. Reunin de Grupos de
5. Solicitudes de Cambio Opinin (Focus Group)
Aprobadas 4. Entrevista a Usuarios o
6. Solicitud de Cambio no Clientes
Aprobadas 5. Cuestionarios
7. Riesgos del Portafolio y del 6. Tcnicas de Identificacin
Programa
de Riesgos
8. Leyes y Regulaciones
9. Contractos 7. Juicio Experto del Cuerpo
10. Informacin Previa del de Asesoramiento de
Proyecto Scrum
11. Recomendaciones del
Cuerpo de Asesoramiento
de Scrum
La Reunin de Grupo de Usuarios involucre a los interesados del proyecto, principalmente los usuarios
o Clientes del Producto. Ellos proporcionan al Equipo Core de Scrum informacin de primera mano
acerca de las expectativas del usuario. Esto ayuda en la formulacin de los Criterios de Aceptacin
para el Producto y proporciona informacin valiosa para el desarrollo de Epics.
Creacin de una Persona
Esto implica la asignacin al personaje de un nombre ficticio y preferentemente una foto. A la Persona
se le incluirn atributos muy especficos como su edad, gnero, nivel de educacin, entorno, intereses
y metas. Una cita que ilustra las necesidades de la persona puede ser incluida tambin. A continuacin
se muestra un ejemplo de una Persona para un sitio web de viajes.
2014 SCRUMstudy.com 36
Proceso 5: Crear la Lista de Requerimientos Pendientes del Producto
2014 SCRUMstudy.com 37
1. Scrum Core Team* 1. Mtodos de Priorizacin 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. Declaracin de la Visin del (Done Criteria)*
Proyecto 3. Planificacin de Valor
6. Product Backlog del 4. Tcnicas de Evaluacin de
Programa Riesgo
7. Requisitos del Negocio 5. Estimacin de Valor del
8. Solicitudes de Cambio Proyecto
Aprobadas 6. Mtodos de Estimacin 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
2014 SCRUMstudy.com 38
Esquema de Priorizacin MoSCoWEl esquema de priorizacin MoSCoW deriva su nombre
de las primeras letras de las frases "Must have" (Debe tener), Should have (Debera tener),
"Could have (Podra tener), y "Would like to have, but not at this time (Quisiera tenerlo, pero
no ahora). Las etiquetas estn 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 sera
bueno tenerlas, no es necesario incluirlas.
Comparacin por Pares (Paired Comparison) En esta tcnica 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 decisin
sobre cul de los dos es ms importante. A travs de este proceso, se puede obtener una lista
priorizada de las Historias de Usuarios.
Mtodo 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 ms importantes. El objetivo es dar ms peso a las Historias de Usuarios
que son de mayor prioridad en comparacin con las otras Historias de Usuarios disponibles.
Cada miembro del grupo asigna puntos a las diversas Historias de Usuarios, dando ms puntos
a aquellas que consideran ms importantes. Al finalizar el proceso de votacin, la Priorizacin
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 definicin clara de
Done es crtica, ya que elimina la ambigedad de los requisitos y ayuda a que el equipo se adhiera a
las normas de calidad obligatorias. Esta definicin 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 Aceptacin de
la Historia del Usuario.
2014 SCRUMstudy.com 39
Proceso 6: Realizar la Planificacin de los Entregables
2014 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.
2014 SCRUMstudy.com 41
El formato de una Historia de Usuario es el siguiente:
Como <rol del usuario> deseo <descripcin del requerimientos> para <beneficio>.
Junto con las Historias de Usuario, el Equipo Core Scrum escribe los Criterios de Aceptacin. Las
Historias de Usuario son a veces subjetivas, por lo que los Criterios de Aceptacin brinda la objetividad
requerida para las Historias de Usuario para ser consideradas como Terminadas o no Terminadas
durante la Revisin de un Sprint.
Los Criterios de Aceptacin ayudan al equipo a entender qu se espera de una Historia de Usuario,
eliminan la ambigedad 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
Aceptacin 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 Aceptacin de una Historia de Usuario, mientras este se
est ejecutando, que ya est comprometida a un Sprint,.
.
2014 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 tcnica de estimacin grupal para determinar cunto trabajo est involucrado y cunto
tiempo tomar completarlo. Los participantes de forma annima 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 estimacin. Este proceso se repite hasta que el estimado de los participantes
2014 SCRUMstudy.com 43
converja y se llegue a un consenso en el estimado final. La informacin de cada participantes se
recolecta de forma que se evite el problema de pensamiento de grupo (group think).
Planificacin Poker (Planning Poker)
Tambin llamada Estimacin Poker, es una forma de aplicar Wideband Delphi. Es una tcnica de
estimacin donde se utiliza el consenso para estimar tamaos relativos de Historias de Usuario o
el esfuerzo requerido para crearlos.
En Planificacin Poker, a cada miembro se le asigna una baraja de cartas, cada carta est
numerada en una secuencia. Estos nmeros representan la complejidad del problema, en
trminos 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 evalan la Historia
de Usuario y tratan de entenderla mejor antes de dar su estimacin para desarrollarla. Entonces
cada miembro elige una carta de la baraja que represente su estimado para la Historia de Usuario.
Si la mayora o todos los miembros del equipo eligen la misma carta, entonces esta ser la
estimacin 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. Despus de la
discusin, 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 estimacin. La Planificacin Poker promueve la interaccin entre los participantes y mejora la
comunicacin. Tambin permite el pensamiento independiente de los participantes evitando el
fenmeno de pensamiento de grupo.
2014 SCRUMstudy.com 44
El nmero de dedos usados para votar indica cun de acuerdo est el participante con el tema
propuesto y si tiene observaciones que desea discutir con el grupo:
Un dedo: Estoy en desacuerdo con la conclusin del grupo y tengo preocupaciones
importantes que deseo revisarlas con el grupo.
Dos dedos: Estoy en desacuerdo con la conclusin del grupo y quisiera revisar con el
grupo algunas preocupaciones menores.
Tres dedos: No estoy seguro pero elijo estar de acuerdo con la conclusin del grupo.
Cuatro dedos: Estoy de acuerdo con la conclusin del grupo y quisiera discutir algunos
temas menores.
Cinco dedos: Estoy totalmente de acuerdo con la conclusin del grupo.
Estimacin Relativa / Puntos de Historia (Relative Sizing / Story Points)
Adems de ser utilizada para la estimacin de costos, los story points pueden tambin servir para
la estimacin de toda una Historia de Usuario o funcionalidad. Este enfoque asigna un valor de
Story Point basado en una evaluacin completa del tamao de la Historia de Usuario considerando
el riesgo, el esfuerzo requerido y el nivel de complejidad. Esta evaluacin ser llevada a cabo por
el Equipo Scrum y un valor de story point ser asignado. Una vez que la evaluacin de una Historia
de Usuario del Product Backlog Priorizada es efectuada, el Equipo Scrum puede evaluar las otras
Historias de Usuario de forma relativa considerando la primera historia.
Por ejemplo, una funcionalidad que tiene asignada 2 story point debe tener el doble de dificultad
que una funcionalidad que tiene asignada 1 story point; una que tenga 3 story point debe tener el
triple de dificultad que una con 1 story point.
2014 SCRUMstudy.com 45
Proceso 3: Crear Tareas
Crear Tasks
En las fases iniciales donde se ponen por escrito los requerimientos, la mayora de las Historias de
Usuario recaban informacin de funcionalidades de alto nivel, por lo que stas tienen que ser
desglosadas en __________ realizables y simples.
Reunin de Planificacin de Tareas (Task Planning Meeting)
Como parte de esta reunin, los miembros del Equipo Scrum revisan las Historias de Usuario
Comprometidas a detalle para eliminar ambigedades resolver todas las preguntas. Aunque no es
mandatoria la presencia del Product Owner en esta reunin, es importante su participacin porque
ayudar al Equipo Scrum a entender mejor las Historias de Usuario, lo que har que la reunin sea
ms eficiente. La creacin de tareas se realiza durante la Reunin de Planificacin de Tareas. Esta
reunin est dividida en dos partes:
El Product Owner sugiere Historias de Usuario que deben formar parte del
Sprint.
El Equipo Scrum determina cuntas Historias de Usuario pueden ser
Primera ejecutadas en un Sprint.
Se alcanza consenso en las Historias de Usuario de sern includas en el Sprint.
Parte
2014 SCRUMstudy.com 46
1. Scrum Core Team* 1. Reunin de Planificacin 1. Lista de Tareas *
2. Historias de Usuario de Tareas* 2. Historias de Usuarios
Aprobadas, Estimadas y 2. Tarjetas Aprobadas, Estimadas,
Comprometidas * 3. Descomposicin Comprometidas y
4. Determinacin de Actualizadas
Dependencias 3. Dependencies
2014 SCRUMstudy.com 47
El Tiempo Ideal (Ideal Time) normalmente describe el nmero 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 estn 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 estndar contiene 4 columnas que indican el progreso de las treas estimadas
para el Sprint: la columna Pendiente (To Do) para las tareas que an no empiezan, la columna
En Progreso (In Progress) para tareas que empezaron pero no han sido completadas an, 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.
2014 SCRUMstudy.com 48
La siguiente figura muestra un ejemplo de un Scrumboard:
Las principales salidas de este son el Sprint Backlog y el Grfico 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 prximo Sprint. Es una prctica comn que el Sprint Backlog se muestre en
un Scrumboard o tablero de tareas, este proporciona una representacin visible y constante de la
situacin de las Historias de Usuarios en el backlog. Tambin se incluyen en el Sprint Backlog
algunos Riesgos asociados con las diversas tareas. Las actividades de mitigacin a los riesgos
identificados podran 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 aadirse nuevas Historias de Usuarios; sin embargo, puede ser necesario aadir
las tareas que pueden haberse pasado por alto o ignorado. Si surgen nuevas necesidades durante
un Sprint, se aadirn al Product Backlog Priorizado y se incluirn en un Sprint posterior.
2. Sprint Burndown Chart Es un grfico que muestra la cantidad de trabajo que queda por hacer
en el Sprint actual. El Grfico Sprint Burndown inicial es acompaado por un Burndown planeado.
El Grfico Sprint Burndown debe actualizarse al final de cada da laborable.
La siguiente figura muestra un ejemplo del Sprint Burndown Chart:
2014 SCRUMstudy.com 49
Este grfico muestra el trabajo estimado pendiente (en el eje Y) y el tiempo (en el eje X).
Al final del da, los miembros del Equipo Scrum actualizan el grfico con el trabajo
completado.
2014 SCRUMstudy.com 50
FASE: IMPLEMENTAR
La fase de Implementar abarca las ejecucin de las tareas y actividades para crear el producto, servicio
o resultado del proyecto. Estas actividades incluyen la creacin de varios entregables, llevar a cabo la
Reunin 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 decisin de cmo 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 tcnicos y de gestin del proyecto durante este
proceso.
La salida ms importante de este proceso es el entregable del Sprint, tambin conocido como el
_______________, el cual satisface todas las caractersticas y funcionalidades definidas en las
Historias de Usuario del Sprint. Si los miembros del Equipo Scrum enfrentan cualquier obstculo
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
podra ser intil sin hacer estas modificaciones, entonces el actual Sprint debera ser terminado, y un
nuevo Sprint que incorpora el cambio debe ser iniciado. Caso contrario, el cambio ser incluido en un
Sprint posterior.
2014 SCRUMstudy.com 51
PROCESO 2: REALIZAR LA REUNIN DIARIA
Aparte de la colaboracin, 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 slo es un facilitador, no dirige la reunin. El Daily Standup Meeting
solo es un foro de intercambio de informacin. Cualquier discusin sobre la resolucin de un problema,
si es necesaria, se realiza despus de la reunin diaria. El Scrum Master recolecta informacin de los
impedimentos que los miembros del Equipo Scrum estn enfrentando al realizar los trabajos del Sprint
y los resuelve despus de la reunin.
2014 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 estn 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 aadir 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 estimacin. Tambin permite que el desarrollo sea ms
flexible porque se podr incorporar requerimientos recientes tcnicos y de negocio en el siguiente
Sprint. De acuerdo a la informacn 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 restriccin de tiempo (timebox). Este proceso
es una tarea permanente del Product Owner.
2014 SCRUMstudy.com 53
FASE: REVISIN Y RETROSPECTIVA
La fase Revisin y Retrospectiva se ocupa de la revisin de los entregables y del trabajo que se ha
hecho, y determina las mejores prcticas y mtodos utilizados para hacer el trabajo relacionado al
proyecto. En las grandes organizaciones, el proceso de Revisin y Retrospectiva puede incluir la
convocatoria de Reunin de Scrum de Scrums.
5. Impediment Log
6. Dependencias
7. Salidas de la Retrospectiva
del Sprint
2014 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 especficas:
1) En qu ha estado trabajando mi equipo desde la ltima reunin?
2) Qu va a hacer mi equipo hasta la prxima reunin?
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 coordinacin entre varios equipos
trabajando en el mismo proyecto.
2014 SCRUMstudy.com 55
Proceso 3: Retrospectiva del Sprint
Retrospect Sprint
Luego de la Reunin de Revisin del Sprint (Sprint Review Meeting) el Equipo Scrum se rene en la
Reunin de Retrospectiva del Sprint (Retrospect Sprint Meeting). Esta es una oportunidad para que el
Equipo Scrum se tome un momento para mirs hacia atrs 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, tambin puede definir
elementos no funcionales para el Product Backlog Prioritizado.
En la Reunin de Retrospectiva del Sprint (Retrospect Sprint Meeting) participan el Scrum Master y los
miembros del Equipo Scrum. El Product Owner podra 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 cmo se podran direccionar estos
temas. El Equipo identifica mejoras potenciales en la forma de trabajo y tambin sugiere mejoras en la
definicin de Done basndose en su experiencia.
Para llevar a cabo una reunin efectiva de Retrospectiva, el evento puede tener estos 5 pasos:
Set the Stage (Preparar el ambiente): Se le da la bienvenida al equipo, se establece un
consenso sobre el propsito de la reunin y se evala la predisposicin de los asistentes
para participar activamente.
Gather data (Obtener informacin): El equipo comparte informacin 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 ms 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 raz de los problemas.
2014 SCRUMstudy.com 56
Action (Accin): El equipo descubre la solucin para mejorar el trabajo que se viene
haciendo y para reducir o prevenir errores.
Circle of questions and Closing (Crculo 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 realizarn en el siguiente Sprint. Finalmente, los miembros
del equipo se agradecen entre si y se cierra la reunin.
La informacin, opiniones, discusiones y los puntos acordados que son expuestos en la Reunin
de Retrospectiva del Sprint (Retrospect Sprint Meeting) son registradas en el Retrospect Sprint Log.
2014 SCRUMstudy.com 57
Fase: Lanzamiento
La fase de lanzamiento (release) destaca la entrega de los Entregables Aceptados al Cliente y la
identificacin, documentacin e internalizacin de las lecciones aprendidas del proyecto.
Ship Deliverables
Despus que el Product Owner valida los ____________ del Sprint basndose en los Criterios de
Aceptacin y de Terminado, los Entregables Aceptados estn listos para la entrega o lanzamiento a
los Interesados. Sin embargo, no todos los Sprints terminan en un lanzamiento. La decisin de cundo
la entrega es un incremento de producto potencialmente comercializable para los interesados es hecha
en el proceso Conduct Release Planning.
El Cronograma de Planificacin de Entrega (Release Planning Schedule) documenta qu entregables
sern liberados y cundo. De este modo, las entradas principales para este proceso son los
Entregables Aceptados y el Cronograma de Planificacin de Entrega.
Los entregables son lanzados utilizando los Mtodos de Despliegue de la Organizacin. Cada
organizacin tiene sus propios Mtodos de Despliegue. Estos guan cmo y cundo los entregables
sern liberados a los interesados. Las principales salidas de este proceso son los Entregables
Trabajados, Acuerdos de Entregables Trabajados y Lanzamientos de Producto.
2014 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. Despus 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 reunin 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 colaboracin y eficiencia del equipo, tambin identifica
mejoras para toda la implementacin Scrum. Las sugerencias, opiniones y conocimientos obtenidos
en la reunin de Retrospectiva del Proyecto son registrados para referencias futuras.
2014 SCRUMstudy.com 59
Captulo 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 grfico Burndown.
D. Aceptado entregables.
6. Cul de los siguientes NO es una entrada para el proceso de Envo de Entregables (Ship
Deliverables)?
A. Entregables Aceptados
B. Crnonograma de Planificacin de Entregas
C. Product Owner
D. Impediment Log
2014 SCRUMstudy.com 60
8. Cul de las siguientes herramientas es utilizada por el Equipo Scrum para estimar en el
proceso de Estimacin 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 histrica del equipo que se utiliza como un indicador en la asignacin de tareas
para cada Sprint.
C. La velocidad del equipo es independiente de la composicin del equipo.
D. La velocidad del equipo se utiliza en la decisin de los plazos de entrega.
10. Cul de los siguientes no es discutido en una reunin Standup diaria (Daily Standup
Meeting)?
A. Lo que el miembro del equipo ha avanzado desde la ltima reunin
B. Lo que el miembro del equipo tiene previsto trabajar hasta la prxima reunin
C. Lo que el miembro del equipo ha aprendido al completar su trabajo
D. Las barreras que el miembro del equipo enfrenta
11. Cul es la duracin normal de una reunin Standup diaria (Daily Standup Meeting)?
A. 5 minutos
B. 1 hora
C. 15 minutos
D. Reuniones de stands-up no tienen lmite 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 reunin en la que el equipo discute las tareas a realizar en el prximo Sprint es conocido
como la:
A. Reunin de Visin de Producto (Product Vision Meeting).
B. Reunin de Planificacin del Sprint (Sprint Planning Meeting).
C. Reunin de Revisin de Sprint (Sprint Review Meeting).
D. Reunin de Restrospectiva del Sprint (Retrospect Sprint Meeting).
2014 SCRUMstudy.com 61
15. La reunin al final del Sprint en el que el equipo presenta su trabajo al Product Owner es
conocido como la:
A. Reunin de Visin de Producto (Product Vision Meeting).
B. Reunin de Planificacin del Sprint (Sprint Planning Meeting).
C. Reunin de Revisin de Sprint (Sprint Review Meeting).
D. Reunin de Restrospectiva del Sprint (Retrospect Sprint Meeting).
16. La reunin en la que el equipo analiza el Sprint anterior e identifica mejoras potenciales
en los procesos se conoce como la:
A. Reunin de Visin de Producto (Product Vision Meeting).
B. Reunin de Planificacin del Sprint (Sprint Planning Meeting).
C. Reunin de Revisin de Sprint (Sprint Review Meeting).
D. Reunin de Restrospectiva del Sprint (Retrospect Sprint Meeting).
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 tcnicos y de negocio se agregan al siguiente Sprint.
C. El mantenimiento del Product Backlog priorizado asegura tenerlo refinado antes de la
reunin de planificacin de Sprint para que el equipo tiene una mejor idea de los requisitos
antes de la reunin.
D.Todas las anteriores.
21. Cul de las siguientes actividades se pueden realizar en conjunto durante la reunin de
planificacin del Sprint (Sprint Planning Meeting)?
A. Estimacin Tareas y Planificacin de Entregas
B. Mantenimiento de la Pila de Producto y Planificacin de Tareas
C. Planificacin de Tareas y Tareas de Estimacin
D. Planificacin de Entregas y Mantenimiento de la Pila de Producto
2014 SCRUMstudy.com 62
22. Cul de las siguientes no es parte de la reunin de planificacin de Sprint?
A. El Product Owner, explica los principales elementos de la Pila de Producto priorizada para
el equipo.
B. El Equipo Scrum, en colaboracin 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 prximo Sprint.
D. El equipo recibe la retroalimentacin 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 situacin para que revise la situacin con el gerente
general.
E. No realizar ninguna accin porque ya est ocupado.
24. Para cualquier Sprint en curso, cundo 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 aadidas al Sprint
26. En cul de los siguientes procesos de la fase Iniciar se determina la duracin del Sprint?
A. Crear Visin del Proyecto
B. Desarrollar Epics
C. Crear la Pila de Producto Priorizada
D. Realizar la Planificacin de las Entregas (Conduct Release Planning)
2014 SCRUMstudy.com 63
ESCALANDO SCRUM
Escalabilidad de Scrum
Para ser eficaz, los Equipo Scrums deben tener idealmente de seis a diez miembros. Esta prctica
podra llevar a la idea errnea de que el mtodo de Scrum slo se puede utilizar para proyectos
pequeos. Sin embargo, se puede escalar fcilmente para el uso eficaz en proyectos grandes. En
situaciones donde el tamao del Equipo Scrum excede los diez miembros, mltiples Equipo Scrums
se pueden formar para trabajar en el proyecto. El proceso Convocar Scrum of Scrum facilita la
coordinacin entre los Equipo Scrums lo que permite una aplicacin efectiva en los proyectos grandes.
Los proyectos grandes o complejos a menudo se implementan como parte de un Programa o Portafolio.
El mtodo de Scrum tambin se puede aplicar para gestionar Programas y Portafolios. El enfoque
lgico de las directrices y los principios de este marco pueden utilizarse para gestionar proyectos de
cualquier tamao, que abarcan distintas geografas 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 informacin y mejorar la comunicacin.
El proceso Convocar _________ asegura esta sincronizacin. Los diversos Equipos Scrums estn
representados en esta reunin 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 tamao del proyecto, el nivel de complejidad y las recomendaciones
del Cuerpo de Asesoramiento de Scrum.
Programas
En los Programas, los roles principales para la gestin de Scrum son:
1. Product Owner del Programa define los objetivos y las prioridades estratgicas 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 Producto Owner y Scrum Master excepto que satisfacen las
necesidades del Programa o unidad de negocio en lugar de las de un slo Equipo Scrum.
Portafolios
En Portafolios, los roles importantes para la gestin de Scrum son:
1. Product Owner del Portafolio Define los objetivos estratgicos y las prioridades del Portafolio.
2. Scrum Master del Portafolio Resuelve problemas, elimina Impedimentos, facilita y lleva a cabo
reuniones para el Portafolio.
2014 SCRUMstudy.com 64
La siguiente figura ilustra cmo el mtodo Scrum se puede utilizar en toda la organizacin para los
Portafolio, Programa o Proyectos.
Los problemas que se enfrentan al utilizar Scrum dentro de un Programa o Portafolio implican
principalmente la coordinacin entre los numerosos equipos. Esto puede conducir al fracaso si no
se gestiona con cuidado. Las herramientas utilizadas para la comunicacin 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 slo la comunicacin interna, sino tambin la comunicacin
externa con otros equipos y los interesados del Programa o Portafolio.
2014 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 reunin de cada uno de los Equipo Scrums.
Por lo general el representante es el Scrum Master, pero tambin puede asistir cualquier miembro del
Equipo Scrum si es necesario. Esta reunin es usualmente facilitada por el Jefe Scrum Master y su
objetivo es centrarse en las reas de coordinacin e integracin entre los diferentes Equipo Scrums.
Tal reunin 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 simultnea, SoS se puede escalar a otro nivel, esta se conoce como Scrum of Scrum of Scrums
Meeting. En esta situacin, una Reunin SoS mantiene la coordinacin de cada grupo de los Equipo
Scrums.
Transicin a Scrum
Los dos mtodos bsicos para hacer la transicin a Scrum son de ________________ y
de______________. En el mtodo de arriba hacia abajo, la transicin es comunicada en toda la
organizacin. Existe un esfuerzo por proveer capacitacin del cambio a todos los involucrados. Esta
comunicacin puede ser fuente de resistencia al cambio. La otra posibilidad es cambiar las cosas
gradualmente dentro de la cultura de la organizacin. Despus, la transicin a Scrum ser de forma
incremental.
Con una implementacin de arriba hacia abajo, podran haber conflictos de comunicacin. Por ejemplo,
un lder de ingeniera implant Scrum en su organizacin sin el consentimiento por parte del rea de
ventas. Esto llevara a grandes conflictos con el mismo Product Owner.
Otro aspecto a considerar de la transicin es saber el impacto de la transicin de la organizacin a los
mtodos Scrum. Toda organizacin puede hacer la transicin al mismo tiempo. Sin embargo, este
mtodo es ms susceptible a problemas que pueden resultar en la interrupcin de actividades que
generan ganancias. Por lo tanto, es generalmente preferible hacer la transicin en diferentes secciones
de forma iterativa para reducir el riesgo y proveer lecciones aprendidas para futuras iteraciones.
2014 SCRUMstudy.com 66
Mapeo de Roles tradicionales a Scrum
Los roles tradicionales del gestin de proyecto son divididos en tres roles en Scrum : ___________,
______________ y ________________.
El Producto 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 tambin ejecutan algunos roles tradicionales del jefe de proyecto,
dado que ellos se autogestionan y son dueos 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 estn comprometidos.
Mantener una comunicacin regular con los interesados.
Es importante que los ejecutivos que financian el proyecto tengan claridad respecto a los siguientes
temas:
2014 SCRUMstudy.com 67
Captulo Escalando Scrum - Preguntas
1. Cul de los siguientes NO es cierto con respecto a la implementacin de Scrum para
grandes proyectos?
A. Se requieren varios equipos para trabajar en sincrona.
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.
2014 SCRUMstudy.com 68