SMC Cuaderno de Trabajo

© 2016 SCRUMstudy.
com
INTRODUCCIÓN
Reglas Básicas del Taller

 Los participantes deberán estar en el aula de clases a tiempo y regresar puntualmente luego
de los descansos de 15 minutos.
 Los teléfonos celulares deberán estar apagados o estar en modo de silencio.
 Se espera una completa participación por parte de los participantes. Únase a las actividades y
ejercicios de acuerdo a las indicaciones del docente. Advertencia – ¡de hecho podría divertirse
en este taller!
 Los materiales y recursos de estudio que utilizarán los participantes tienen derechos de autor
y son propiedad absoluta de SCRUMstudy y PM Certifica. No deberán ser fotocopiados,
distribuidos o compartidos y deberán ser utilizados únicamente por los participantes que se
hayan inscrito en el aula de capacitación del Taller de Preparación para la Certificación SMC.
Objetivos del Curso

 Proveer el entendimiento de la filosofía y principios Scrum.
 Proveer conocimiento práctico de Scrum, incluyendo los roles, reuniones y artefactos.
 Preparar a los participantes para sentirse cómodos al implementar Scrum en sus
organizaciones así como también manejar conflictos y obstáculos comunes.
Resultados del Curso

 Los estudiantes reconocerán, definirán y trabajarán con facilidad los conceptos, ventajas y
retos del Marco de Trabajo de Scrum.
 Los participantes estarán preparados para desempeñar el rol de Scrum Master en sus
organizaciones y ayudar a sus organizaciones a adoptar el Marco de Trabajo Scrum.
 Los participantes participarán en dinámicas en las cuales llevarán a cabo un proyecto Scrum.
 Los participantes obtendrán conocimientos para anticipar conflictos relacionados a la
implementación de Scrum.
 Los participantes contarán con las herramientas apropiadas para dirigir, resolver y tomar el
liderazgo en los conflictos de Scrum en sus organizaciones.
 Se proporcionará a los participantes acceso a un examen en línea.
Metodología del Curso

 La metodología asegura una alta retención de los conceptos y teorías.
 Se motiva a los participantes a poner en práctica los conceptos más que a solamente
escucharlos – esto provee una mejor internalización y retención.
 Se llevarán a cabo dinámicas prácticas y se discutirán los problemas comunes de
implementación de todas las partes del flujo Scrum.
 Los participantes ponen en práctica un caso de estudio para simular el desarrollo del producto
utilizando el Marco de Trabajo Scrum.
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.
Membresía Avanzada – Cuota Anual

La Membresía Avanzada provee acceso a foros de discusión y recursos en línea adicionales, además
de descuentos en el precio del examen.
Acerca del Examen de Certificación SMCTM Certification Exam

Formato del Examen
 Elección Mútiple
 100 preguntas por examen
 Un punto otorgado por cada respuesta correcta
 No hay puntos negativos por respuestas erróneas
 120 minutos de duración
 Examen en línea supervisado
 Tasa de Aprobación Actual: 95%
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 gran interés por Agile

Agile se basa en la planificación de adaptación en el desarrollo y la entrega iterativa. Se centra
principalmente en que el equipo ejecute el trabajo con eficacia. Aunque las metodologías adaptivas e
incrementales han existido desde la década de 1950, sólo las metodologías que se ajustan a El
Manifiesto Ágil son generalmente consideradas verdaderamente como "Ágil".
The Agile Manifesto

El propósito de The Agile Manifesto fue distribuido de la siguiente manera:
Estamos descubriendo mejores formas de desarrollar
software haciéndolo y ayudando a que otros lo hagan.
A través de este trabajo hemos llegado a valorar:
Los individuos y Procesos y

las Interacciones Herramientas
Software Documentación
Funcionando Extensiva
Colaboración Negociación
con el Cliente Contractual
Respuestas ante Seguir un Plan
el cambio
Es decir, mientras que hay valor en los elementos de

la derecha, valoramos más los elementos de la izquierda.
Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
El permiso para copiar fue proporcionado por los autores mencionados mediante aviso en http://agilemanifesto.org/.
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
Principios de Agile Manifesto

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y
continua de software con valor.
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.
3. Entregamos software funcional de manera frecuente, entre dos semanas y dos

meses, con preferencia el periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que brindarles

el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo

y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal del avance del proyecto.
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante
de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados.
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.
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.
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.
Feature Driven Development (FDD)

Feature Driven Development (FDD) fue presentado por Jeff De Luca en 1997 y opera bajo el principio
de la realización de un proyecto donde éste se separa en pequeñas funciones valoradas por el cliente
que pueden ser entregadas en menos de dos semanas. FDD tiene dos principios - el desarrollo de
software es una actividad humana y el desarrollo de software es una funcionalidad valorada por el
cliente.
Test Driven Development (TDD)

También conocido como Test-First Development, Test Driven Development fue presentado por Kent
Beck, uno de los creadores de Extreme Programming (XP). Test Driven Development es un método
de desarrollo de software que consiste en escribir primero un código de prueba automatizado y en el
desarrollo de la menor cantidad de códigos necesarios para luego pasar la prueba.
Adaptive Software Development (ASD)

Adaptive Software Development (ASD) surgió a partir de la rápida labor de desarrollo de aplicaciones
por Jim Highsmith y Sam Bayer. Los aspectos más destacados de los ASD son Adaptación constantes
de los procesos de trabajo, el suministro de soluciones a los problemas que surgen en los grandes
Proyectos y el desarrollo incremental iterativo con prototipos continuos.
Agile Unified Process (AUP)

Agile Unified Process (AUP) evolucionó del proceso llamdo Rational Unified Process de IBM.
Desarrollado por Scott Ambler, AUP combina técnicas ágiles de la industria ya probadas como Test
Driven Development (TDD), Agile Modeling, gestión del cambio ágil y la base de datos Refactoring
para ofrecer un Producto de trabajo de la mejor calidad.
Domain-Driven Design (DDD)

Domain-Driven Design se trata de un enfoque de desarrollo ágil con la intención de manejar diseños
complejos con aplicación vinculada a un modelo en evolución. Fue concebido por Eric Evans en el año
2004 y gira en torno al diseño de un dominio básico.
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
El énfasis está en Personas Procesos
Documentación Sólo mínima según se requiera Exhaustivo
Estilo de Procesos Iterativo Lineal
Planificación por Adelantada Baja Alta
Prioritización de los Según el valor del negocio y

Fijo en el plan de proyecto
Requisitos regularmente actualizada
Garantía de Calidad Centrada en el Cliente Centrada en el Proceso
Organización Auto-organizada Gestionada
El Estilo de Gestión Descentralizado Centralizado
Las actualizaciones de Sistema formal de Gestión del

Cambio
Prioritized Product Backlog Cambio
Liderazgo Colaborativo, Líder Servicial Mando y control
La Medición del Rendimiento El valor del negocio Plan de la Conformidad
Al comienzo y a lo largo del

Return on Investiment (ROI) Al final del proyecto
proyecto
Varía en función del ciclo de

Participación del Cliente Alta durante todo el proyecto
vida del proyecto
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
Scrum vs Método Tradicional
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.
3. ¿Cuál de los siguientes NO es parte del Manifiesto Ágil?

A. Promover a las personas sobre los procesos.
B. Responder al cambio en lugar de hacer planes a largo plazo.
C. Tener un equipo especializado en lugar de un equipo multifuncional.
D. El software funcionando es más importante que la documentación extensa.
4. Como jefe de proyecto empleando prácticas Ágiles en su organización, ¿cuál de los

siguientes principios NO emplearía?
A. Empleados del negocio y técnicos deben trabajar juntos.
B. Documentar todos los detalles de un nuevo software antes de permitir su lanzamiento.
C. Ubicar a los equipos en un mismo lugar y promover la comunicación cara a cara.
D. Recibir cambios de requerimientos, incluso tarde en el desarrollo.
5. ¿Cuál de los siguientes NO es verdadero con respecto a las metodologías Ágiles?

A. Se enfoca en las personas en lugar de los procesos.
B. Promueve la documentación mínima, a diferencia de la técnica de Cascada.
C. Recomienda un estilo de liderazgo basado en comando y control.
D. Se centra en la capacidad de adaptación del proyecto.
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.
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
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.
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.
¿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.
*Reference: SBOKTM Guide 2013, p. 4-5
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
3. ¿En cuál de los siguientes entornos proyectos Scrum NO son aplicables?

A. El desarrollo de productos de vanguardia
B. Alta frecuencia de cambio de requerimientos
C. Mercados volátiles y hipercompetitivos
D. Ninguna de las anteriores
4. ¿Cuál es el resultado respecto al desarrollo de productos utilizando Scrum?

A. Transparencia con todo el Equipo de Scrum y con los interesados
B. Ambiente adaptativo de desarrollo de producto
C. Las características que ofrecen el máximo valor comercial se desarrollan primero
D. Todas las anteriores
5. La entrega priorizada en Scrum significa que:

A. Las características que son las más simples y no requerirían mucha participación por parte
del equipo se completarán primero.
B. Las características con la menor o interdependencia nula se completarán primero para
asegurar la entrega sin problemas ni interrupciones.
C. Las características que proporcionan el máximo valor comercial se completarán primero.
D. Las características se desarrollan de acuerdo al orden de llegada, las que primero entran,
son las que primero salen.
LOS ROLES DE SCRUM
Los roles de Scrum se dividen en dos categorías:
 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.
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.
Voz del Cliente - Voice of the Customer (VOC)

El cliente es el interesado más importante para cualquier compañía. Por lo tanto, es muy importante
entender sus necesidades y requerimientos. La voz del cliente se enfoca en
__________________________ del cliente, que deben entenderse muy bien antes de diseñar
cualquier producto o servicio. En general, en un entorno de Scrum, El Product Owner representa la
Voz del Cliente.
Para cualquier proyecto Scrum, el cliente podría ser:
 Interno (dentro de la misma organización)
 Externo (fuera de la organización)

La siguiente tabla resume las responsabilidades del Product Owner en los diferentes procesos de
Scrum.
Proceso Responsabilidades del Product Owner
 Define la Visión del Proyecto

Create Project Vision  Ayuda a crear el Acta de Constitución del Proyecto y el
Presupuesto del Proyecto
Identify Scrum Master and  Ayuda a elegir al Scrum Master para el proyecto
Stakeholder(s)  Identifica a los interesados
 Ayuda a determinar los miembros del Equipo Scrum

 Ayuda a desarrollar el Plan de Colaboración
Form Scrum Team  Ayuda a desarrollar el Plan para la Formación del Equipo
con el/los Scrum Master(s)
Develop Epic(s)  Crea Epic(s) y Personas
 Prioriza los elementos del Product Backlog (cartera de

Create Prioritized Product pendientes)
Backlog  Define el Criterio de Terminado (Done)
 Crea un Cronograma de Planificación de Entregas
Conduct Release Planning (Releases)
 Ayuda a determinar la duración del Sprint
 Ayuda a crear Historias de Usuarios
Create User Stories  Define el Criterio de Aceptación para cada Historia de
Usuario
 Aprueba los Historias de Usuarios que se harán en un Sprint
Approve, Estimate and  Ayuda al Equipo Scrum a comprender las Historias de
Commit User Stories Usuarios para que puedan estimar.
 Explica las Historias de Usuarios al Equipo Scrum mientras
Create Tasks crean la Lista de Tareas
 Proporciona orientación y aclaración al Equipo Scrum sobre
Estimate Tasks la estimación de esfuerzo para las tareas
 Aclara los requisitos al Equipo Scrum mientras crea el Sprint
Create Sprint Backlog Backlog
Create Deliverables  Aclara los Requisitos del Negocio al Equipo Scrum
Groom Prioritized Product  Refina la Product Backlog y reprioriza si es necesario

Backlog
 Acepta / Rechaza los Entregables

 Proporciona retroalimentación al Scrum Master y al Equipo
Demonstrate and Validate Scrum
Sprints  Actualiza el Plan de Entregas (Releases) y la Priorización
del Product Backlog
 Ayuda con el lanzamiento de las Entregas de Producto y se
Ship Deliverables encarga de la coordinación con el Cliente
Retrospect Project  Participa en las Reuniones de Retrospectiva del Proyecto
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.
Procesos Responsabilidades del Scrum Master
Identify Scrum Master and  Ayuda a identificar a los interesados del proyecto
Stakeholder(s)
 Ayuda a determinar los miembros del Equipo Scrum

 Ayuda a desarrollar el Plan de Colaboración y el Plan para la
Form Scrum Team Formación del Equipo
 Asegura que los recursos de respaldo estén disponibles para el
funcionamiento del proyecto sin problemas
Develop Epic(s)  Facilita la creación de Epic(s) y Personas
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
 Coordina la creación del Cronograma de Planificación de las

Conduct Release Planning Entregas (Releases)
 Determina el duración del Sprint con el Product Owner
 Apoya al Equipo Scrum en la creación de Historias de Usuarios y

Create User Stories sus Criterios de Aceptación
Approve, Estimate and  Facilita reuniones del Equipo Scrum para estimar y Crear
Commit User Stories Historias de Usuarios
 Facilita al Equipo Scrum en la creación de la Lista de Tareas

Create Tasks para el siguiente Sprint
 Ayuda al Equipo Scrum en la estimación del esfuerzo necesario

Estimate Tasks para completar las tareas acordadas para el Sprint
 Apoya al Equipo Scrum en el desarrollo del Sprint Backlog y el

Create Sprint Backlog Gráfico Sprint Burndown
 Apoya al Equipo Scrum en la creación de los Entregables

Create Deliverables (Deliverables) acordados para el Sprint
 Ayuda a actualizar el Scrumboard y el Impediment Log
 Asegura que el Scrumboard y el Impediment Log permanezcan

Conduct Daily Standup actualizados
Groom Prioritized Product  Facilita la reuniones de revisión del Product Backlog

Backlog
 Se asegura que los Incidentes que afectan al Equipo Scrum se

Convene Scrum of Scrums discutan y resuelvan
Demonstrate and Validate  Facilita la presentación de los Entregables ya completados por el

Sprints Equipo Scrum para la aprobación del Product Owner
 Asegura que exista un ambiente ideal para el Equipo Scrum en los

Retrospect Sprint sucesivos Sprints
 Representa al Equipo Core de Scrum (Scrum Core Team) para

Retrospect Project proporcionar lecciones del proyecto actual, si es necesario
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.
Características del Equipo Scrum
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:
 El uso de equipos multi-funcionales también se asegura de que todas las habilidades y

conocimientos necesarios para llevar a cabo el trabajo del proyecto existan dentro del equipo.
 Este modelo de equipo en Scrum está diseñada para optimizar la flexibilidad y la productividad.
 Un equipo multi-funcional está más enfocado en un objetivo común.
Coubicación y comunicación cara a cara:
 Scrum permite la creación de equipos auto-organizados fomentando la coubicación de todos

los miembros y recomienda la comunicación cara a cara entre todos los miembros.
 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:
 Los equipos Scrum entregan productos de forma iterativa e incremental, maximizando

oportunidades para la retroalimentación.
 Las entregas incrementales de producto “Terminados” asegura estas versiones se encuentren

disponibles para comercializarse.
La siguiente tabla muestra las responsabilidades del Equipo Scrum durante los diferentes procesos
de Scrum.
Proceso Responsabilidades del Scrum Team
 Brinda información para la creación del Plan de Colaboración y para

Form Scrum Team el Plan para la Formación del Equipo
 Se asegura de tener un buen entendimiento de los Epic(s) y de

Develop Epic(s) Personas.
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.
 Brinda información al Product Owner para la creación de Historias de

Create User Stories Usuario.
 Estima las Historias de Usuario aprobadas por el Product Owner.

Approve, Estimate and Commit
 Se compromete ha implementar algunas Historias de Usuario en un
User Stories Sprint.
 Elabora la Lista de Tareas basadas en las Historias de Usuario y sus

Create Tasks dependencias.
 Estima las tareas identificadas y si es necesario actualizar la Lista de

Estimate Tasks Tareas.
Create Sprint Backlog  Elabora el Sprint Backlog y el gráfico Sprint Burndown
 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.
Groom Prioritized Product  Participa en las reuniones de refinamiento y repriorización (si es

Backlog necesario) del Product Backlog.
 Brinda información al Scrum Master para las reuniones de Scrum de

Convene Scrum of Scrums Scrums.
Demonstrate and Validate  Presenta los entregables completos al Product Owner para su
Sprints aprobación.
 Identifica oportunidades de mejora, si existiesen, del Sprint que acaba

Retrospect Sprint de finalizar y acuerda las acciones de mejora para llevarlas a cabo el
siguiente Sprint.
Retrospect Project  Participa en la reunion de Retrospectiva del Proyecto.
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.
La siguiente figura muestra las etapas en el Modelo de Tuckman de Desarrollo de Equipo.
Etapas de Tuckman de Desarrollo de Equipos
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.
Ventajas de Equipos Multi-funcionales

Scrum utiliza el enfoque de equipos multi-funcionales porque este brinda las siguientes ventajas:
 Toma rápida de decisiones: Un equipo multi-funcional es pequeño y está conformado por

expertos que pueden alcanzar un objetivo común más rápido que en un proyecto tradicional
donde los equipos estás orientados a la función que ejecutan.
 Mejor comunicación: Los equipos multi-funcionales generalmente están _______ lo que

permite tener una comunicación más fluida cara a cara entre los miembros del equipo. Así el
equipo interactúa regularmente haciendo posible que se comparta el conocimiento.
 Orientado al objetivo: Los equipos multi-funcionales en Scrum están enfocados totalmente al

resultado deseado. El Equipo Scrum ha definido un grupo de objetivos durante un Sprint y es
suficientemente flexible para realizar cambios en los objetivos antes del siguiente Sprint.
 Propiedad colectiva: El equipo como un todo es responsable de la entrega de resultados, y

el éxito o el fracaso del proyecto es de todo el equipo.
 Innovación continua: El uso de expertos en varios campos en el equipo multi-funcional

permite el intercambio de ideas, de esta forma se fomenta el pensamiento creative.
Non- core Roles

Los roles non-core o no esenciales son las funciones que no son obligatorias para el proyecto Scrum,
y pueden incluir miembros que no están involucrados directamente o continuamente con el proceso
Scrum. Sin embargo, los roles no esenciales pueden jugar un papel importante en el proyecto.
Los Roles no Esenciales pueden incluir:
1. Interesados
Es un término colectivo que incluye a los Clientes, los usuarios y patrocinadores, que a menudo
interactúan con el Product Owner, Scrum Master y Equipo Scrum para proporcionarles
información y para ayudar en la creación del producto, servicio, o cualquier otro resultado del
proyecto. Los interesados influyen en el proyecto a lo largo del desarrollo del proyecto.
También pueden desempeñar un papel en los procesos importantes de Scrum tales como:
Desarrollo de Epic(s), Crear Product Backlog Priorizados, Ejecutar la Planificación de la
Entrega, Retrospectiva del Sprint.
 Cliente
El Cliente es la persona o la organización que adquiere el producto, servicio, o cualquier otro

resultado del proyecto. Para cualquier organización, dependiendo del proyecto, pueden haber
Clientes internos (es decir, dentro de la misma organización) o Clientes externos (es decir,
fuera de la organización).
 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
El patrocinador es la persona o la organización que provee recursos y apoyo para el proyecto.

El patrocinador es también el interesado, a quien todos le deben rendir cuentas al final.
A veces, la misma persona u organización pueden desempeñar múltiples funciones – el
interesado, por ejemplo, el patrocinador y el cliente puede ser el mismo.
2. Vendedores Los vendedores incluyen a individuos u organizaciones externas que ofrecen

productos y/o servicios que no están dentro de las competencias básicas de la organización
del proyecto.
3. Cuerpo de Asesoramiento de Scrum (SGB) es un rol _______. Por lo general, se compone

de un grupo de documentos y/o un grupo de expertos que normalmente están involucrados en
la definición de los objetivos relacionados con la calidad, las regulaciones gubernamentales,
la seguridad y otros parámetros importantes de la organización. Estos objetivos guían la labor
llevada a cabo por el Product Owner, Scrum Master y Equipo Scrum. El Cuerpo de
Asesoramiento de Scrum también ayuda a capturar las mejores prácticas que se deben utilizar
en todos los proyectos Scrum de la organización.
El Cuerpo de Asesoramiento de Scrum no toma decisiones relacionadas con el proyecto. En
cambio, actúa como una consultoría o una estructura de orientación para todos los niveles de
jerarquía en la organización de proyectos - Portafolio, Programa y proyecto. Los Equipo
Scrums tienen la opción de solicitar ayuda al Scrum Guidance of Body sobre cualquier
asesoramiento requerido.
Capítulo Roles de Scrum - Preguntas
1. ¿Cuál de los siguientes es un rol esencial (core) de Scrum?
A. Product owner
B. Interesado
C. Patrocinador del proyecto
D. Administrador del proyecto
2. ¿Quién de los siguientes es responsable de proporcionar al Equipo de Scrum de un

ambiente favorable para la creación de entregables?
A. Scrum Master
B. Product Owner
C. Cuerpo de Asesoramiento de Scrum (SGB)
D. Interesados externos
3. ¿Quién de los siguientes es el responsable de crear una conciencia de las prácticas de

Scrum entre los miembros del Equipo de Scrum?
A. Scrum Master
B. Product Owner
C. Equipo de Scrum
D. Cuerpo de Asesoramiento de Scrum (SGB)
4. ¿Quién de los siguientes es responsable de lograr el máximo valor de negocio del

proyecto?
A. Scrum Master
B. Product Owner
C. Equipo Scrum
D. Las partes interesadas externas
5. ¿Quién de los siguientes es el responsable de crear los entregables en el proceso Crear

Entregables?
A. Jefe Scrum Master
B. Product Owner del Portafolio
C. Líder Equipo Scrum
D. Equipo Scrum
6. Las ventajas de utilizar un equipo multi-funcional son:
A. Mejora de la comunicación entre los miembros del equipo.

B. Toma de decisiones más rápida.
C. Responsabilidad individual asignada a cada miembro del equipo en función de su
experiencia.
D. Ambos A y B.
7. ¿Quién de los siguientes es el responsable de decidir sobre los criterios de aceptación

para las historias de usuario?
A. Scrum Master
B. Product Owner
D. Equipo Scrum
8. ¿Quién de los siguientes representa la voz del cliente?
A. Jefe Scrum Master

B. Product Owner
D. Los miembros del 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
D. Equipo Scrum
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).
Un proyecto Scrum tiene las siguientes cinco fases:

1. Iniciar
2. Planear y Estimar
3. Implementar
4. Revisión y Retrospectiva
5. Lanzamiento
Fase Procesos
1. Crear la Visión del Proyecto

2. Identificar al Scrum Master e interesados
Initiate 3. Formar el Equipo Scrum
4. Desarrollar Epic(s)
(Iniciar)
5. Crear la Lista de Pendientes del Producto Priorizada
6. Realizar la Planificación de las Entregas (Release)
7. Crear Historias de Usuarios

8. Aprobar, Estimar y Comprometerse con Historias de
Plan and Estimate Usuarios
9. Crear Tareas
(Planear y Estimar)
10. Estimar el Trabajos
11. Crear la Lista de Pendientes de Sprint
Implement 12. Crear Entregables

13. Realizar el Standup Diario
(Implementar) 14. Mantener la Lista de Pendientes del Producto Priorizada
Review and Retrospect 15. Convocar Scrum de Scrums

16. Demostrar y Validar el Sprint
(Revisión y Retrospectiva) 17. Realizar la Retrospectiva del Sprint
Release 18. Enviar los Entregables

19. Realizar la Retrospectiva del Proyecto
(Lanzamiento)
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).
Proceso 1: Crear la Visión del Proyecto

En este proceso, el Caso de Negocio es revisado para crear un Declaración de la Visión del Proyecto
que servirá de inspiración y proporcionará el enfoque de todo el Proyecto. El Product Owner es el
responsable de crear la visión del proyecto.
1. Caso de Negocio del 1. Product Owner Identificado *

1. Reunión de la Visión del 2. Declaración de la Visión del
Proyecto*
Proyecto * Proyecto *
2. Product Owner del
3. Acta de Constitución del
Programa 2. Sesiones JAD
Proyecto
3. Scrum Master del 4. Presupuesto del Proyecto
3. Análisis FODA (SWOT)
Programa
4. Interesados del Programa 4. Análisis de Brechas
5. Jefe Product Owner
6. Product Backlog del
Programa
7. Prueba del Proyecto
8. Prueba de Concepto
9. Visión de la Empresa
10. Misión de la Empresa
11. Estudio del Mercado
12. Recomendaciones del
Cuerpo de Asesoramiento
de Scrum (SGB)
Caso de Negocio del Proyecto (Project Business Case) *

Un caso de negocio (business case) puede ser un documento bien estructurado o simplemente una
declaración verbal que expresa la razón para iniciar un Proyecto. Puede ser formal y detallado, o
informal y breve. Independientemente del formato, a menudo incluye información sustancial sobre los
antecedentes del Proyecto, los objetivos del negocio y los resultados deseados, un análisis FODA
(SWOT), Análisis de Brechas, una lista de los Riesgos identificados, y las estimaciones de tiempo, el
esfuerzo y costo.
El Proyecto se inicia con la presentación del Caso de Negocio. El caso de negocio se presenta a los
interesados y patrocinadores para que comprendan los beneficios de negocio esperados del Proyecto.
Finalmente los patrocinadores confirman que van a proporcionar los recursos financieros para el
Proyecto.
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.
Product Owner Identificado
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.
Declaración de la Visión del Proyecto
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.
Proceso 2: Identificar al Scrum Master y a los Interesados
Identify Scrum Master and Stakeholder(s)

El segundo paso en la fase de Inicio en un proyecto Scrum es identificar al Scrum Master y a los
interesados.
1. Product Owner * 1. Criterios de Selección * 1. Scrum Master Identificado*

2. Declaración de la Visión 2. Consejo Experto del 2. Interesados Identificados*
del Proyecto * Recursos Humanos
3. Entrenamiento y Costos de
3. Product Owner del
capacitación
Programa 4. Costos de Recursos
4. Scrum Master del
Programa
5. Jefe del Product Owner
6. Jefe del Scrum Master
7. Interesados del Programa
8. Requisitos de Personal
9. Disponibilidad y
compromiso de las
Personas
10. Matriz de Recursos de la
Organización
11. Matriz de Destrezas
Requeridas
de Scrum
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:
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.
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.
1. Product Owner * 1. Selección del Equipo Scrum* 1. Equipo Scrum Identificado *

2. Scrum Master* 2. Consejo Experto del Recursos 2. Respaldos de los miembros del
3. Declaración de la Visión del Humanos equipo
Proyecto* 3. Entrenamiento y Costos de 3. Plan de Colaboración
4. Jefe del Product Owner capacitación 4. Plan de Desarrollo del Equipo
5. Requisitos del Personal 4. Costos de Recursos
6. Disponibilidad y Compromiso
de las Personas
7. Matriz de Recursos de la
Organización
8. Matriz de Destrezas
Requeridas
9. Requerimientos de Recursos
10. Recomendaciones del Cuerpo
de Asesoramiento de Scrum
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.
Objetivos de un equipo auto-organizado
Proceso 4: Desarrollo de Epic(s)

Develop Epic(s)
Es el cuarto proceso de la fase de Incio. En terminología Scrum, un Epic es definido cómo una
________________ no refinada, la cual es generalmente muy grande para ser completada en un solo
Sprint, por lo que es necesario desglosarla en Historias de Usuario (User Stories) más pequeñas en
algún punto del proyecto antes de implementarlas. El Equipo Core Scrum empieza escribiendo Epics
basados en la Visión del Proyecto y podría considerar otros factores como Solicitudes de Cambio
aprobados y no aprobados, Leyes y Regulaciones, Contratos, etc.
El Product Owner es el responsable de crear las Epics y las Historias de Usuarios. Generalmente, el
Product Owner crea las Historias de Usuario, pero en algunos casos son desarrolladas por el Equipo
Scrum en coordinación con el Product Owner.
Las dos salidas principales de este proceso son los ______ y ________. Personas son complementos
a Epics, dado que ayudan al equipo a entender mejor a los usuarios y sus necesidades y objetivos.
Personas son personajes de ficción con descripción muy detallada que representan a la mayoría de
los usuarios y otros interesados que no utilizan directamente el producto final.
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
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
de Scrum
Reunión de Grupo de Usuarios
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.
Proceso 5: Crear la Lista de Requerimientos Pendientes del Producto
Priorizada
Create Prioritized Product Backlog

Luego que el Equipo Core Scrum crea los Epics y Personas, el Product Owner crea la Lista Priorizada
de Pendientes del Producto Priorizada (Prioritized Product Backlog), la cual incluye una lista de
características y funcionalidades necesarias para cumplir con los objetivos del proyecto. Esta lista es
priorizada donde los elementos de mayor valor, es decir los que dan el máximo valor _________, tienen
la ________ más alta.
El Product Backlog es una lista de requerimientos que, al convertirse en funcionalidad de producto
potencialmente comercializable, entregará la Visión del Producto.
Es responsabilidad del Product Owner elaborar el inicial Product Backlog Priorizado.
El Product Backlog Priorizado generalmente contiene Epics, pero a veces también contiene
información relacionada a hallazgos importantes como problemas reportados, requerimientos
funcionales y no funcionales, etc. Los elementos del Product Backlog Priorizado tienen asignadas
estimaciones de alto nivel para indicar el esfuerzo en tiempo y recursos que son necesarios para
implementarlos basados en características como el tamaño, complejidad y experiencia requerida.
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
La priorización tienen en cuenta tres factores principales: valor, riesgo e incertidumbre, y

dependencias. El Equipo Core Scrum podría utilizar varios métodos de priorización como los
mencionados a continuación:
 Análisis Kano : El análisis Kano fue desarrollado por Noriaki Kano (1984) , Esta técnica puede
ser utilizada para clasificar las preferencias del cliente en cuatro categorías, a las cuales nos
referiremos como Exciters/ Delighters, Satisfiers, Dissatisfiers e Indifferent.
o Entusiasmados (Exciters/Delighters): Funcionalidades nuevas o de alto valor para el
cliente.
o Satisfechos (Satisfiers): Funcionalidades que ofrecen valor al cliente.
o Insatisfechos (Dissatisfiers): Funcionalidades que, si no están presentes, probablemente
causen que el cliente esté disgustado con el producto, sin embargo no afecta el nivel de
satisfacción si ellos están presentes.
o Indiferentes (Indifferent): Funcionalidades que no afectan al cliente de ninguna forma y
deben ser eliminadas.
 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.
Proceso 6: Realizar la Planificación de los Entregables
Conduct Release Planning

En este proceso, el Equipo Core de Scrum trabaja elaborando el Cronograma de Planificación de los
Entregables (Release Planning Schedule) para entregar incrementos de producto a los interesados.
El Cronograma de Planificación de los Entregables indica qué entregables serán liberados a los
clientes, junto con los intervalos planeados y las fechas de entrega.
También, el Equipo Core de Scrum también define la duración del Sprint para el proyecto. Una vez que
la duración del Sprint es fijada, normalmente no cambia en el proyecto. Podría ser modificada en medio
del proyecto debido a mejoras en el ambiente del proyecto y en la velocidad del equipo. Para elaborar
el Cronograma de Planificación de los Entregables y para fijar la duración del Sprint se utilizan varias
entradas como las de los interesados, Declaración de Visión del Proyecto, Product Backlog Priorizado,
Requerimientos de Negocio y calendario de feriados.
El Cronograma de Planificación de los Entregables debe ser planeado de tal manera que se asegure
que cada entrega dé valor significativo al cliente. Cada Sprint debe tener una funcionalidad
potencialmente comercializable como salida; y la fecha de implementación de este entregable del
Sprint es determinada en el Cronograma de Planificación de los Entregables.
Un Sprint puede durar entre 1 y 6 semanas. Sin embargo para obtener el máximo beneficio de un
proyecto Scrum se recomienda mantener la duración del Sprint en 4 o menos semanas, a menos que
el proyecto tenga requirimientos estables, donde los Sprints puede ser ampliados a 6 semanas.
1. Scrum Core Team* 1. Sesiones de Planificación 1. Cronograma de

2. Interesados* de las Entregas* Planificación de las
3. Declaración de la Visión del 2. Métodos de Priorización de Entregas*
Proyecto * las Entregas * 2. Duración del Sprint *
4. Product Backlog 3. Clientes Objetivo para el
Priorizado * Lanzamiento
5. Criterio de Terminado * 4. Product Backlog Priorizado
6. Product Owner del y Refinado
Programa
7. Scrum Master del
Programa
8. Jefe del Product Owner
Programa
10. Requisitos del Negocio
11. Calendario de Feriados
de Scrum
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.
Proceso 1: Crear Historias de Usuarios

Create User Stories
Este es el primer proceso en la fase de Planear y Estimar.
Una Historia de Usuario (User Story) es una declaración que expresa una funcionalidad deseada de
un usuario. Normalmente esta es desglosada en bloques de tareas secuenciales.
Las Historias de Usuario son importantes para el Equipo Core de Scrum y para los interesados porque
ayudan a mejorar la comunicación entre ambos grupos. Los requerimientos expresados en Historias
de Usuario son fáciles de entender y permiten tener mejor estimaciones. Las Historias de Usuario
eliminan la necesidad de la documentación detallada de los requerimientos del cliente. Son escritas en
lenguaje que el negocio entiende. A veces, el Equipo Core de Scrum trabaja en el desarrollo de
“themes”. Un Theme es un grupo de Historias de Usuario relacionadas. Estos contienen uno o más
Epics. Muchos Themes puede ser asociados a un producto, pero un Theme no puede ser relacionado
con más de un producto al mismo tiempo.
La responsabilidad de crear las Historias de Usuario recae en el _________. Generalmente el Product
Owner crea las Historias de Usuario, pero en algunos casos estos son creados por el Equipo Scrum
en coordinación con el Product Owner.
El Equipo Core de Scrum tiene que asegurar que los requerimientos de negocio del cliente serán
convertidos en requerimientos funcionales que el desarrollador pueda entender fácilmente para
implementarlos. Por lo tanto, el Equipo Core de Scrum debe ser experto escribiendo Historias de
Usuario que den valor, sean estimables y factibles. Para dominar la habilidad de crear buenas Historias
de Usuario se requiere práctica y tiempo; sin embargo el Equipo Core de Scrum puede acortar ese
tiempo asistiendo a Talleres para Escribir Historias de Usuario. El Equipo Scrum podría seguir el
modelo INVEST para crear mejores Historia de Usuario.
INVEST es un acrónimo que significa: Independent, Negotiable, Valuable, Estimable, Small y Testable.
 Independent (Independiente) — Cada Historia de Usuario debe ser independiente de las

otras. La interdependencia de historias puede causar problemas en la estimación y la
priorización.
 Negotiable (Negociable) — Una Historia de Usuario debería tener una descripción corta sin
muchos detalles. Por lo que se puede conversar y negociar con el cliente.
 Valioso (Valuable) — Cada Historia de Usuario debe dar valor al cliente. Para asegurar que
la historia sea valiosa, el cliente debe estar involucrado en su escritura.
 Que se puede Estimar (Estimable) — La Historia de Usuario debe ser fácil de estimar por
parte de los desarrolladores, así ellos no tendrán dificultades en la priorización y planificación.
 Pequeño (Small) — Una Historia de Usuario bien escrita debe ser pequeña en esfuerzo. Si se
requiere mayor esfuerzo existe alta probabilidad de tener errores en la estimación y el alcance.
 Verificable (Testable) — Para confirmar que una Historia de Usuario está Terminada, es
necesario que sea verificable. Algo que no puede ser verificado no debería ser desarrollado,
porque no podrá ser confirmado como Terminado. Por ejemplo: “Como usuario, yo quiero que
mi trabajo sea fácil, así este proceso no debería ser complicado.” esta historia de usuario no
es verificable.
Una Historia de Usuario nos muestra tres características de un requerimiento: Quién, Qué y Cómo.
Los requerimientos expresados como Historias de Usuario son enunciados cortos, simples y
fáciles de entender.
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,.
.
1. Scrum Core Team* 1. Experiencia en la Escritura 1. Historias de Usuarios *

2. Product Backlog de Historias de Usuario * 2. Criterios de Aceptación de
Priorizado* 2. Talleres de Historia de la Historia de Usuario *
3. Criterio de Terminado * Usuario 3. Product Backlog Priorizada
4. Personas * 3. Reuniones de Grupo de y Actualizada
5. Interesados Usuarios 4. Personas Actualizadas y
6. Epic(s) 4. Reuniones de Grupo Refinadas
7. Requisitos del Negocio Focales
8. Regulaciones y Leyes 5. Entrevistas al Cliente /
9. Contractos Usuario
10. Recomendaciones del 6. Cuestionarios
Cuerpo de Asesoramiento 7. Métodos de Estimación de
de Scrum Historia de Usuarios
8. Juicio Experto del Cuerpo
de Asesoramiento de
Scrum
Proceso 2: Aprobar, Estimar y Comprometerse con las Historias de Usuarios
Approve, Estimate, and Commit User Stories

Después que las Historias de Usuarios son creadas, tienen que ser aprobadas por el Product
Owner, estimadas por el Equipo Scrum, este también se compromete a desarrollar un conjunto
de Historias de Usuarios.
Approve El Product Owner evalúa las Historias de Usuarios de acuerdo al nivel de
satisfacción de los requerimientos de negocio y verificando si cumplen con sus
respectivos Criterios de Aceptación.
Estimate Después de que las Historias de Usuarios son aprobadas por el Product Owner, el
Equipo Core Scrum comienza el trabajo de estimación de estas. Estimar los
recursos y el tiempo con precisión es un aspecto crítico en cualquier organización
para garantizar una buena experiencia en la entrega del proyecto para el cliente.
Sin embargo, las estimaciones, por definición, no son _________ . La precisión de
la estimación varia de acuerdo a la complejidad del proyecto, el tamaño,
disponibilidad del equipo, volatilidad de los requerimientos, etc. Scrum trata de
asegurar una mejor estimación usando actividades de estimación de equipos y
métodos de comparación relativas.
Commit Después de la estimación, el Equipo Scrum se compromete desarrollar un grupo
de Historias de Usuario aprobadas y estimadas para el siguiente Sprint; así, estas
Historias de Usuario aprobadas, estimadas y comprometidas forman parte del
Sprint Backlog.
1. Scrum Core Team* 1. Reunión del Grupo de 1. Historias de Usuarios

2. Historias de Usuarios * Usuarios * Aprobadas, Estimadas y
3. Criterios de Aceptación de 2. Planificación Poker Comprometidas *
Historia de Usuario* 3. Puño de Cinco
4. Recomendaciones del 4. Estimación de Puntos de
Cuerpo de Asesoramiento Costo
de Scrum 5. Otras Técnicas de
Estimación
de Asesoramiento de
Scrum
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
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.
Puño de Cinco (Fist of Five)

Es un mecanismo simple y rápido para alcanzar consenso en un grupo y direccionar la discusión.
Después de una discusión inicial de una propuesta dada o decisión pendiente, a los miembros del
Equipo Scrum se les pide que voten en una escala entre el 1 al 5, usando sus dedos. Esta técnica
no solo permite llegar a un consenso, sino también direcciona la discusión porque a cada miembro
del equipo se le pide explicar la razón de su elección. Ellos tienen la oportunidad de expresar
cualquier preocupación o problema que tengan. Una vez que el equipo ha intercambiado
opiniones, una decision colectiva es tomada.
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:
 Un dedo: Estoy en desacuerdo con la conclusión del grupo y tengo preocupaciones

importantes que deseo revisarlas 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.
 Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo.

Estimación Relativa / Puntos de Historia (Relative Sizing / Story Points)
Además de ser utilizada para la estimación de costos, los story points pueden también servir para
la estimación de toda una Historia de Usuario o funcionalidad. Este enfoque asigna un valor de
Story Point basado en una evaluación completa del tamaño de la Historia de Usuario considerando
el riesgo, el esfuerzo requerido y el nivel de complejidad. Esta evaluación será llevada a cabo por
el Equipo Scrum y un valor de story point será asignado. Una vez que la evaluación 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.
Estimación de Afinidad (Affinity Estimation)

Esta técnica es utilizada para estimar rápidamente un gran número de Historias de Usuario.
Usando notas adhesivas o tarjetas y una cinta adhesiva, el equipo coloca las Historias de Usuarios
en la pared u otra superficie desde la más pequeña hasta la más grande. Para esto, cada miembro
del equipo empieza ordenándo un subconjunto de Historias de Usuario del Product Backlog
Priorizado según su tamaño relativo. El ordenamiento inicial es realizado en silencio. Una vez que
todos han colocado sus Historias de Usuario en la pared, el equipo revisa todas las ubicaciones y
podría mover Historias de Usuario según corresponda.
La segunda parte del ejercicio incluye la discusión. Finalmente, el Product Owner indicará algunas
categorías de tamaños en la pared. Estas categorías podrian ser small, medium, o large; o estas
pueden ser numeradas utilizando Story Points para indicar la medida relativa. El equipo entonces
moverá las Historias de Usuario a la categoría que corresponda, este es el ultimo paso del
proceso. Algunos beneficios principales de esta ténica es que el proceso es muy transparente y
fácil de ejecutarla.
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
• El Equipo Scrum determina cómo convertir las Historias de Usuario

seleccionadas en Incrementos de Producto desglosándolas en tareas.
Segunda •El Equipo Scrum se compromete con los entregables del Sprint.
Parte
En la primera parte de la Reunión de Planificación de Tareas (Task Planning Meeting), el Product

Owner sugiere Historias de Usuario que deben formar parte del Sprint basándose en la estimación
provista por el Equipo Scrum de cuántas Historias de Usuario pueden entregar en un Sprint. El objetivo
del Equipo Scrum es alcanzar un consenso en las Historias de Usuario que serán incluídas en el Sprint.
En la segunda parte de la Reunión de Planificación de Tareas (Task Planning Meeting), el Equipo
Scrum determina cómo convertir las Historias de Usuario seleccionadas en Incrementos de Producto
desglosándolas en tareas. La principal salida de esta reunión es la Lista de Tareas, la cual contiene
las tareas comprometidas por el Equipo Scrum para el Sprint. La Reunión de Planificación de Tareas
puede ser llevada a cabo dentro de la Reunión de Planificación del Sprint (Sprint Planning Meeting).
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
Proceso 4: Estimar las Tareas

Estimate Tasks
Una vez que la Lista de Tareas esté lista, el Equipo Scrum estima las tareas. Este proceso es crítico
para los miembros del Equipo Scrum para estimar el esfuerzo necesario para realizar cada tarea y así
planear la forma de proceder. La estimación es hecha tomando en cuenta la duración y el esfuerzo
requerido para convertir las tareas en entregables. “Esfuerzo” hace referencia tanto al personal como
a otros recursos requeridos para completar las tareas dentro de un Sprint.
1. Scrum Core Team* 1. Reuniones de Estimación de 1. Lista del Esfuerzo

2. Lista de Tareas * Tareas * Estimado de Tareas*
3. Criterios de Aceptación de 2. Criterios de Estimación * 2. Lista de Tareas
las Historias de Usuario 3. Planificación Poker Actualizadas
4. Dependencias 4. Puño de Cinco
5. Riesgos Identificados 5. Otras Técnicas de
6. Recomendaciones del Estimación
de Scrum
Reuniones de Estimación de Tareas (Task Estimation Meeting)

El Equipo Scrum estima las tareas en la Reunión de Estimación de Tareas. Esta reunión puede
ser llevada a cabo como parte de la Reunión de Planificación del Sprint (Sprint Planning Meeting).
Para estimar las tareas, el Equipo Scrum puede utilizar varias técnicas de Estimación. Es
importante que el Equipo Scrum trabaje con Criterios de Estimación consensuados. El objetivo
principal es utilizar los Criterios de Estimación para mantener tamaños relativos de estimación y
minimizar la necesidad de re-estimación. Los Criterios de Estimación pueden ser expresados de
muchas formas, dos ejemplos comunes son los _______________ y _______________.
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.
Proceso 5: Crear la Lista de Pendientes del Sprint

Create Sprint Backlog
Este es el ultimo proceso de la fase de Planificación y Estimación. El Sprint Backlog es creado
durante la Reunión de Planificación de Sprint (Sprint Planning Meeting). Después de que la Lista
del Esfuerzo Estimado de Tareas haya sido elaborada, el Equipo Core de Scrum toma los
elementos de la Lista de Tareas para revisarlos a detalle. Cada miembro del Equipo selecciona
las tareas que planea trabajar durante el Sprint. Desde que el Equipo Scrum es auto-organizado,
la decisión de quién trabajará en qué es hecha por los Miembros del Equipo. Ni el Product Owner
ni el Scrum Master dan instrucciones al equipo sobre qué elementos deben trabajar y cómo tienen
que hacer su trabajo. El Product Owner es el puente entre el Equipo Scrum y los interesados
mientras que el Scrum Master es el líder facilitador y mentor del Equipo Scrum.
1. Scrum Core Team* 1. Reunión de Planificación 1. Sprint Backlog *

2. Lista del Esfuerzo Estimado del Sprint (Sprint Planning 2. Sprint Burndown Chart*
de Tareas* Meeting) *
3. Duración del Sprint * 2. Herramientas de
4. Velocidad del Sprint Previo Seguimiento del Sprint
5. Dependencias 3. Métrica de Seguimiento del
6. Calendario del Equipo Sprint
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.
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:
 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.
 El gráfico Sprint Burndown es un buen indicador de la ________ del equipo en el Sprint

actual y permite hacer pronósticos para saber si el equipo podrá completar o no todas las
Historias de Usuario comprometidas.
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).
Proceso 1: Crear Entregables

Create Deliverables
En este proceso es donde principalmente se realizan los trabajos de desarrollo. El Equipo Scrum es
responsable de la creación de los Entregables del Sprint (Sprint Deliverables), mientras que el Product
Owner y el Scrum Master también tienen un rol importante en este proceso.
 El Product Owner es un Puente entre el Equipo Scrum y los Interesados, brindando a los
miembros del Equipo Scrum la información necesaria que necesitan mientras desarrollan los
entregables Sprint.
 El Scrum Master es responsable de asegurar un ambiente propicio para el desarrollo del
trabajo de los entregables del Sprint.
1. Scrum Core Team* 1. Experiencia del Equipo* 1. Entregables del Sprint

2. Sprint Backlog * 2. Software (Sprint Deliverables)*
3. Scrumboard* 3. Otras Herramientas de 2. Scrumboard Actualizado*
4. Impediment Log* Desarrollo 3. Impediment Log
5. Cronograma de 4. Juicio Experto del Cuerpo Actualizado*
Planificación de la Entrega de Asesoramiento de 4. Solicitudes de Cambio no
6. Dependencias Scrum Aprobadas
7. Recomendaciones del 5. Riesgos Identificados
Cuerpo de Asesoramiento 6. Riesgos Mitigados
de Scrum 7. Dependencias
Actualizadas
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.
Proceso 2: Realizar la Reunión Diaria
Conduct Daily Standup

La figura muestra todas las entradas, las herramientas y las salidas del proceso Realizar un Standup
Diario.
1. Scrum Team* 1. Reunión Diaria de Standup 1. Sprint Burndown Chart

2. Scrum Master* (Daily Standup Meeting)* Actualizado*
3. Sprint Burndown Chart * 2. Tres Preguntas Diarias * 2. Impediment Log
4. Impediment Log* 3. Sala de Guerra (War Room) Actualizado*
5. Product Owner 4. Video Conferencia 3. Equipo Scrum Motivado
6. Experiencia del Día Previo 4. Scrumboard Actualizado
de Trabajo 5. Solicitud de Cambio no
7. Scrumboard Aprobada
8. Dependencias 6. Riesgos Identificados
7. Riesgos Mitigados
8. Dependencias Actualizadas
La colaboración se promueve en el Equipo Scrum a través de la Reuniones Diarias (Daily Standup

Meetings). Esta es una reunión diaria de corta duración, generalmente _____ minutos como máximo.
En esta los miembros del Equipo Scrum informan su estado y sus planes para las siguientes 24 horas
al resto del equipo. Se revisa el trabajo completado desde la última Reunión Diaria y se proyecta el
trabajo que debe ser hecho antes de la siguiente Reunión.
La duración de las reuniones es muy corta y se espera que todos los miembros del Equipo Scrum
asistan. Sin embargo, la reunión no se cancela o se retrasa si uno o más miembros no pueden asistir.
En estas reuniones cada miembro del Equipo Scrum responde a estas tres preguntas específicas:
 ¿Qué terminé ayer?

 ¿Qué voy a terminar hoy?
 ¿Qué impedimentos u obstáculos (si los hay) estoy enfrentando en la actualidad?
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.
Proceso 3: Mantenimiento de los Pendientes Priorizados del Producto
Groom Prioritized Product Backlog
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.
1. Scrum Core Team* 1. Reunión de Revisión del 1. Product Backlog

2. Product Backlog Product Backlog Priorizado Priorizado Actualizado*
Priorizado* * 2. Cronograma de
3. Entregables Rechazados 2. Técnicas de Comunicación Planificación del
4. Solicitudes de Cambio 3. Otras Técnicas de Entregable Actualizado
Aprobadas Refinamiento del Product
5. Solicitudes de Cambio no Backlog Priorizado
Aprobadas
Programa Actualizado
8. Retrospect Sprint Log
9. Dependencias
10. Cronograma de
Planificación del Entregable
de Scrum
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.
Proceso 1: Convocar Scrum de Scrums

Convene Scrum of Scrums
Este proceso sólo aplica para grandes proyectos Scrum donde varios Equipos Scrum están trabajando
sincronizadamente para asegurar el progreso del proyecto. Dado que los equipos trabajan en paralelo,
asegurar que todos avancen uniformemente es un tema crítico para los plazos del proyecto. A veces,
las tareas de un equipo pueden depender de la entrega a tiempo de una tarea de otro equipo. Por lo
que tiene que existir un mecanismo que asegure que los equipos coordinen y que se comuniquen
efectivamente.
Esto se lleva a cabo normalmente mediante el ____________, que es parecido al Daily Scrum pero a
nivel de varios equipos. Esta reunión es facilitada por el Jefe Scrum Master (Chief Scrum Master) quien
también ayuda a direccionar los impedimentos que impactan a más de un equipo.
1. Reunión de Scrum de 1. Mejor coordinación de

1 Scrum Master o
Scrums (Scrum of Scrums Equipos *
Representantes del Equipo
Meeting)* 2. Incidentes Resueltos
Scrum *
2. Cuatro Preguntas por 3. Impediment Log
2. Jefe Scrum Master (Chief Equipo* Actualizado
Scrum Master) 3. Video Conferencia 4. Dependencias
4. Sala de Reunión Actualizadas
3. Jefe Product Owner (Chief
Product Owner)
de Asesoramiento de
4. Agenda de la Reunión Scrum
5. Impediment Log
6. Dependencias
7. Salidas de la Retrospectiva
del Sprint
Normalmente, un miembro de cada Equipo Scrum representará a su equipo en el Scrum of Scrums

(SoS) Meeting. En la mayoría de los casos, este es el Scrum Master, pero a veces alguien más puede
representar al equipo. Una sóla persona puede ser nominada por el equipo para que los represente en
todas las reuniones SoS, o el representante puede cambiar con el tiempo, dependiendo si hay otra
persona que pueda cumplir mejor esta función de acuerdo a los incidentes y circunstancias. La persona
que participe en la reunión debe tener el conocimiento técnico para identificar los casos en los que los
equipos podrían causar impedimentos o retrasos.
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.
Proceso 2: Demostrar y Validar el Sprint

Demostrate and Validate Sprint
En este proceso, el Equipo Scrum presenta los Entregables del Sprint (Sprint Deliverables) al Product
Owner, quien valida que esos entregables cumplan con los Criterios de Aceptación de Historias de
Usuario y el Criterio de Terminado.
La salida de la Reunión de Revisión del Sprint (Sprint Review Meeting) es la __________ o el
____________ de los elementos del backlog por el Product Owner. Los elementos no aceptados
permanecen en el Product Backlog Priorizado. Es responsabilidad del Scrum Master asegurar que el
Product Owner no cambie requerimientos o criterios de aceptación durante el Sprint o rechace un
elemento terminado del backlog porque no se satisface los nuevos cambios de requerimientos. Si el
requerimiento fue cambiado, una nueva tarea necesita ser creada para direccionar a estos cambios a
un Sprint futuro.
Solo las funcionalidades del producto que satisfacen la definición de Terminado (Done) pueden ser
presentadas, y las funcionalidades en proceso (WIP) son incluidas en un Sprint futuro. Si un entregable
no cumple con los Criterios de Aceptación no es considerado como Terminado. Los miembros del
equipo presentan el trabajo completado durante el Sprint, responden a preguntas de los Interesados y
anotan los cambios sugeridos.
1. Scrum Core Team* 1. Reunión de Revisión del 1. Entregables Aceptados *

2. Entregables del Sprint Sprint (Sprint Review 2. Entregables Rechazados
(Sprint Deliverables)* Meeting)* 3. Riesgos Actualizados
3. Sprint Backlog* 2. Análisis de Valor Ganado 4. Resultados del Análisis de
4. Criterio de Terminado 3. Juicio de Experto del Valor Ganado
(Done Criteria)* Cuerpo de Asesoramiento 5. Cronograma de
5. Criterio de Aceptación de la de Scrum Planificación del
Historia de Usuario * Entregable Actualizado
6. Interesados 6. Dependencias
7. Cronograma de Actualizadas
Planificación de la Entrega
9. Dependencias
de Scrum
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.
1. Scrum Master* 1. Reunión de Retrospectiva 1. Mejoras Viables Acordadas *

2. Equipo Scrum* del Sprint (Retrospect 2. Acciones acordadas y
3. Salidas de Demostrar y Sprint Meeting)* asignadas con fecha de
Validar el Sprint * 2. ESVP Entrega
4. Product Owner 3. Lancha Rápida (Speed 3. Elementos Non-Functional
5. Recomendaciones del Boat) propuestos para el Product
Cuerpo de Asesoramiento 4. Técnicas de Métricas and Backlog Priorizado
de Scrum Medidas 4. Registro de la Retrospectiva
5. Juicio de Experto del del Sprint (Retrospect Sprint
Cuerpo de Asesoramiento Log)
de Scrum 5. Lecciones aprendidas del
Equipo Scrum
6. Recomendaciones
Actualizadas del Cuerpo de
Asesoramiento de Scrum
Para llevar a cabo una reunión 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 propósito de la reunión y se evalúa la predisposición de los asistentes
para participar activamente.
 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.
 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.
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.
Proceso 1: Enviar los Entregables
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.
1. Product Owner * 1. Métodos de Despliegue de 1. Acuerdos de Entregables

2. Interesados * la Organización Trabajados (Working
3. Entregables Aceptados * (Organizational Deliverables Agreement)*
4. Cronograma de Deployment Methods) * 2. Entregables Trabajados
Planificación de Entrega * 2. Plan de Comunicación (Working Deliverables)
5. Scrum Master 3. Lanzamientos de Producto
6. Equipo Scrum (Product Releases)
7. Criterios de Aceptación de
Historia de Usuario
8. Plan Piloto
de Scrum
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.
1. Scrum Core Team(s)* 1. Reunión de la 1. Mejoras viables acordadas*

2. Jefe Scrum Master Retrospectiva del Proyecto 2. Acciones acordadas y
3. Jefe Product Owner (Retrospect Project asignadas con fecha de
4. Interesados) Meeting)* Entrega*
5. Recomendaciones del 2. Otras herramientas para la 3. Elementos Non-Functional
Cuerpo de Asesoramiento Retrospectiva del Proyecto propuestos para el Product
de Scrum 3. Juicio Experto del Cuerpo Backlog Priorizado y para el
de Asesoramiento de Program Product Backlog
Scrum 4. Recomendaciones
Actualizadas del Cuerpo de
Asesoramiento de Scrum
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.
2. ¿Cuál de las siguientes es la definición de una historia de usuario?

A. Una declaración que describe la visión del producto.
B. Un documento que describe la prioridad de tareas a realizar en el proyecto.
C. Una declaración que expresa la funcionalidad para el usuario final deseado.
D. Una historia que proporciona información sobre tareas similares completado en anteriores
proyectos de implementación de Scrum.
3. ¿Cómo se organizan los elementos de la Pila de Producto Priorizada (Prioritized Product

Backlog)?
A. Los artículos más pequeños están en la cima.
B. Los elementos con menos interdependencias están en la parte superior.
C. Los elementos más complejos están en la cima.
D. Los elementos con el mayor valor de negocio están en la cima.
4. ¿Quién es el responsable de crear historias de los usuarios en el proceso Crear Historias

de usuario?
A. Scrum Master
B. Product Owner
C. Equipo Scrum
D. Interesados
5. La responsabilidad de la estimación de los elementos de la Pila de Producto Priorizada

(Prioritized Product Backlog) en la fase de Planificación y Estimación recae en el
A. Equipo Scrum
B. Scrum Master
C. Product Owner
D. Equipo externo experimentado
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
7. ¿Con qué frecuencia se cambian las prioridades de la Pila de Producto Priorizada

(Prioritized Product Backlog)?
A. Nunca.
B. Siempre que el Product Owner decide que un elemento tiene que ser tener una
mayor prioridad.
C. Siempre que el Scrum Master cree que un elemento tiene que ser añadido.
D. Cuando la alta dirección se siente que un elemento tiene que ser añadido.
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
9. ¿Cuál de las siguientes afirmaciones NO es verdadera?
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).
15. La reunión al final del Sprint en el que el equipo presenta su trabajo al Product Owner es
conocido como la:
16. La reunión en la que el equipo analiza el Sprint anterior e identifica mejoras potenciales
en los procesos se conoce como la:
17. Durante la reunión de revisión de Sprint (Sprint Review Meeting):

A. El equipo presenta el producto final entre sí.
B. El Scrum Master puede aceptar o rechazar la entrega del producto final.
C. El equipo presenta la entrega del producto final al Product Owner.
D. Cada miembro del equipo puede aceptar o rechazar la entrega del producto final.
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.
20. La responsabilidad de la preparación de la Pila de Producto priorizada (Prioritized Product

Backlog) recae en el
A. Product Owner (propietario del producto).
B. Scrum Master.
C. Equipo Scrum.
D. Los interesados externos.
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
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
25. Los Criterios Aceptación:

A. Incrementan la ambigüedad de los requerimientos.
B. Ayudan al equipo se ceñirse a las normas de calidad relacionadas con la funcionalidad.
C. Son determinados por el Scrum Master en colaboración con los miembros del equipo.
D. Son determinados por el Scrum Master en colaboración con el Product Owner (propietario
del producto).
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)
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.
Scrum en Programas y Portafolios.
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.
La siguiente figura ilustra cómo el método Scrum se puede utilizar en toda la organización para los
Portafolio, Programa o Proyectos.
Scrum en toda la organización para Proyectos, Programas y Portafolios

Trabajando con Equipos de Programas y Portafolios
Al aplicar Scrum para gestionar proyectos en el marco de un Programa o un Portafolio se recomienda

que los principios generales de Scrum que se presentan en el SBOKTM se cumplan. Se entiende, sin
embargo, que con el fin de cumplir con el Programa en su totalidad o las actividades relacionadas con
el Portafolio e interdependencias, pueden ser necesarios pequeños ajustes en el conjunto de
herramientas, así como en la estructura organizacional.
Los Portafolios y Programas tienen equipos separados y con diferentes objetivos. Los equipos de
gestión de Programa tienen por objetivo ofrecer capacidades y llevar a cabo ciertas metas que
contribuyan a objetivos específicos del Programa. Por el contrario, el equipo de Portafolio tiene que
equilibrar los objetivos de los distintos Programas para alcanzar los objetivos estratégicos de la
organización en su totalidad.
La gestión de comunicación con los equipos de Portafolio y Programas
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.
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.
La Figura ilustra la dinámica de las reuniones Scrum of Scrums (SoS)
Reunión de Scrum of Scrums (SoS)
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.
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.
Mantenimiento de la Participación de los Interesados

Scrum requiere gran apoyo por parte de los interesados del proyecto. Las siguientes son las acciones
recomendadas para el mantenimiento de la participación y el apoyo de los interesados.
 Establecer un acuerdo de trabajo con los interesados para promover su colaboración y

participación efectiva.
 Evaluar continuamente los cambios del proyecto que afectan a los interesados para asegurar
que nuevos interesados del proyecto estén comprometidos.
 Mantener una comunicación regular con los interesados.

 Administrar las expectativas de los interesados.
Importancia del Soporte Ejecutivo

Los ejecutivos son las personas que __________ el proyecto. Por tanto, para que cualquier proyecto
de Scrum sea exitoso, los ejecutivos deben apoyarlo. Para conservar el apoyo ejecutivo:
 Comuníquese regularmente con los ejecutivos.

 Mantenga a los ejecutivos informados de los últimos avances.
 Informe a los ejecutivos de cualquier conflicto o retrasos potenciales en la entrega del proyecto
para minimizar el impacto.
Es importante que los ejecutivos que financian el proyecto tengan claridad respecto a los siguientes
temas:
 ¿Cuál es el beneficio de implementar el Método Scrum?

o ¿Cómo este cambio crea __________ y / o evita ____________ para la organización?
o ¿Cuán imprescindible es adaptarser al actual ambiente de negocios?
 ¿Cuáles son los plazos límite y costos de la transición?
o ¿Cuál es el tiempo estimado para completar la trascición y cuál es el costo de la
transición?
o ¿Cuáles son los hitos principales para realizar la transición?
o ¿Qué tan frecuentemente los ejecutivos se va a reunir para revisar el avance del
proyecto?
 ¿Cuáles son los riesgos que involucra la transición?
o ¿Cuáles son obstáculos o riesgos potenciales en la implementación?
o ¿Cuál es el costo y tiempo adicional requerido para mitigar cada uno de estos riesgos?
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.
2. ¿Cuál de los siguientes es parte de la Scrum de Scrums?

A. Resumen de las tareas a realizar en el Sprint.
B. Si alguna de tus decisiones podrían afectar a otros equipos.
C. Hablar de los problemas que pueden haber surgido para cualquiera de los equipos de
Scrum.
D. Resolución de Impedimentos que pueden haber surgido.
3. ¿Cuál de las siguientes afirmaciones es FALSA respecto a Scrum en equipos grandes?

A. Los equipos grandes tienen Jefe de Scrum Masters y Jefe de Product Owners para
controlar el progreso del proyecto.
B. El Jefe de Product Owner es responsable de la asignación de recursos.
C. El Jefe de Product Owner facilita el Scrum de Scrums.
D. El Jefe de Product Owner es responsable del éxito o fracaso del proyecto.
4. ¿Cuál de las siguientes es la responsabilidad del Product Owner del programa?

A. Comunicar las metas y objetivos de Sprint a los miembros del Equpo Scrum.
B. Definir los objetivos y prioridades estratégicas para el Programa.
C. Establecer los criterios mínimos de terminado de los equipos.
D. Resolver problemas, eliminando los obstáculos, facilitar y realizar reuniones para el
programa.
5. ¿Cuál de los siguientes procesos garantiza la sincronización y facilita el flujo de

información entre varios equipos Scrum que trabajan en paralelo en grandes proyectos
Scrum?
A. Convocar Scrum de Scrums.
B. Ejecutar la Reunión Diaria.
C. Retrospectiva del Proyecto.
D. Retrospectiva del Sprint.

SMC Cuaderno de Trabajo

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SMC Cuaderno de Trabajo

Cargado por

Copyright:

Formatos disponibles

© 2016 SCRUMstudy.

Reglas Básicas del Taller

Objetivos del Curso

Resultados del Curso

Metodología del Curso

Membresía Avanzada – Cuota Anual

Acerca del Examen de Certificación SMCTM Certification Exam

El gran interés por Agile

The Agile Manifesto

Los individuos y Procesos y

Es decir, mientras que hay valor en los elementos de

Kent Beck James Grenning Robert C. Martin

Principios de Agile Manifesto

3. Entregamos software funcional de manera frecuente, entre dos semanas y dos

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que brindarles

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo

7. El software funcionando es la medida principal del avance del proyecto.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

Feature Driven Development (FDD)

Test Driven Development (TDD)

Adaptive Software Development (ASD)

Agile Unified Process (AUP)

Domain-Driven Design (DDD)

El énfasis está en Personas Procesos

Documentación Sólo mínima según se requiera Exhaustivo

Estilo de Procesos Iterativo Lineal

Planificación por Adelantada Baja Alta

Prioritización de los Según el valor del negocio y

Garantía de Calidad Centrada en el Cliente Centrada en el Proceso

Organización Auto-organizada Gestionada

El Estilo de Gestión Descentralizado Centralizado

Las actualizaciones de Sistema formal de Gestión del

Liderazgo Colaborativo, Líder Servicial Mando y control

La Medición del Rendimiento El valor del negocio Plan de la Conformidad

Al comienzo y a lo largo del

Varía en función del ciclo de

Scrum vs Método Tradicional

3. ¿Cuál de los siguientes NO es parte del Manifiesto Ágil?

4. Como jefe de proyecto empleando prácticas Ágiles en su organización, ¿cuál de los

5. ¿Cuál de los siguientes NO es verdadero con respecto a las metodologías Ágiles?

*Reference: SBOKTM Guide 2013, p. 4-5

3. ¿En cuál de los siguientes entornos proyectos Scrum NO son aplicables?

4. ¿Cuál es el resultado respecto al desarrollo de productos utilizando Scrum?

5. La entrega priorizada en Scrum significa que:

Los roles de Scrum se dividen en dos categorías:

Voz del Cliente - Voice of the Customer (VOC)

 Interno (dentro de la misma organización)

 Externo (fuera de la organización)

 Define la Visión del Proyecto

 Ayuda a determinar los miembros del Equipo Scrum

Develop Epic(s)  Crea Epic(s) y Personas

 Prioriza los elementos del Product Backlog (cartera de

Create Deliverables  Aclara los Requisitos del Negocio al Equipo Scrum

Groom Prioritized Product  Refina la Product Backlog y reprioriza si es necesario

 Acepta / Rechaza los Entregables

Retrospect Project  Participa en las Reuniones de Retrospectiva del Proyecto

 Ayuda a determinar los miembros del Equipo Scrum

Develop Epic(s)  Facilita la creación de Epic(s) y Personas

 Coordina la creación del Cronograma de Planificación de las