SMC Cuaderno de Trabajo

2014 SCRUMstudy.com v4.
1
INTRODUCCIN
Reglas Bsicas del Taller

Est es una clase de tres das y cada da tendr 5 horas de clase.
Los participantes debern estar en el aula de clases a tiempo y regresar puntualmente luego
de los descansos de 15 minutos.
Los telfonos celulares debern estar apagados o estar en modo de silencio.
Se espera una completa participacin por parte de los participantes. nase a las actividades y
ejercicios de acuerdo a las indicaciones del docente. Advertencia de hecho podra divertirse
en este taller!
Los materiales y recursos de estudio que utilizarn los participantes tienen derechos de autor
y son propiedad absoluta de SCRUMstudy y PM Certifica. No debern ser fotocopiados,
distribuidos o compartidos y debern ser utilizados nicamente por los participantes que se
hayan inscrito en el aula de capacitacin del Taller de Preparacin para la Certificacin SMC.
Objetivos del Curso

Proveer el entendimiento de la filosofa y principios Scrum.
Proveer conocimiento prctico de Scrum, incluyendo los roles, reuniones y artefactos.
Preparar a los participantes para sentirse cmodos al implementar Scrum en sus
organizaciones as como tambin manejar conflictos y obstculos comunes.
Resultados del Curso

Los estudiantes reconocern, definirn y trabajarn con facilidad los conceptos, ventajas y
retos del Marco de Trabajo de Scrum.
Los participantes estarn preparados para desempear el rol de Scrum Master en sus
organizaciones y ayudar a sus organizaciones a adoptar el Marco de Trabajo Scrum.
Los participantes participarn en dinmicas en las cuales llevarn a cabo un proyecto Scrum.
Los participantes obtendrn conocimientos para anticipar conflictos relacionados a la
implementacin de Scrum.
Los participantes contarn 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 lnea.
Metodologa del Curso

La metodologa asegura una alta retencin de los conceptos y teoras.
Se motiva a los participantes a poner en prctica los conceptos ms que a solamente
escucharlos esto provee una mejor internalizacin y retencin.
Se llevarn a cabo dinmicas prcticas y se discutirn los problemas comunes de
implementacin de todas las partes del flujo Scrum.
Los participantes ponen en prctica un caso de estudio para simular el desarrollo del producto
utilizando el Marco de Trabajo Scrum.
2014 SCRUMstudy.com 1
Acerca de SCRUMstudy
SCRUMstudy es la entidad de certificacin global para las certificaciones Scrum y Agile. Una
gran cantidad de informacin acerca de SCRUMstudy y sus programas de certificacin y
membresa est disponible en SCRUMstudy.com. En la parte inferior se proporciona un
resumen de las certificaciones que otorga SCRUMstudy.
ESMCTM SCTTM
Expert Level Expert Scrum SCRUMstudy
Master
Certified
SMCTM SPOCTM AECTM

Intermediate Level Scrum Master Scrum Product Agile Expert
Certified Owner Certified Certified
SDCTM
Foundation Level
Scrum Developer Certified
Membresa Bsica - Gratuita
Esta membresa provee acceso a las principales pginas de informacin, foros de discusin general y
blogs limitados y recursos en lnea. Los candidatos a la certificacin deben tener por lo menos una
Membresa Bsica para poder dar un examen de certificacin de SCRUMstudy.
Membresa Avanzada Cuota Anual

La Membresa Avanzada provee acceso a foros de discusin y recursos en lnea adicionales, adems
de descuentos en el precio del examen.
Acerca del Examen de Certificacin SMCTM Certification Exam

Formato del Examen
Eleccin Mtiple
100 preguntas por examen
Un punto otorgado por cada respuesta correcta
No hay puntos negativos por respuestas errneas
120 minutos de duracin
Examen en lnea supervisado
Tasa de Aprobacin Actual: 95%
RESUMEN DE AGILE
El trmino agile (gil) generalmente se refiere a ser capaz de moverse o responder rpidamente y
fcilmente. En cualquier tipo de disciplina de gestin, ser gil es una cualidad, por lo tanto esto debe
ser una meta que se debe tratar de alcanzar. La gestin de Proyectos Agile especialmente, implica la
adaptabilidad durante la creacin de un Producto, Servicio o cualquier otro Resultado.
Es importante entender que a pesar de que el desarrollo de los mtodos giles es altamente adaptable,
de todos modos es necesario tener en cuenta la estabilidad en sus procesos de adaptacin.
El gran inters por Agile

Agile se basa en la planificacin de adaptacin en el desarrollo y la entrega iterativa. Se centra
principalmente en que el equipo ejecute el trabajo con eficacia. Aunque las metodologas adaptivas e
incrementales han existido desde la dcada de 1950, slo las metodologas que se ajustan a El
Manifiesto gil son generalmente consideradas verdaderamente como "gil".
The Agile Manifesto

El propsito de The Agile Manifesto fue distribuido de la siguiente manera:
Estamos descubriendo mejores formas de desarrollar
software hacindolo y ayudando a que otros lo hagan.
A travs de este trabajo hemos llegado a valorar:
Los individuos y Procesos y

las Interacciones Herramientas
Software Documentacin
Funcionando Extensiva
Colaboracin Negociacin
con el Cliente Contractual
Respuestas ante Seguir un Plan
el cambio
Es decir, mientras que hay valor en los elementos de

la derecha, valoramos ms 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 documentacin extensiva
3. Colaboracin con el Cliente sobre la negociacin 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 tardas 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 ms 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 ejecucin del trabajo.
6. El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo

y entre sus miembros es la conversacin 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 atencin continua a la excelencia tcnica y al buen diseo 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 diseos emergen de equipos auto-

organizados.
12. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para que
como consecuencia procedan a ajustar y perfeccionar su comportamiento.
Mtodos Agile
Una serie de metodologas giles se crearon y ganaron fuerza en la dcada de 1990 y principios del
2000. Si bien difieren en una variedad de aspectos, lo que tienen en comn se deriva de su adhesin
a The Agile Manifesto.
Los siguientes mtodos giles se discuten brevemente a continuacin:
1. Lean Kanban
2. Extreme Programming (XP)
3. Crystal Methods
4. Dynamic Systems Development Methods (DSMD)
5. Feature Driven Development (FDD)
6. Test Driven Development (TDD)
7. Adaptive Software Development (ASD)
8. Agile Unified Process (AUP)
9. Domain-Driven Design (DDD)
Lean Kanban
El concepto de Lean optimiza el sistema de una organizacin para producir resultados valiosos sobre
la base de sus recursos, necesidades y alternativas, mientras reduce las prdidas. Las prdidas, por
ejemplo, podran ser la construccin incorrecta de un Producto, el no saber aprender, o las prcticas
que impiden que el proceso fluya. Debido a que estos factores son de naturaleza dinmica, una
organizacin gil evala la totalidad de su sistema y continuamente hace ajustes a sus procesos. El
fundamento de Lean es que la reduccin de la duracin de cada ciclo (es decir, una iteracin) conduce
a un aumento de Productividad mediante la reduccin de los retrasos, ayuda en la deteccin de errores
en una etapa temprana, y en consecuencia reduce la cantidad total de esfuerzo requerido para terminar
una tarea. Los principios de software Lean se han aplicado con xito en el desarrollo de software.
Kanban significa literalmente un "cartel" o "cartelera y enfatiza el uso de ayudas visuales para ayudar
y realizar un seguimiento de la produccin. El concepto fue introducido por Taiichi Ohno, considerado
como el padre de los sistemas Toyota Proudction Systems (TPS).
Extreme Programming
Extreme Programming (XP), que se origin en Chrysler Corporation, gan fuerza en la dcada de
1990. XP hace que sea posible mantener el costo de cambiar el software sin que ste aumente
radicalmente con el tiempo. Los atributos claves de XP incluyen el desarrollo gradual, horarios flexibles,
pruebas automatizadas de cdigo, la comunicacin verbal, el diseo en constante evolucin,
Colaboracin cercana y la vinculacin de las unidades, de largo como de corto plazo, de todos los
involucrados.
Crystal Methods
Las metodologas de desarrollo de software Crystal fueron presentadas por Alistair Cockburn a
principios de 1990. Los mtodos Crystal se centran en las personas, son ligeros y fciles de adaptar.
Porque la gente es lo primordial, los procesos y las herramientas de desarrollo no son fijos sino que se
ajustan a las necesidades y caractersticas especficas del Proyecto.
Todos los mtodos de Crystal tienen cuatro roles patrocinador, diseador principal, desarrolladores
y usuario experto. Los mtodos Crystal recomiendan diversas estrategias y tcnicas para lograr
agilidad. Un ciclo de proyectos Crystal consta de grficos, ciclo de entrega y de recapitulacin.
Dynamic Systems Development Methods (DSDM)
El marco Dynamic Systems Development Methods (DSDM) se public inicialmente en 1995 y es
administrado por el Consorcio DSDM. DSDM establece la calidad y el esfuerzo en trminos de costo y
el tiempo desde el principio y ajusta los entregables del proyecto para cumplir con los criterios
establecidos, dando prioridad a las prestaciones en las siguientes categoras: lo que "deben tener",
"deberan tener", "podran tener", y "no tendrn" (mediante la tcnica Priorizacin MoSCoW). DSDM
es un mtodo orientado al sistema con seis distintas fases de pre-proyecto; Viabilidad; Fundamentos;
Exploracin e Ingeniera; Despliegue y Evaluacin de Beneficios.
Feature Driven Development (FDD)

Feature Driven Development (FDD) fue presentado por Jeff De Luca en 1997 y opera bajo el principio
de la realizacin de un proyecto donde ste se separa en pequeas 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)

Tambin 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 mtodo
de desarrollo de software que consiste en escribir primero un cdigo de prueba automatizado y en el
desarrollo de la menor cantidad de cdigos necesarios para luego pasar la prueba.
Adaptive Software Development (ASD)

Adaptive Software Development (ASD) surgi a partir de la rpida labor de desarrollo de aplicaciones
por Jim Highsmith y Sam Bayer. Los aspectos ms destacados de los ASD son Adaptacin 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 tcnicas giles de la industria ya probadas como Test
Driven Development (TDD), Agile Modeling, gestin 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 intencin de manejar diseos
complejos con aplicacin vinculada a un modelo en evolucin. Fue concebido por Eric Evans en el ao
2004 y gira en torno al diseo de un dominio bsico.
Scrum vs Gestin de Proyectos Tradicional
En la tabla se resumen muchas de las diferencias entre los modelos tradicionales de gestin de
proyectos y Scrum.
Gestin de Proyectos
Enfoque Scrum
Tradicional
El nfasis est en Personas Procesos
Documentacin Slo mnima segn se requiera Exhaustivo
Estilo de Procesos Iterativo Lineal
Planificacin por Adelantada Baja Alta
Prioritizacin de los Segn el valor del negocio y

Fijo en el plan de proyecto
Requisitos regularmente actualizada
Garanta de Calidad Centrada en el Cliente Centrada en el Proceso
Organizacin Auto-organizada Gestionada
El Estilo de Gestin Descentralizado Centralizado
Las actualizaciones de Sistema formal de Gestin del

Cambio
Prioritized Product Backlog Cambio
Liderazgo Colaborativo, Lder Servicial Mando y control
La Medicin 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
Vara en funcin del ciclo de

Participacin 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 correccin a medida que todas las
personas involucradas obtengan una mejor comprensin de lo que debe ser entregado como parte del
proyecto, e incorporen lo aprendido de manera iterativa. As, el tiempo y el esfuerzo requerido para
alcanzar el punto final definitivo, se reduce considerablemente y el equipo produce entregables que se
adaptan mejor al entorno empresarial.
Lanzamiento
Scrum vs Mtodo Tradicional
Captulo Visin de Agile y Scrum - Preguntas
1. Cul de las siguientes NO es una caracterstica comn de la gestin adaptativa de
proyectos?
A. Desarrollo iterativo del producto
B. Alto esfuerzo en la planificacin adelantada (al inicio del proyecto)
C. Reduce el tiempo de lanzamiento al mercado
D. Entrega del producto flexible
2. Usted es el CEO de una empresa que maneja cuatro proyectos diferentes. En qu

proyecto implementara metodologas giles?
A. Construccin de un edificio de departamentos multifamiliares de 5 plantas con 6
departamentos por piso.
B. Trabajo en la dcima etapa de un proyecto de implementacin 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 gestin del
cambio que implica la identificacin de las prcticas del estado actual y el desarrollo de
una hoja de ruta para el proceso del estado futuro en funcin de la visin del equipo de
gestin.
D. La construccin de un automvil en una fbrica basada en un prototipo desarrollado con
anterioridad.
3. Cul 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 ms importante que la documentacin extensa.
4. Como jefe de proyecto empleando prcticas giles en su organizacin, cul de los

siguientes principios NO empleara?
A. Empleados del negocio y tcnicos 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 comunicacin cara a cara.
D. Recibir cambios de requerimientos, incluso tarde en el desarrollo.
5. Cul de los siguientes NO es verdadero con respecto a las metodologas giles?

A. Se enfoca en las personas en lugar de los procesos.
B. Promueve la documentacin mnima, a diferencia de la tcnica de Cascada.
C. Recomienda un estilo de liderazgo basado en comando y control.
D. Se centra en la capacidad de adaptacin del proyecto.
INFORMACIN GENERAL DE SCRUM
Scrum es una de las metodologas giles ms populares. Emplea un enfoque adaptativo e iterativo
para gestionar proyectos y desarrollo de productos. Ha sido diseada para ser una manera rpida,
flexible y eficaz para ofrecer _____ significativo de forma _________ en todo el proyecto.
El marco de Scrum, tal como se define en la Gua SBOK, puede ser mejor entendido a travs de sus
principios, procesos y aspectos.
Principios Scrum
1. Control del Proceso Emprico Scrum establece que la toma de decisiones basada en la
observacin y experimentacin es mejor que la planificacin detallada al inicio del proyecto.
2. Auto-organizacin Este principio se centra en los miembros del equipo, quienes entregan
un valor significativamente mayor cuando son auto-organizados, lo cual genera equipos muy
comprometidos y con un alto nivel de responsabilidad; a su vez, esto produce un entorno
innovador y creativo que es ms propicio para el crecimiento.
3. Colaboracin Este principio se centra en las tres dimensiones bsicas relacionadas con el
trabajo colaborativo: conciencia, articulacin y apropiacin.
4. Priorizacin basada en el valor Este principio pone de relieve el enfoque de Scrum para
ofrecer el mximo valor de negocio, desde el principio del proyecto hasta su conclusin.
5. Time-boxing Este principio describe cmo el tiempo es considerado como una restriccin
limitante en Scrum, y cmo se utiliza para ayudar a manejar eficazmente la planificacin y
ejecucin del proyecto.
6. Desarrollo Iterativo Este principio define el desarrollo iterativo y enfatiza cmo manejar
mejor los cambios y crear productos que satisfagan las necesidades del Cliente. Tambin
delinea las responsabilidades del Product Owner y de la organizacin relacionadas con el
desarrollo iterativo.
Un principio esencial de Scrum es que los requerimientos de cualquier proyecto de largo plazo no
pueden ser entendidos completamente o definidos al inicio del proyecto, especialmente si el mercado
sufre cambios constantemente, por lo que este enfoque debe permitir que el equipo sea flexible para
incorporar cambios de requerimientos. En el enfoque tradicional, el mtodo predictivo de desarrrollo
no puede manejar tales cambios. En cambio, Scrum es especialmente til para proyectos complejos
con gran ____________ en los cuales los pronsticos de largo plazo podran conllevar a riesgos
crticos.
Scrum gua a travs de la transparencia, inspeccin y adaptacin para alcanzar los resultados ms
valiosos de negocio.
Aspectos Scrum
Los aspectos de Scrum se deben abordar y gestionar a lo largo de un proyecto Scrum. Los cinco
aspectos de Scrum son:
1. Organizacin
2. Justificacin de Negocio
3. Calidad
4. Cambio
5. Riesgo
Procesos de Scrum
Los procesos de Scrum abordan las actividades y el flujo especfico de un proyecto Scrum. En total
hay diecinueve procesos que se agrupan en cinco fases.
El trmino "Producto" en la Gua SBOK puede referirse a un Producto o, Servicio, o cualquier otra
prestacin. Scrum se puede aplicar de manera efectiva a cualquier proyecto en cualquier industria-
desde proyectos pequeos o equipos con tan slo seis miembros, hasta proyectos grandes y complejos
con varios cientos de miembros por equipo.
Por qu utilizar Scrum?*
Algunas de las ventajas principales de la utilizacin de Scrum en cualquier proyecto son:
1. ______________ El Control del Proceso Emprico y la Entrega Iterativa hacen que los
proyectos sean adaptables y abiertos a la incorporacin de cambios.
2. ______________ Todos los radiadores de informacin tales como el Scrumboard y el Sprint
Burndown Chart son compartidos, lo que promueve un ambiente de trabajo abierto.
3. _________________ Continua Se proporciona a travs de los procesos: Ejecutar
Reuniones Diarias y Demostrar y Validar.
4. ___________ Continua Los entregables se mejoran progresivamente Sprint por Sprint a
travs del proceso de Mantenimiento del Product Backlog.
5. Entrega Continua de Valorlos procesos iterativos permiten la entrega continua de valor tan
frecuentemente como el Cliente lo requiere a travs del proceso Enviar los Entregables.
6. Ritmo Sostenible Los procesos Scrum estn diseados de tal manera que las personas
involucradas pueden trabajar a un mismo ritmo que, en teora, se puede continuar
indefinidamente.
7. Entrega Temprana de Alto ValorEl proceso de Crear el Product Backlog Priorizado
asegura que los requisitos de mayor valor del Cliente sean los primeros en satisfacerse.
8. Proceso de Desarrollo Eficiente El time-boxing y la reduccin al mnimo el trabajo que no
es esencial conduce a mayores niveles de eficiencia.
9. MotivacinLos procesos de Ejecutar la Reunin Diaria y la Retrospectiva del Sprint
conducen a mayores niveles de motivacin entre los empleados.
10. Resolucin de Problemas de forma ms Rpida Colaboracin y la coubicacin de equipos
multi-funcionales conducen a la resolucin de problemas con mayor rapidez.
11. Entregables EfectivosEl procesos de Crear el Product Backlog Priorizado y revisiones
peridicas despus de la creacin de entregables asegura entregas efectivas para el Cliente.
12. Centrado en el Cliente El poner nfasis en el valor del negocio y tener un enfoque de
colaboracin con los interesados asegura un marco orientado al Cliente.
13. Entorno de Alta ConfianzaLos procesos de Ejecutar la Reunin Diaria y la Retrospectiva
del Sprint promueven transparencia y colaboracin, dando lugar a un ambiente de trabajo de
alta confianza, asegurando as una baja friccin entre los empleados.
14. Responsabilidad ColectivaEl proceso de Aprobar, Estimar y Comprometerse con Historias
de Usuario permite que los miembros del equipo se sientan responsables del proyecto, as su
trabajo tiene una mejor calidad.
15. Alta VelocidadUn marco de colaboracin que le permite a los equipos multi-funcionales
altamente calificados alcanzar su potencial y alta velocidad.
16. Medio Ambiente InnovadorLos procesos Retrospectiva del Sprint y Retrospectiva del
Proyecto crean un ambiente de introspeccin, aprendizaje y capacidad de adaptacin que lleva
a un entorno de trabajo innovador y creativo.
*Reference: SBOKTM Guide 2013, p. 4-5
Captulo Visin General Agile y Scrum - Preguntas
1. El control del proceso emprico es un principio de Scrum que:
A. Es utilizado en casos en los que las entradas estn claramente definidas.
B. Se centra en proporcionar control a travs de inspecciones y adaptaciones frecuentes de
los procesos que estn perfectamente definidos.
C. Se utiliza en situaciones en las que los procesos generan salidas impredecibles e
irrepetibles.
D. Se utiliza cuando una entrada particular ofrece siempre una salida especfica.
2. Todos los siguientes son parte de los principios del Scrum EXCEPTO:
A. La auto-organizacin
B. Time-boxing
C. Priorizacin basada en valor
D. Control de procesos definidos
3. En cul 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 voltiles y hipercompetitivos
D. Ninguna de las anteriores
4. Cul 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 caractersticas que ofrecen el mximo valor comercial se desarrollan primero
D. Todas las anteriores
5. La entrega priorizada en Scrum significa que:

A. Las caractersticas que son las ms simples y no requeriran mucha participacin por parte
del equipo se completarn primero.
B. Las caractersticas con la menor o interdependencia nula se completarn primero para
asegurar la entrega sin problemas ni interrupciones.
C. Las caractersticas que proporcionan el mximo valor comercial se completarn primero.
D. Las caractersticas 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 categoras:
Core RolesLos Core Roles son las funciones que obligatoriamente se requieren para producir
el producto o servicio del proyecto, estos estn ____________ con el proyecto, y son los
responsables del xito de cada Sprint y del proyecto en su totalidad.
Non-core Roles: son las funciones que no son obligatoriamente necesarias para el proyecto
Scrum, y pueden incluir miembros de los equipos que estn interesados en el proyecto, pero no
tienen ningn papel formal en el equipo del proyecto. Ellos pueden interactuar con el equipo, pero
no son responsables del xito del proyecto. Estos roles no esenciales tambin deben tenerse en
cuenta en cualquier proyecto de Scrum.
Core Roles
Hay tres Core Roles (roles/funciones principales) en Scrum que son los responsables de cumplir con
los objetivos del proyecto. Los core roles son el Product Owner, Scrum Master, y el Equipo Scrum.
Juntos se les conoce como el Equipo Central/Principal de Scrum (Scrum Core Team). Es importante
tener en cuenta que, de estos tres roles, ninguno tiene autoridad sobre los otros.
La figura presenta un resumen de los roles principales del Equipo Core de Scrum.
Core Role: Product Owner (Dueo del Producto)
El Product Owner representa a los interesados y es responsable de asegurar que el Equipo Scrum
entregue valor, a travs del producto, al proyecto. El Product Owner escribe los requerimientos de
negocio en la forma de ________________ con apoyo de los miembros del Equipo Core Scrum;
tambin gestiona el Product Backlog (cartera de pendientes) en el proceso Priorizar el Product Backlog.
En algunos casos, los miembros del Equipo Scrum podran escribir las User Stories (Historias de
Usuario) bajo la supervisin del Product Owner. El Product Owner es tambin responsable de asegurar
la comunicacin clara de las funcionalidades del producto al Equipo Scrum, por lo que tambin es
conocido como la ___________________.
De la misma forma que existe un rol de Product Owner en un proyecto, podra haber un Product Owner
del Programa en un Programa, o un Product Owner del Portafolio en un Portafolio.
Voz del Cliente - Voice of the Customer (VOC)

El cliente es el interesado ms importante para cualquier compaa. 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 disear
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 podra ser:
Interno (dentro de la misma organizacin)
Externo (fuera de la organizacin)

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

Create Project Vision Ayuda a crear el Acta de Constitucin 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 Colaboracin
Form Scrum Team Ayuda a desarrollar el Plan para la Formacin 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 Planificacin de Entregas
Conduct Release Planning (Releases)
Ayuda a determinar la duracin del Sprint
Ayuda a crear Historias de Usuarios
Create User Stories Define el Criterio de Aceptacin para cada Historia de
Usuario
Aprueba los Historias de Usuarios que se harn 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 orientacin y aclaracin al Equipo Scrum sobre
Estimate Tasks la estimacin 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 retroalimentacin al Scrum Master y al Equipo
Demonstrate and Validate Scrum
Sprints Actualiza el Plan de Entregas (Releases) y la Priorizacin
del Product Backlog
Ayuda con el lanzamiento de las Entregas de Producto y se
Ship Deliverables encarga de la coordinacin 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 gestin de proyectos avance sin problemas y
que los miembros del Equipo Scrum tengan todas las herramientas necesarias para hacer su trabajo.
El rol del Scrum Master se basa en el concepto de ________________ en el cual los lderes logran
resultados atendiendo a las necesidades de aquellos a quienes lideran.
De la misma forma que existe un rol de Scrum Master en un proyecto, podra haber un Scrum Master
del Programa en un Programa, o un Scrum Master del Portafolio en un Portafolio.
La tabla resume las responsabilidades del Scrum Master en los diferentes procesos de Scrum.
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 Colaboracin y el Plan para la
Form Scrum Team Formacin del Equipo
Asegura que los recursos de respaldo estn disponibles para el
funcionamiento del proyecto sin problemas
Develop Epic(s) Facilita la creacin de Epic(s) y Personas
Create Prioritized Product Ayuda al Product Owner en la creacin del Product Backlog
Backlog Priorizado y en la definicin de los Criterios de Terminado
Coordina la creacin del Cronograma de Planificacin de las

Conduct Release Planning Entregas (Releases)
Determina el duracin del Sprint con el Product Owner
Apoya al Equipo Scrum en la creacin de Historias de Usuarios y

Create User Stories sus Criterios de Aceptacin
Approve, Estimate and Facilita reuniones del Equipo Scrum para estimar y Crear
Commit User Stories Historias de Usuarios
Facilita al Equipo Scrum en la creacin de la Lista de Tareas

Create Tasks para el siguiente Sprint
Ayuda al Equipo Scrum en la estimacin 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 Grfico Sprint Burndown
Apoya al Equipo Scrum en la creacin 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 revisin 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 presentacin de los Entregables ya completados por el

Sprints Equipo Scrum para la aprobacin 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 comprensin de los
requerimientos de negocio especificados por el Product Owner, de la estimacin de Historias de
Usuarios y de la creacin de los _________________ del proyecto.
Caractersticas 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 microgestin de las tareas llevadas a cabo por un jefe.
Multi-funcionales:
El uso de equipos multi-funcionales tambin 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 diseada para optimizar la flexibilidad y la productividad.
Un equipo multi-funcional est ms enfocado en un objetivo comn.
Coubicacin y comunicacin cara a cara:
Scrum permite la creacin de equipos auto-organizados fomentando la coubicacin de todos

los miembros y recomienda la comunicacin cara a cara entre todos los miembros.
Un equipo coubicado conformado por expertos funcionales que colaboran para alcanzar un
objetivo comn tendr mayor probabilidad de xito que un equipo que trabaja separado
fsicamente de acuerdo a la funcin que realiza.
Cuando un Equipo Scrum necesita ser distribuido, el Scrum Master debe garantizar que las
tcnicas de comunicacin eficaces estn disponibles para que los equipos puedan auto-
organizarse y trabajar con eficacia.
Entrega Iterativa de Producto:
Los equipos Scrum entregan productos de forma iterativa e incremental, maximizando

oportunidades para la retroalimentacin.
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 informacin para la creacin del Plan de Colaboracin y para

Form Scrum Team el Plan para la Formacin 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 duracin del
Sprint.
Conduct Release Planning Solicita aclaracin de los nuevos productos o cambios al producto
existente en el Product Backlog Priorizado y Refinado.
Brinda informacin al Product Owner para la creacin 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 grfico Sprint Burndown
Crea Entregables.
Identifica riesgos e implementa acciones de mitigacin a los riesgos si
Create Deliverables es necesario.
Actualiza el Registro de Impedimentos y sus dependencias.
Actualiza el grfico Sprint Burndown, el Scrumboard y el Registro de
Impedimentos.
Discute problemas que enfrentan los miembros y busca soluciones
Conduct Daily Standup para motivar al equipo.
Identifica riesgos si existiesen.
Presenta solicitudes de cambio si se requiere.
Groom Prioritized Product Participa en las reuniones de refinamiento y repriorizacin (si es

Backlog necesario) del Product Backlog.
Brinda informacin 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 aprobacin.
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 mtodo de Scrum inicialmente pueden parecer muy diferente y difcil para un nuevo Equipo Scrum.
Un nuevo Equipo Scrum, al igual que cualquier otro equipo nuevo, por lo general se desenvuelve a
travs de un proceso de cuatro etapas. Este proceso se conoce como Modelo de Dinmica de Equipo
de Tuckman (Tuckman, 1965).
Las cuatro etapas del modelo son las siguientes:
____________________ Este a menudo se experimenta como un escenario divertido porque todo es
nuevo y el equipo an no ha encontrado ninguna dificultad con el proyecto.
Storming (Turbulencia) Durante esta etapa, el equipo trata de cumplir con el trabajo. Sin embargo,
puede encontrar conflictos de poder y con frecuencia hay caos o confusin entre los
miembros del equipo.
____________________ En esta fase es cuando el equipo comienza a madurar, resolver sus
diferencias internas y encontrar soluciones para as trabajar juntos.
Performing (Desempeo) Durante esta etapa, el equipo est unido y opera en su nivel ms alto en
trminos de rendimiento. Los miembros se han convertido en un equipo eficiente de
profesionales que son consistentemente productivos.
La siguiente figura muestra las etapas en el Modelo de Tuckman de Desarrollo de Equipo.
Etapas de Tuckman de Desarrollo de Equipos
Seleccin del Equipo
El Equipo Scrum es la base de cualquier Proyecto de Scrum y el tener a los miembros adecuados para
el equipo es vital para la entrega exitosa del proyecto. Los miembros del Equipo Scrum son
especialistas generalistas ya que cuentan con conocimiento de diversos campos y son expertos en al
menos uno. Ms all de la experiencia en la materia, son las habilidades interpersonales de cada
miembro del equipo que determinar el xito de los equipos auto-organizados.
Los miembros ideales del Equipo Scrum son independientes, auto-motivados, enfocados al cliente y
tienen un sentido alto de responsabilidad y de colaboracin.
Cuando se selecciona el equipo, un aspecto importante es crear _________ para cada miembro del
equipo. Esto asegura evitar que haya una disminucin importante de la productividad debido a la
prdida de miembros crticos.
Ventajas de Equipos Multi-funcionales

Scrum utiliza el enfoque de equipos multi-funcionales porque este brinda las siguientes ventajas:
Toma rpida de decisiones: Un equipo multi-funcional es pequeo y est conformado por

expertos que pueden alcanzar un objetivo comn ms rpido que en un proyecto tradicional
donde los equipos ests orientados a la funcin que ejecutan.
Mejor comunicacin: Los equipos multi-funcionales generalmente estn _______ lo que

permite tener una comunicacin ms fluida cara a cara entre los miembros del equipo. As el
equipo interacta regularmente haciendo posible que se comparta el conocimiento.
Orientado al objetivo: Los equipos multi-funcionales en Scrum estn 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.
Innovacin 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 estn 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 trmino colectivo que incluye a los Clientes, los usuarios y patrocinadores, que a menudo
interactan con el Product Owner, Scrum Master y Equipo Scrum para proporcionarles
informacin y para ayudar en la creacin del producto, servicio, o cualquier otro resultado del
proyecto. Los interesados influyen en el proyecto a lo largo del desarrollo del proyecto.
Tambin pueden desempear un papel en los procesos importantes de Scrum tales como:
Desarrollo de Epic(s), Crear Product Backlog Priorizados, Ejecutar la Planificacin de la
Entrega, Retrospectiva del Sprint.
Cliente
El Cliente es la persona o la organizacin que adquiere el producto, servicio, o cualquier otro
resultado del proyecto. Para cualquier organizacin, dependiendo del proyecto, pueden haber
Clientes internos (es decir, dentro de la misma organizacin) o Clientes externos (es decir,
fuera de la organizacin).
Usuarios
El usuario es el individuo o la organizacin que utiliza directamente el Producto, servicio, o

cualquier otro resultado del proyecto. Al igual que los Clientes, para cualquier organizacin
pueden haber usuarios internos y externos. Tambin, en algunos proyectos los Clientes y los
usuarios pueden ser los mismos.
Patrocinador
El patrocinador es la persona o la organizacin que provee recursos y apoyo para el proyecto.
El patrocinador es tambin el interesado, a quien todos le deben rendir cuentas al final.
A veces, la misma persona u organizacin pueden desempear mltiples funciones el
interesado, por ejemplo, el patrocinador y el cliente puede ser el mismo.
2. Vendedores Los vendedores incluyen a individuos u organizaciones externas que ofrecen

productos y/o servicios que no estn dentro de las competencias bsicas de la organizacin
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 estn involucrados en
la definicin de los objetivos relacionados con la calidad, las regulaciones gubernamentales,
la seguridad y otros parmetros importantes de la organizacin. Estos objetivos guan la labor
llevada a cabo por el Product Owner, Scrum Master y Equipo Scrum. El Cuerpo de
Asesoramiento de Scrum tambin ayuda a capturar las mejores prcticas que se deben utilizar
en todos los proyectos Scrum de la organizacin.
El Cuerpo de Asesoramiento de Scrum no toma decisiones relacionadas con el proyecto. En
cambio, acta como una consultora o una estructura de orientacin para todos los niveles de
jerarqua en la organizacin de proyectos - Portafolio, Programa y proyecto. Los Equipo
Scrums tienen la opcin de solicitar ayuda al Scrum Guidance of Body sobre cualquier
asesoramiento requerido.
Captulo Roles de Scrum - Preguntas
1. Cul de los siguientes es un rol esencial (core) de Scrum?
A. Product owner
B. Interesado
C. Patrocinador del proyecto
D. Administrador del proyecto
2. Quin de los siguientes es responsable de proporcionar al Equipo de Scrum de un

ambiente favorable para la creacin de entregables?
A. Scrum Master
B. Product Owner
C. Cuerpo de Asesoramiento de Scrum (SGB)
D. Interesados externos
3. Quin de los siguientes es el responsable de crear una conciencia de las prcticas 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. Quin de los siguientes es responsable de lograr el mximo valor de negocio del

proyecto?
A. Scrum Master
B. Product Owner
C. Equipo Scrum
D. Las partes interesadas externas
5. Quin 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. Lder Equipo Scrum
D. Equipo Scrum
6. Las ventajas de utilizar un equipo multi-funcional son:
A. Mejora de la comunicacin entre los miembros del equipo.

B. Toma de decisiones ms rpida.
C. Responsabilidad individual asignada a cada miembro del equipo en funcin de su
experiencia.
D. Ambos A y B.
7. Quin de los siguientes es el responsable de decidir sobre los criterios de aceptacin

para diversas tareas?
A. Scrum Master
B. Product Owner
D. Equipo Scrum
8. Quin 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 continuacin proporciona una visin general del flujo de un proyecto Scrum.
El ciclo de Scrum comienza con la Fase de Inicio, durante la cual se determina la Visin del
Proyecto y se crea el Product Backlog (Cartera de Necesidades) priorizado.
Luego el trabajo es completado en varios Sprints. Cada Sprint comienza con una Reunin de
Planificacin del Sprint (Sprint Planning Meeting) durante la cual son escogidas las tareas (los
elementos con prioridad alta del Product Backlog) para el Sprint prximo a comenzar.
Un Sprint suele durar entre ________ semanas en el cual el Equipo Scrum trabaja en la
elaboracin Entregables (Deliverables) potencialmente listos en incrementos de producto.
Las reuniones diarias (Daily Stand-up Meeting) se llevan a cabo durante el _______, donde Los
miembros del Equipo Scrum reportan el trabajo avanzado, el trabajo que se proponen terminar y
los impedimentos que estn afrotando.
Al final del Sprint, se lleva a cabo una reunin de revisin del Sprint (Sprint Review Meeting) en el
cual se le presenta una demostracin del trabajo terminado al Product Owner y a los interesados
relevantes. El Product Owner acepta o rechaza los entregables presentados.
El ciclo de Sprint termina con una Reunin de la Retrospectiva del Sprint (Retrospect Sprint
Meeting).
Un proyecto Scrum tiene las siguientes cinco fases:

1. Iniciar
2. Planear y Estimar
3. Implementar
4. Revisin y Retrospectiva
5. Lanzamiento
Fase Procesos
1. Crear la Visin 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 Planificacin 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
(Revisin 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 mtodo Scrum es la fase Iniciar. Los procesos relacionados con la iniciacin de un
proyecto son los siguientes:Crear la Visin del Proyecto, Identificar al Scrum Master e interesados,
Formar el Equipo Scrum, Desarrollar Epic(s), Crear la Lista de Pendientes del Producto Priorizada,
Realizar la Planificacin de las Entregas (Release).
Proceso 1: Crear la Visin del Proyecto

En este proceso, el Caso de Negocio es revisado para crear un Declaracin de la Visin del Proyecto
que servir de inspiracin y proporcionar el enfoque de todo el Proyecto. El Product Owner es el
responsable de crear la visin del proyecto.
1. Caso de Negocio del 1. Product Owner Identificado *

1. Reunin de la Visin del 2. Declaracin de la Visin del
Proyecto*
Proyecto * Proyecto *
2. Product Owner del
3. Acta de Constitucin del
Programa 2. Sesiones JAD
Proyecto
3. Scrum Master del 4. Presupuesto del Proyecto
3. Anlisis FODA (SWOT)
Programa
4. Interesados del Programa 4. Anlisis de Brechas
5. Jefe Product Owner
6. Product Backlog del
Programa
7. Prueba del Proyecto
8. Prueba de Concepto
9. Visin de la Empresa
10. Misin 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
declaracin verbal que expresa la razn para iniciar un Proyecto. Puede ser formal y detallado, o
informal y breve. Independientemente del formato, a menudo incluye informacin sustancial sobre los
antecedentes del Proyecto, los objetivos del negocio y los resultados deseados, un anlisis FODA
(SWOT), Anlisis de Brechas, una lista de los Riesgos identificados, y las estimaciones de tiempo, el
esfuerzo y costo.
El Proyecto se inicia con la presentacin 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.
Reunin de la Visin del Proyecto
Reunin de la Visin del Proyecto es una reunin con los interesados del Programa, el Product Owner
del Programa, el Scrum Master del Programa y el jefe del Product Owner. Ayuda a identificar el contexto
empresarial, Requisitos del Negocio y las expectativas de los interesados con el fin de desarrollar una
Declaracin de la Visin del Proyecto eficaz. Scrum cree en la participacin y colaboracin cercana
con todos los representantes de las compaa para que estn convencidos de apoyar al Proyecto.
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 mximo empresarial para el Proyecto. l o ella tambin es responsable
de la articulacin de requisitos por parte de los Clientes y de mantener la Justificacin de Negocio para
el Proyecto. El Product Owner representa la voz del Cliente.
Cada Equipo Scrum tendr un Product Owner designado. Un pequeo Proyecto puede tener slo un
Product Owner, mientras que los Proyectos ms grandes pueden tener varios. Estos Product Owners
son responsables de la gestin del Product Backlog Priorizado. Ellos escriben los Historias de Usuarios
y gestionan el mantenimiento del Product Backlog.
Declaracin de la Visin del Proyecto
El resultado clave del proceso Crear la Visin del Producto es la Declaracin de la Visin del Proyecto.
Una buena visin del Proyecto explica la necesidad del negocio y que es lo que el Proyecto tiene como
objetivo satisfacer, en lugar de cmo se va a satisfacer la necesidad.
El Declaracin de la Visin del Proyecto no debera ser muy especfico y debe ser flexible. Es posible
que el conocimiento actual sobre el Proyecto est basado en suposiciones que luego van a cambiar
conforme avanza el Proyecto, por lo que es importante que la visin del Proyecto sea lo suficientemente
flexible como para adaptarse a estos cambios. La visin del Proyecto debe centrarse en el problema y
no en la solucin.
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 Seleccin * 1. Scrum Master Identificado*

2. Declaracin de la Visin 2. Consejo Experto del 2. Interesados Identificados*
del Proyecto * Recursos Humanos
3. Entrenamiento y Costos de
3. Product Owner del
capacitacin
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
Organizacin
11. Matriz de Destrezas
Requeridas
de Scrum
Un proyecto Scrum empieza cuando una necesidad de negocio y la visin son identificadas; entonces
se puede continuar con la identificacin de los interesados del proyecto tales como el patrocinador,
usuarios finales, proveedores, etc, quienes estarn impactados por la necesidad de negocio o
ayudarn a llevarla a cabo. Por lo tanto, una vez que la Visin del Proyecto est lista, el Product Owner
procede a identificar todos los interesados del proyecto. Dentro de este proceso, el Product Owner
identifica al Scrum Master, quien ayuda al Product Owner a cumplir con la Visin del Proyecto siendo
el jefe facilitador y mentor del Equipo Scrum.
Es importante que cuando el Product Owner seleccione al Scrum Masters tenga en cuenta sus
habilidades de resolucin de conflictos, que encarne el estilo de gestin : ______________, y que se
comprometa a brindar al Equipo Scrum un ambiente propicio para la entrega exitosa del proyecto.
Criterios de seleccin
La seleccin adecuada del Scrum Master y la identificacin de los interesados adecuados es crucial
para el xito de cualquier proyecto. En algunos proyecto puede haber pre-condiciones que estipulen
determinados miembros del equipo y sus roles.
Cuando hay flexibilidad en la eleccin del Scrum Master, se deben considerar los siguientes criterios
de seleccin:
1. Habilidades para la resolucin de problemasEs uno de los principales criterios a considerar al
seleccionar al Scrum Master. El Scrum Master debe tener las habilidades y experiencia necesarias
para ayudar a eliminar cualquier Impedimento que encare el Equipo Scrum.
2. DisponibilidadEl Scrum Master debe estar disponible para agendar, supervisar y facilitar las
reuniones, incluyendo Release Planning Meeting, Daily Standup Meeting, y otras reuniones
relacionadas al Sprint.
3. CompromisoEl Scrum Master se debe comprometer a que el Equipo Scrum est dotado de un
ambiente de trabajo propicio para asegurar la entrega exitosa del proyecto Scrum.
4. Lder Servicial
En la identificacin de los Interesados es importante recordar que los Interesados incluyen a todos los
clientes, los usuarios y patrocinadores, quienes a menudo interactan con el Product Owner, Scrum
Master y Equipo Scrum para proveer entradas y facilitar la creacin de los productos del Proyecto. Los
Interesados influyen en el proyecto a lo largo de su ciclo de vida.
Scrum Master Identificado
Un Scrum Master es un facilitador y Lder Servicial que se asegura de que el Equipo Scrum est dotado
de un ambiente propicio para completar el Proyecto con xito. El Scrum Master gua, facilita y ensea
prcticas de Scrum a todos los involucrados en el Proyecto; elimina impedimentos que encara el
equipo; y asegura que se estn siguiendo los procesos de Scrum. Es la responsabilidad del Product
Owner identificar al Scrum Master para un proyecto Scrum.
Interesados Identificados
Los interesados, trmino colectivo que incluye a los Clientes, los usuarios y los patrocinadores, quienes
con frecuencia interactan con el Equipo Core Scrum, influyen en el Proyecto durante todo el proceso
de desarrollo de Productos.
Proceso 3: Formar el Equipo Scrum
Form Scrum Team
Uno de los procesos ms importantes en el flujo Scrum es la formacin del Equipo Scrum, porque ste
es el que crea los entregables del proyecto, y con estos se logra satisfacer la Visin del Proyecto.
El Equipo Scrum es tambin conocido como el Equipo de __________. Un Equipo ideal Scrum tiene
entre 6 a 10 miembros. Los miembros del Equipo Scrum son especialistas generalistas, donde cada
uno debe poseer un conocimiento general de diversos campos y son expertos en al menos uno. Ms
all de ser expertos tcnicos, son las habilidades interpersonales de cada miembro del equipo que
determinar el xito de los equipos auto-organizados.
1. Product Owner * 1. Seleccin del Equipo Scrum* 1. Equipo Scrum Identificado *

2. Scrum Master* 2. Consejo Experto del Recursos 2. Respaldos de los miembros del
3. Declaracin de la Visin del Humanos equipo
Proyecto* 3. Entrenamiento y Costos de 3. Plan de Colaboracin
4. Jefe del Product Owner capacitacin 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
Organizacin
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 Visin del Proyecto porque el tipo de proyecto y el tipo de industria son
factores cruciales en la seleccin de expertos tcnicos. Sin embargo el Product Owner y el Scrum
Master podra considerar otros factores como los requerimientos de personal, disponibilidad y
compromiso de las personas y la matriz de destrezas requeridas.
Una vez que el Equipo Scrum es seleccionado, el Equipo Core Scrum (Product Owner, Scrum Master
y Equipo Scrum) est completo. La salida ms importante de este proceso es un equipo
____________ y ________________.
Los miembros ideales del Equipo Scrum son independientes, auto-motivados, se enfocan en el Cliente,
y tienen un alto sentido de responsabilidad y colaboracin. El equipo debe ser capaz de fomentar un
ambiente de reflexin independiente y de tomar decisiones con el fin de extraer los mayores beneficios
de la estructura.
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 terminologa Scrum, un Epic es definido cmo 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) ms pequeas en
algn punto del proyecto antes de implementarlas. El Equipo Core Scrum empieza escribiendo Epics
basados en la Visin del Proyecto y podra 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 coordinacin 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 ficcin con descripcin muy detallada que representan a la mayora de
los usuarios y otros interesados que no utilizan directamente el producto final.
1. Scrum Core Team* 1. Reunin de Grupo de 1. Epic(s) *
2. Declaracin de la Visin del Usuarios * 2. Personas *
Proyecto * 2. Talleres de Historia de 3. Campos Aprobados
3. Interesados
Usuario 4. Riesgos Identificados
Programa 3. Reunin de Grupos de
5. Solicitudes de Cambio Opinin (Focus Group)
Aprobadas 4. Entrevista a Usuarios o
6. Solicitud de Cambio no Clientes
Aprobadas 5. Cuestionarios
7. Riesgos del Portafolio y del 6. Tcnicas de Identificacin
Programa
de Riesgos
8. Leyes y Regulaciones
9. Contractos 7. Juicio Experto del Cuerpo
10. Informacin Previa del de Asesoramiento de
Proyecto Scrum
de Scrum
Reunin de Grupo de Usuarios
La Reunin de Grupo de Usuarios involucre a los interesados del proyecto, principalmente los usuarios
o Clientes del Producto. Ellos proporcionan al Equipo Core de Scrum informacin de primera mano
acerca de las expectativas del usuario. Esto ayuda en la formulacin de los Criterios de Aceptacin
para el Producto y proporciona informacin valiosa para el desarrollo de Epics.
Creacin de una Persona
Esto implica la asignacin al personaje de un nombre ficticio y preferentemente una foto. A la Persona
se le incluirn atributos muy especficos como su edad, gnero, nivel de educacin, entorno, intereses
y metas. Una cita que ilustra las necesidades de la persona puede ser incluida tambin. A continuacin
se muestra un ejemplo de una Persona para un sitio web de viajes.
Proceso 5: Crear la Lista de Requerimientos Pendientes del Producto
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 (Prioritized Product Backlog), la cual incluye una lista de caractersticas 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 mximo valor _________, tienen la ________
ms alta.
El Product Backlog es una lista de requerimientos que, al convertirse en funcionalidad de producto
potencialmente comercializable, entregar la Visin del Producto.
Es responsabilidad del Product Owner elaborar el inicial Product Backlog Priorizado.
El Product Backlog Priorizado generalmente contiene Epics, pero a veces tambin contiene
informacin 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 caractersticas como el tamao, complejidad y experiencia requerida.
1. Scrum Core Team* 1. Mtodos de Priorizacin de 1. Product Backlog Priorizado
2. Epic(s) * Historias de Usuarios * (Prioritized Product
3. Personas * 2. Talleres de Historia de Backlog)*
4. Interesados 2. Criterio de Terminado
Usuario
5. Declaracin de la Visin del (Done Criteria)*
Proyecto 3. Planificacin de Valor
6. Product Backlog del 4. Tcnicas de Evaluacin de
Programa Riesgo
7. Requisitos del Negocio 5. Estimacin de Valor del
8. Solicitudes de Cambio Proyecto
Aprobadas 6. Mtodos de Estimacin de
9. Riesgos Identificados
Historias de Usuario
10. Contratos
11. Recomendaciones del 7. Juicio Experto del Cuerpo
Cuerpo de Asesoramiento de Asesoramiento de
de Scrum Scrum
La priorizacin tienen en cuenta tres factores principales: valor, riesgo e incertidumbre, y

dependencias. El Equipo Core Scrum podra utilizar varios mtodos de priorizacin como los
mencionados a continuacin:
Anlisis Kano : El anlisis Kano fue desarrollado por Noriaki Kano (1984) , Esta tcnica puede
ser utilizada para clasificar las preferencias del cliente en cuatro categoras, a las cuales nos
referiremos como Exciters/ Delighters, Satisfiers, Dissatisfiers e Indifferent.
o Exciters/Delighters: Funcionalidades nuevas o de alto valor para el cliente.
o Satisfiers: Funcionalidades que ofrecen valor al cliente.
o Dissatisfiers: Funcionalidades que, si no estn presentes, probablemente causen que el
cliente est disgustado con el producto, sin embargo no afecta el nivel de satisfaccin si
ellos estn presentes.
o Indifferent: Funcionalidades que no afectan al cliente de ninguna forma y deben ser
eliminadas.
Esquema de Priorizacin MoSCoWEl esquema de priorizacin MoSCoW deriva su nombre
de las primeras letras de las frases "Must have" (Debe tener), Should have (Debera tener),
"Could have (Podra tener), y "Would like to have, but not at this time (Quisiera tenerlo, pero
no ahora). Las etiquetas estn en orden decreciente de prioridad. "Debo tener" estas Historias
de Usuarios: son aquellas que si no son incluidas en el producto, este no tendr valor y
"Quisiera, pero no ahora" estas Historias de Usuarios: son aquellas que, a pesar de que sera
bueno tenerlas, no es necesario incluirlas.
Comparacin por Pares (Paired Comparison) En esta tcnica se prepara una lista de
todas las Historias de Usuarios del Product Backlog Priorizado. Luego, cada Historia de
Usuario se toma de forma individual y se compara con las otras Historias de Usuarios en la
lista, uno a la vez. Cada vez que dos Historias de Usuarios se comparan, se toma una decisin
sobre cul de los dos es ms importante. A travs de este proceso, se puede obtener una lista
priorizada de las Historias de Usuarios.
Mtodo de los 100 Puntos (100-point method) Fue desarrollado por Dean Leffingwell y
Don Widrig (2003). Se trata de dar al Cliente 100 puntos que puede usar para votar por las
Historias de Usuarios ms importantes. El objetivo es dar ms peso a las Historias de Usuarios
que son de mayor prioridad en comparacin con las otras Historias de Usuarios disponibles.
Cada miembro del grupo asigna puntos a las diversas Historias de Usuarios, dando ms puntos
a aquellas que consideran ms importantes. Al finalizar el proceso de votacin, la Priorizacin
se determina calculando el total de puntos asignados a cada Historia de Usuario.
Criterios de Terminado (Done)
Es un conjunto de reglas que se aplican a todas los Historias de Usuarios. Una definicin clara de
Done es crtica, ya que elimina la ambigedad de los requisitos y ayuda a que el equipo se adhiera a
las normas de calidad obligatorias. Esta definicin se utiliza para crear los Criterios de Terminado, que
son un resultado del proceso de Crear la Lista de Requerimientos Pendientes del Producto. Una
Historia de Usuario se considera Terminada (Done) cuando se le muestra y es aprobada por el
Product Owner que juzga sobre la base de los Criterios de Terminado y los Criterios de Aceptacin de
la Historia del Usuario.
Proceso 6: Realizar la Planificacin de los Entregables
Conduct Release Planning

En este proceso, el Equipo Core de Scrum trabaja elaborando el Cronograma de Planificacin de los
Entregables (Release Planning Schedule) para entregar incrementos de producto a los interesados.
El Cronograma de Planificacin de los Entregables indica qu entregables sern liberados a los
clientes, junto con los intervalos planeados y las fechas de entrega.
Tambin, el Equipo Core de Scrum tambin define la duracin del Sprint para el proyecto. Una vez que
la duracin del Sprint es fijada, normalmente no cambia en el proyecto. Podra 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 Planificacin de los Entregables y para fijar la duracin del Sprint se utilizan varias
entradas como las de los interesados, Declaracin de Visin del Proyecto, Product Backlog Priorizado,
Requerimientos de Negocio y calendario de feriados.
El Cronograma de Planificacin 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 implementacin de este entregable del
Sprint es determinada en el Cronograma de Planificacin de los Entregables.
Un Sprint puede durar entre 1 y 6 semanas. Sin embargo para obtener el mximo beneficio de un
proyecto Scrum se recomienda mantener la duracin 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 Planificacin 1. Cronograma de

2. Interesados* de las Entregas* Planificacin de las
3. Declaracin de la Visin del 2. Mtodos de Priorizacin de Entregas*
Proyecto * las Entregas * 2. Duracin 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 declaracin 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 comunicacin entre ambos grupos. Los requerimientos expresados en Historias
de Usuario son fciles de entender y permiten tener mejor estimaciones. Las Historias de Usuario
eliminan la necesidad de la documentacin 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 ms
Epics. Muchos Themes puede ser asociados a un producto, pero un Theme no puede ser relacionado
con ms 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 coordinacin con el Product Owner.
El Equipo Core de Scrum tiene que asegurar que los requerimientos de negocio del cliente sern
convertidos en requerimientos funcionales que el desarrollador pueda entender fcilmente 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 prctica y tiempo; sin embargo el Equipo Core de Scrum puede acortar ese
tiempo asistiendo a Talleres para Escribir Historias de Usuario. El Equipo Scrum podra seguir el
modelo INVEST para crear mejores Historia de Usuario.
INVEST es un acrnimo 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 estimacin y la
priorizacin.
Negotiable (Negociable) Una Historia de Usuario debera tener una descripcin 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 fcil de estimar por
parte de los desarrolladores, as ellos no tendrn dificultades en la priorizacin y planificacin.
Pequeo (Small) Una Historia de Usuario bien escrita debe ser pequea en esfuerzo. Si se
requiere mayor esfuerzo existe alta probabilidad de tener errores en la estimacin 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 debera ser desarrollado,
porque no podr ser confirmado como Terminado. Por ejemplo: Como usuario, yo quiero que
mi trabajo sea fcil, as este proceso no debera ser complicado. esta historia de usuario no
es verificable.
Una Historia de Usuario nos muestra tres caractersticas de un requerimiento: Quin, Qu y Cmo.
Los requerimientos expresados como Historias de Usuario son enunciados cortos, simples y
fciles de entender.
El formato de una Historia de Usuario es el siguiente:
Como <rol del usuario> deseo <descripcin del requerimientos> para <beneficio>.
Junto con las Historias de Usuario, el Equipo Core Scrum escribe los Criterios de Aceptacin. Las
Historias de Usuario son a veces subjetivas, por lo que los Criterios de Aceptacin brinda la objetividad
requerida para las Historias de Usuario para ser consideradas como Terminadas o no Terminadas
durante la Revisin de un Sprint.
Los Criterios de Aceptacin ayudan al equipo a entender qu se espera de una Historia de Usuario,
eliminan la ambigedad de los requerimientos y ayuda a alinear expectativas. El Product Owner define
y comunica el ________________ al Equipo Scrum. En los Sprint Review Meetings, el Critero de
Aceptacin brinda el contexto para que el Product Owner decida si la Historia de Usuario ha sido
completada satisfactoriamente. Es importante, y es responsabilidad del Scrum Master, asegurar que
el Product Owner no cambie los Criterios de Aceptacin de una Historia de Usuario, mientras este se
est ejecutando, que ya est comprometida a un Sprint,.
.
1. Scrum Core Team* 1. Experiencia en la Escritura 1. Historias de Usuarios *

2. Product Backlog de Historias de Usuario * 2. Criterios de Aceptacin 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. Mtodos de Estimacin 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

Despus que las Historias de Usuarios son creadas, tienen que ser aprobadas por el Product
Owner, estimadas por el Equipo Scrum, este tambin se compromete a desarrollar un conjunto
de Historias de Usuarios.
Approve El Product Owner evala las Historias de Usuarios de acuerdo al nivel de
satisfaccin de los requerimientos de negocio y verificando si cumplen con sus
respectivos Criterios de Aceptacin.
Estimate Despus de que las Historias de Usuarios son aprobadas por el Product Owner, el
Equipo Core Scrum comienza el trabajo de estimacin de estas. Estimar los
recursos y el tiempo con precisin es un aspecto crtico en cualquier organizacin
para garantizar una buena experiencia en la entrega del proyecto para el cliente.
Sin embargo, las estimaciones, por definicin, no son _________ . La precisin de
la estimacin varia de acuerdo a la complejidad del proyecto, el tamao,
disponibilidad del equipo, volatilidad de los requerimientos, etc. Scrum trata de
asegurar una mejor estimacin usando actividades de estimacin de equipos y
mtodos de comparacin relativas.
Commit Despus de la estimacin, 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. Reunin del Grupo de 1. Historias de Usuarios

2. Historias de Usuarios * Usuarios * Aprobadas, Estimadas y
3. Criterios de Aceptacin de 2. Planificacin Poker Comprometidas *
Historia de Usuario* 3. Puo de Cinco
4. Recomendaciones del 4. Estimacin de Puntos de
Cuerpo de Asesoramiento Costo
de Scrum 5. Otras Tcnicas de
Estimacin
de Asesoramiento de
Scrum
Algunas herramientas conocidas que se pueden utilizar para este proceso son:
Wideband Delphi
Es una tcnica de estimacin grupal para determinar cunto trabajo est involucrado y cunto
tiempo tomar completarlo. Los participantes de forma annima proveen estimaciones de cada
funcionalidad, y estas estimaciones iniciales son graficadas en un cuadro. El equipo entonces
discute sobre los factores que influenciaron en sus estimations y se procede a realizar una
segunda ronda de estimacin. Este proceso se repite hasta que el estimado de los participantes
converja y se llegue a un consenso en el estimado final. La informacin de cada participantes se
recolecta de forma que se evite el problema de pensamiento de grupo (group think).
Planificacin Poker (Planning Poker)
Tambin llamada Estimacin Poker, es una forma de aplicar Wideband Delphi. Es una tcnica de
estimacin donde se utiliza el consenso para estimar tamaos relativos de Historias de Usuario o
el esfuerzo requerido para crearlos.
En Planificacin Poker, a cada miembro se le asigna una baraja de cartas, cada carta est
numerada en una secuencia. Estos nmeros representan la complejidad del problema, en
trminos de tiempo o esfuerzo. El Product Owner escoge una Historia de Usuario del Product
Backlog Priorizado y lo presenta al equipo. Los miembros del Equipo Scrum evalan la Historia
de Usuario y tratan de entenderla mejor antes de dar su estimacin para desarrollarla. Entonces
cada miembro elige una carta de la baraja que represente su estimado para la Historia de Usuario.
Si la mayora o todos los miembros del equipo eligen la misma carta, entonces esta ser la
estimacin de la Historia de Usuario. Si no hay consenso, entonces los miembros del equipo
discuten las razones por la que seleccionaron diferentes cartas o estimaciones. Despus de la
discusin, vuelven a escoger una carta. Se siguen los mismos pasos hasta que los supuestos
sean comprendidos y los malentendidos sean resueltos, de esta forma se alcanzar consenso en
la estimacin. La Planificacin Poker promueve la interaccin entre los participantes y mejora la
comunicacin. Tambin permite el pensamiento independiente de los participantes evitando el
fenmeno de pensamiento de grupo.
Puo de Cinco (Fist of Five)

Es un mecanismo simple y rpido para alcanzar consenso en un grupo y direccionar la discusin.
Despus de una discusin inicial de una propuesta dada o decisin pendiente, a los miembros del
Equipo Scrum se les pide que voten en una escala entre el 1 al 5, usando sus dedos. Esta tcnica
no solo permite llegar a un consenso, sino tambin direcciona la discusin porque a cada miembro
del equipo se le pide explicar la razn de su eleccin. Ellos tienen la oportunidad de expresar
cualquier preocupacin o problema que tengan. Una vez que el equipo ha intercambiado
opiniones, una decision colectiva es tomada.
El nmero de dedos usados para votar indica cun de acuerdo est el participante con el tema
propuesto y si tiene observaciones que desea discutir con el grupo:
Un dedo: Estoy en desacuerdo con la conclusin del grupo y tengo preocupaciones
importantes que deseo revisarlas con el grupo.
Dos dedos: Estoy en desacuerdo con la conclusin del grupo y quisiera revisar con el
grupo algunas preocupaciones menores.
Tres dedos: No estoy seguro pero elijo estar de acuerdo con la conclusin del grupo.
Cuatro dedos: Estoy de acuerdo con la conclusin del grupo y quisiera discutir algunos
temas menores.
Cinco dedos: Estoy totalmente de acuerdo con la conclusin del grupo.
Estimacin Relativa / Puntos de Historia (Relative Sizing / Story Points)
Adems de ser utilizada para la estimacin de costos, los story points pueden tambin servir para
la estimacin de toda una Historia de Usuario o funcionalidad. Este enfoque asigna un valor de
Story Point basado en una evaluacin completa del tamao de la Historia de Usuario considerando
el riesgo, el esfuerzo requerido y el nivel de complejidad. Esta evaluacin ser llevada a cabo por
el Equipo Scrum y un valor de story point ser asignado. Una vez que la evaluacin de una Historia
de Usuario del Product Backlog Priorizada es efectuada, el Equipo Scrum puede evaluar las otras
Historias de Usuario de forma relativa considerando la primera historia.
Por ejemplo, una funcionalidad que tiene asignada 2 story point debe tener el doble de dificultad
que una funcionalidad que tiene asignada 1 story point; una que tenga 3 story point debe tener el
triple de dificultad que una con 1 story point.
Estimacin de Afinidad (Affinity Estimation)

Esta tcnica es utilizada para estimar rpidamente un gran nmero 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 ms pequea hasta la ms grande. Para esto, cada miembro
del equipo empieza ordenndo un subconjunto de Historias de Usuario del Product Backlog
Priorizado segn su tamao 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
podra mover Historias de Usuario segn corresponda.
La segunda parte del ejercicio incluye la discusin. Finalmente, el Product Owner indicar algunas
categoras de tamaos en la pared. Estas categoras 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 categora que corresponda, este es el ultimo paso del
proceso. Algunos beneficios principales de esta tnica es que el proceso es muy transparente y
fcil de ejecutarla.
Proceso 3: Crear Tareas
Crear Tasks
En las fases iniciales donde se ponen por escrito los requerimientos, la mayora de las Historias de
Usuario recaban informacin de funcionalidades de alto nivel, por lo que stas tienen que ser
desglosadas en __________ realizables y simples.
Reunin de Planificacin de Tareas (Task Planning Meeting)
Como parte de esta reunin, los miembros del Equipo Scrum revisan las Historias de Usuario
Comprometidas a detalle para eliminar ambigedades resolver todas las preguntas. Aunque no es
mandatoria la presencia del Product Owner en esta reunin, es importante su participacin porque
ayudar al Equipo Scrum a entender mejor las Historias de Usuario, lo que har que la reunin sea
ms eficiente. La creacin de tareas se realiza durante la Reunin de Planificacin de Tareas. Esta
reunin est dividida en dos partes:
El Product Owner sugiere Historias de Usuario que deben formar parte del
Sprint.
El Equipo Scrum determina cuntas Historias de Usuario pueden ser
Primera ejecutadas en un Sprint.
Se alcanza consenso en las Historias de Usuario de sern includas en el Sprint.
Parte
El Equipo Scrum determina cmo convertir las Historias de Usuario

seleccionadas en Incrementos de Producto desglosndolas en tareas.
Segunda El Equipo Scrum se compromete con los entregables del Sprint.
Parte
En la primera parte de la Reunin de Planificacin de Tareas (Task Planning Meeting), el Product

Owner sugiere Historias de Usuario que deben formar parte del Sprint basndose en la estimacin
provista por el Equipo Scrum de cuntas Historias de Usuario pueden entregar en un Sprint. El objetivo
del Equipo Scrum es alcanzar un consenso en las Historias de Usuario que sern includas en el Sprint.
En la segunda parte de la Reunin de Planificacin de Tareas (Task Planning Meeting), el Equipo
Scrum determina cmo convertir las Historias de Usuario seleccionadas en Incrementos de Producto
desglosndolas en tareas. La principal salida de esta reunin es la Lista de Tareas, la cual contiene
las tareas comprometidas por el Equipo Scrum para el Sprint. La Reunin de Planificacin de Tareas
puede ser llevada a cabo dentro de la Reunin de Planificacin del Sprint (Sprint Planning Meeting).
1. Scrum Core Team* 1. Reunin de Planificacin 1. Lista de Tareas *
2. Historias de Usuario de Tareas* 2. Historias de Usuarios
Aprobadas, Estimadas y 2. Tarjetas Aprobadas, Estimadas,
Comprometidas * 3. Descomposicin Comprometidas y
4. Determinacin de Actualizadas
Dependencias 3. Dependencies
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 crtico
para los miembros del Equipo Scrum para estimar el esfuerzo necesario para realizar cada tarea y as
planear la forma de proceder. La estimacin es hecha tomando en cuenta la duracin 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 Estimacin de 1. Lista del Esfuerzo

2. Lista de Tareas * Tareas * Estimado de Tareas*
3. Criterios de Aceptacin de 2. Criterios de Estimacin * 2. Lista de Tareas
las Historias de Usuario 3. Planificacin Poker Actualizadas
4. Dependencias 4. Puo de Cinco
5. Riesgos Identificados 5. Otras Tcnicas de
6. Recomendaciones del Estimacin
de Scrum
Reuniones de Estimacin de Tareas (Task Estimation Meeting)

El Equipo Scrum estima las tareas en la Reunin de Estimacin de Tareas. Esta reunin puede
ser llevada a cabo como parte de la Reunin de Planificacin del Sprint (Sprint Planning Meeting).
Para estimar las tareas, el Equipo Scrum puede utilizar varias tcnicas de Estimacin. Es
importante que el Equipo Scrum trabaje con Criterios de Estimacin consensuados. El objetivo
principal es utilizar los Criterios de Estimacin para mantener tamaos relativos de estimacin y
minimizar la necesidad de re-estimacin. Los Criterios de Estimacin pueden ser expresados de
muchas formas, dos ejemplos comunes son los _______________ y _______________.
El Tiempo Ideal (Ideal Time) normalmente describe el nmero de horas que un miembro del Equipo
Scrum trabaja exclusivamente en el desarrollo de los entregables del proyecto, sin incluir el tiempo
dedicado a otras actividades o trabajos que estn fuera del proyecto.
Proceso 5: Crear la Lista de Pendientes del Sprint

Create Sprint Backlog
Este es el ultimo proceso de la fase de Planificacin y Estimacin. El Sprint Backlog es creado
durante la Reunin de Planificacin de Sprint (Sprint Planning Meeting). Despus 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 decisin de quin 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 cmo 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 lder facilitador y mentor del Equipo Scrum.
1. Scrum Core Team* 1. Reunin de Planificacin 1. Sprint Backlog *

2. Lista del Esfuerzo Estimado del Sprint (Sprint Planning 2. Sprint Burndown Chart*
de Tareas* Meeting) *
3. Duracin del Sprint * 2. Herramientas de
4. Velocidad del Sprint Previo Seguimiento del Sprint
5. Dependencias 3. Mtrica 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 estndar contiene 4 columnas que indican el progreso de las treas estimadas
para el Sprint: la columna Pendiente (To Do) para las tareas que an no empiezan, la columna
En Progreso (In Progress) para tareas que empezaron pero no han sido completadas an, la
columna En Pruebas (Testing) para tareas que han sido completadas pero se encuentran en
el proceso de ser probadas y la columna Terminado (Done) para tareas terminadas y probadas
exitosamente. Una columna opcional es la quinta: Stories. Al inicio del Sprint, todas las tareas
se colocan en la columna To Do y se van moviendo a las columnas siguientes de acuerdo al
avance.
La siguiente figura muestra un ejemplo de un Scrumboard:
Las principales salidas de este son el Sprint Backlog y el Grfico Sprint Burndown.
1. Sprint Backlog (Lista de Pendientes del Sprint) Es la lista de las tareas a ser ejecutadas por
el Equipo Scrum en el prximo Sprint. Es una prctica comn que el Sprint Backlog se muestre en
un Scrumboard o tablero de tareas, este proporciona una representacin visible y constante de la
situacin de las Historias de Usuarios en el backlog. Tambin se incluyen en el Sprint Backlog
algunos Riesgos asociados con las diversas tareas. Las actividades de mitigacin a los riesgos
identificados podran ser incluidas como tareas en el Sprint Backlog.
Una vez que el Sprint Backlog se haya finalizado y el Equipo Scrum se haya comprometido al
mismo, no deben aadirse nuevas Historias de Usuarios; sin embargo, puede ser necesario aadir
las tareas que pueden haberse pasado por alto o ignorado. Si surgen nuevas necesidades durante
un Sprint, se aadirn al Product Backlog Priorizado y se incluirn en un Sprint posterior.
2. Sprint Burndown Chart Es un grfico que muestra la cantidad de trabajo que queda por hacer
en el Sprint actual. El Grfico Sprint Burndown inicial es acompaado por un Burndown planeado.
El Grfico Sprint Burndown debe actualizarse al final de cada da laborable.
La siguiente figura muestra un ejemplo del Sprint Burndown Chart:
Este grfico muestra el trabajo estimado pendiente (en el eje Y) y el tiempo (en el eje X).
Al final del da, los miembros del Equipo Scrum actualizan el grfico con el trabajo
completado.
El grfico Sprint Burndown es un buen indicador de la ________ del equipo en el Sprint

actual y permite hacer pronsticos para saber si el equipo podr completar o no todas las
Historias de Usuario comprometidas.
FASE: IMPLEMENTAR
La fase de Implementar abarca las ejecucin de las tareas y actividades para crear el producto, servicio
o resultado del proyecto. Estas actividades incluyen la creacin de varios entregables, llevar a cabo la
Reunin diaria y el mantenimiento del Product Backlog (es decir revisar, ajustar y actualizar
periodicamente).
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 creacin de los Entregables del Sprint (Sprint Deliverables), mientras que el Product
Owner y el Scrum Master tambin 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 informacin 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*
Planificacin 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 decisin de cmo desarrollar algunas tareas recae en los miembros del Equipo Scrum. Ni
los interesados, ni el Scrum Master, tampoco el Product Owner puede dirigir al equipo en la forma de
desarrollar los entregables. Los miembros del Equipo Scrum son expertos en sus dominios, y su juicio
y experiencia son aplicadas a todos los aspectos tcnicos y de gestin del proyecto durante este
proceso.
La salida ms importante de este proceso es el entregable del Sprint, tambin conocido como el
_______________, el cual satisface todas las caractersticas y funcionalidades definidas en las
Historias de Usuario del Sprint. Si los miembros del Equipo Scrum enfrentan cualquier obstculo
mientras completan los entregables del Sprint, ellos los registran en el Impediment Log. Un Impediment
Log es mantenido por el Scrum Master, y es su responsabilidad resolver los problemas y eliminar los
impedimentos.
Cuando el Product Owner quiere hacer cambios en medio del Sprint, el alcance del Sprint en curso no
es modificado. Si el cambio que se requiere es tan importante que el resultado del Sprint en curso
podra ser intil sin hacer estas modificaciones, entonces el actual Sprint debera ser terminado, y un
nuevo Sprint que incorpora el cambio debe ser iniciado. Caso contrario, el cambio ser incluido en un
Sprint posterior.
PROCESO 2: REALIZAR LA REUNIN 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. Reunin 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 Da 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 colaboracin se promueve en el Equipo Scrum a travs de la Reuniones Diarias (Daily Standup

Meetings). Esta es una reunin diaria de corta duracin, generalmente _____ minutos como mximo.
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 Reunin Diaria y se proyecta el
trabajo que debe ser hecho antes de la siguiente Reunin.
La duracin de las reuniones es muy corta y se espera que todos los miembros del Equipo Scrum
asistan. Sin embargo, la reunin no se cancela o se retrasa si uno o ms miembros no pueden asistir.
En estas reuniones cada miembro del Equipo Scrum responde a estas tres preguntas especficas:
Qu termin ayer?
Qu voy a terminar hoy?
Qu impedimentos u obstculos (si los hay) estoy enfrentando en la actualidad?
Aparte de la colaboracin, las Reuniones Diarias promueven la transparencia entre los miembros del
Equipo Core Scrum. El Scrum Master ayuda a los miembros del equipo a resolver problemas e
impedimentos. El Scrum Master slo es un facilitador, no dirige la reunin. El Daily Standup Meeting
solo es un foro de intercambio de informacin. Cualquier discusin sobre la resolucin de un problema,
si es necesaria, se realiza despus de la reunin diaria. El Scrum Master recolecta informacin de los
impedimentos que los miembros del Equipo Scrum estn enfrentando al realizar los trabajos del Sprint
y los resuelve despus de la reunin.
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 estn refinados, es recomendable que
entre el 7% al 10% de cada Sprint sea destinado para refinar el backlog. El Product Owner es
responsable de refinar el Product Backlog Priorizado, lo que conlleva a aadir o cambiar algunos
elementos para satisfacer cambios de requerimientos y para detallar Historias de Usuario para el
siguiente Sprint.
Este proceso asegura que el Product Backlog Priorizado est refinado bien antes del siguiente Sprint,
as el Equipo Scrum tendr un grupo de historias bien analizadas y claramente definidas que permitir
agilizar el desglose de tareas y el proceso de estimacin. Tambin permite que el desarrollo sea ms
flexible porque se podr incorporar requerimientos recientes tcnicos y de negocio en el siguiente
Sprint. De acuerdo a la informacn del cliente, cambios externos del mercado y conocimiento ganado
del Sprint actual y de los anteriores, el Product Backlog Priorizado es repriorizado.
Scrum no considera que este tipo de reuniones tenga una restriccin de tiempo (timebox). Este proceso
es una tarea permanente del Product Owner.
1. Scrum Core Team* 1. Reunin de Revisin del 1. Product Backlog

2. Product Backlog Product Backlog Priorizado Priorizado Actualizado*
Priorizado* * 2. Cronograma de
3. Entregables Rechazados 2. Tcnicas de Comunicacin Planificacin del
4. Solicitudes de Cambio 3. Otras Tcnicas 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
Planificacin del Entregable
de Scrum
FASE: REVISIN Y RETROSPECTIVA
La fase Revisin y Retrospectiva se ocupa de la revisin de los entregables y del trabajo que se ha
hecho, y determina las mejores prcticas y mtodos utilizados para hacer el trabajo relacionado al
proyecto. En las grandes organizaciones, el proceso de Revisin y Retrospectiva puede incluir la
convocatoria de Reunin de Scrum de Scrums.
Proceso 1: Convocar Scrum de Scrums

Convene Scrum of Scrums
Este proceso slo aplica para grandes proyectos Scrum donde varios Equipos Scrum estn trabajando
sincronizadamente para asegurar el progreso del proyecto. Dado que los equipos trabajan en paralelo,
asegurar que todos avancen uniformemente es un tema crtico 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 reunin es facilitada por el Jefe Scrum Master (Chief Scrum Master) quien
tambin ayuda a direccionar los impedimentos que impactan a ms de un equipo.
1. Reunin de Scrum de 1. Mejor coordinacin 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 Reunin Actualizadas
3. Jefe Product Owner (Chief
Product Owner)
de Asesoramiento de
4. Agenda de la Reunin 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 mayora de los casos, este es el Scrum Master, pero a veces alguien ms puede
representar al equipo. Una sla 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 funcin de acuerdo a los incidentes y circunstancias. La persona
que participe en la reunin debe tener el conocimiento tcnico para identificar los casos en los que los
equipos podran 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 especficas:
1) En qu ha estado trabajando mi equipo desde la ltima reunin?
2) Qu va a hacer mi equipo hasta la prxima reunin?
3) Qu consideraban otros equipos que mi equipo termine que no se ha hecho?
4) Qu est planeando hacer nuestro equipo que pueda afectar a otros equipos?
La salida principal de las Reuniones Scrum de Scrum es la mejor coordinacin entre varios equipos
trabajando en el mismo proyecto.
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 Aceptacin.
La salida de la Reunin de Revisin 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 aceptacin 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 definicin 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 Aceptacin 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. Reunin de Revisin del 1. Entregables Aceptados *

2. Entregables del Sprint Sprint (Sprint Review 2. Entregables Rechazados
(Sprint Deliverables)* Meeting)* 3. Riesgos Actualizados
3. Sprint Backlog* 2. Anlisis de Valor Ganado 4. Resultados del Anlisis de
4. Criterio de Terminado 3. Juicio de Experto del Valor Ganado
(Done Criteria)* Cuerpo de Asesoramiento 5. Cronograma de
5. Criterio de Aceptacin de la de Scrum Planificacin del
Historia de Usuario * Entregable Actualizado
6. Interesados 6. Dependencias
7. Cronograma de Actualizadas
Planificacin de la Entrega
9. Dependencias
de Scrum
Proceso 3: Retrospectiva del Sprint
Retrospect Sprint
Luego de la Reunin de Revisin del Sprint (Sprint Review Meeting) el Equipo Scrum se rene en la
Reunin de Retrospectiva del Sprint (Retrospect Sprint Meeting). Esta es una oportunidad para que el
Equipo Scrum se tome un momento para mirs hacia atrs y examinar el Sprint que acaba de terminar
para identificar mejoras potenciales en el proceso. Estas mejoras pueden resultar no solo en un simple
acuerdo entre miembros del equipo para hacer las cosas de otra forma, tambin puede definir
elementos no funcionales para el Product Backlog Prioritizado.
En la Reunin de Retrospectiva del Sprint (Retrospect Sprint Meeting) participan el Scrum Master y los
miembros del Equipo Scrum. El Product Owner podra asistir pero no es obligatoria su presencia.
Los miembros del equipo revisan qu se hizo bien y qu no en el Sprint que acaba de terminar.
Plantean los problemas que enfrentaron durante el Sprint y discuten cmo se podran direccionar estos
temas. El Equipo identifica mejoras potenciales en la forma de trabajo y tambin sugiere mejoras en la
definicin de Done basndose en su experiencia.
1. Scrum Master* 1. Reunin 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 Rpida (Speed 3. Elementos Non-Functional
5. Recomendaciones del Boat) propuestos para el Product
Cuerpo de Asesoramiento 4. Tcnicas de Mtricas 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 reunin efectiva de Retrospectiva, el evento puede tener estos 5 pasos:
Set the Stage (Preparar el ambiente): Se le da la bienvenida al equipo, se establece un
consenso sobre el propsito de la reunin y se evala la predisposicin de los asistentes
para participar activamente.
Gather data (Obtener informacin): El equipo comparte informacin sobre el Sprint que
acaba de terminar y discuten sobre las fortalezas y debilidades. Este estado permite que
los participantes se enteren sobre las cosas ms importantes que sucedieron en el Sprint.
Generate insight (Generar ideas): Este paso est enfocado en la pregunta Por qu?
(por qu algunas cosas funcionaron bien y por qu otras necesitan cambiar?) Este ayuda
a los participantes a tener perspectiva y a saber la causa raz de los problemas.
Action (Accin): El equipo descubre la solucin para mejorar el trabajo que se viene
haciendo y para reducir o prevenir errores.
Circle of questions and Closing (Crculo de preguntas y Cierre): Cada miembro del equipo
tiene la oportunidad de preguntar o compartir sus preocupaciones. En esta etapa se
clarifican las acciones que se realizarn en el siguiente Sprint. Finalmente, los miembros
del equipo se agradecen entre si y se cierra la reunin.
La informacin, opiniones, discusiones y los puntos acordados que son expuestos en la Reunin
de Retrospectiva del Sprint (Retrospect Sprint Meeting) son registradas en el Retrospect Sprint Log.
Fase: Lanzamiento
La fase de lanzamiento (release) destaca la entrega de los Entregables Aceptados al Cliente y la
identificacin, documentacin e internalizacin de las lecciones aprendidas del proyecto.
Proceso 1: Enviar los Entregables
Ship Deliverables
Despus que el Product Owner valida los ____________ del Sprint basndose en los Criterios de
Aceptacin y de Terminado, los Entregables Aceptados estn listos para la entrega o lanzamiento a
los Interesados. Sin embargo, no todos los Sprints terminan en un lanzamiento. La decisin de cundo
la entrega es un incremento de producto potencialmente comercializable para los interesados es hecha
en el proceso Conduct Release Planning.
El Cronograma de Planificacin de Entrega (Release Planning Schedule) documenta qu entregables
sern liberados y cundo. De este modo, las entradas principales para este proceso son los
Entregables Aceptados y el Cronograma de Planificacin de Entrega.
Los entregables son lanzados utilizando los Mtodos de Despliegue de la Organizacin. Cada
organizacin tiene sus propios Mtodos de Despliegue. Estos guan cmo y cundo los entregables
sern liberados a los interesados. Las principales salidas de este proceso son los Entregables
Trabajados, Acuerdos de Entregables Trabajados y Lanzamientos de Producto.
1. Product Owner * 1. Mtodos de Despliegue de 1. Acuerdos de Entregables

2. Interesados * la Organizacin Trabajados (Working
3. Entregables Aceptados * (Organizational Deliverables Agreement)*
4. Cronograma de Deployment Methods) * 2. Entregables Trabajados
Planificacin de Entrega * 2. Plan de Comunicacin (Working Deliverables)
5. Scrum Master 3. Lanzamientos de Producto
6. Equipo Scrum (Product Releases)
7. Criterios de Aceptacin 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. Despus que todos los incrementos de producto son
entregados exitosamente a los interesados, el Equipo Core Scrum o los equipos revisan, analizan e
identifican qu se hizo bien y que no durante el ciclo del proyecto.
La reunin de Retrospectiva del Proyecto (Retrospect Project Meeting) tiene el objetivo de identificar
las mejores _______________ y recomendaciones para el Cuerpo de Asesoramiento Scrum (Scrum
Guidance Body). No solo ayuda a mejorar la colaboracin y eficiencia del equipo, tambin identifica
mejoras para toda la implementacin Scrum. Las sugerencias, opiniones y conocimientos obtenidos
en la reunin de Retrospectiva del Proyecto son registrados para referencias futuras.
1. Scrum Core Team(s)* 1. Reunin 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
Captulo Flujo Scrum - Preguntas
1. El conjunto de prioridades de trabajo a realizar se conoce como
A. Una historia de usuario.
B. La Cartera priorizada del producto.
C. Un grfico Burndown.
D. Aceptado entregables.
2. Cul de las siguientes es la definicin de una historia de usuario?

A. Una declaracin que describe la visin del producto.
B. Un documento que describe la prioridad de tareas a realizar en el proyecto.
C. Una declaracin que expresa la funcionalidad para el usuario final deseado.
D. Una historia que proporciona informacin sobre tareas similares completado en anteriores
proyectos de implementacin de Scrum.
3. Cmo se organizan los elementos de la Pila de Producto Priorizada (Prioritized Product

Backlog)?
A. Los artculos ms pequeos estn en la cima.
B. Los elementos con menos interdependencias estn en la parte superior.
C. Los elementos ms complejos estn en la cima.
D. Los elementos con el mayor valor de negocio estn en la cima.
4. Quin es el responsable de crear historias de los usuarios en el proceso Desarrollar

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

(Prioritized Product Backlog) en la fase de Planificacin y Estimacin recae en el
A. Equipo Scrum
B. Scrum Master
C. Product Owner
D. Equipo externo experimentado
6. Cul de los siguientes NO es una entrada para el proceso de Envo de Entregables (Ship
Deliverables)?
A. Entregables Aceptados
B. Crnonograma de Planificacin de Entregas
C. Product Owner
D. Impediment Log
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 aadido.
D. Cuando la alta direccin se siente que un elemento tiene que ser aadido.
8. Cul de las siguientes herramientas es utilizada por el Equipo Scrum para estimar en el
proceso de Estimacin de Tareas?
A. Experiencia en la escritura de Historias de Usuario
B. Wideband Delphi
C. Comparativo por Pares
D. Sesiones JAD
9. Cul 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 histrica del equipo que se utiliza como un indicador en la asignacin de tareas
para cada Sprint.
C. La velocidad del equipo es independiente de la composicin del equipo.
D. La velocidad del equipo se utiliza en la decisin de los plazos de entrega.
10. Cul de los siguientes no es discutido en una reunin Standup diaria (Daily Standup
Meeting)?
A. Lo que el miembro del equipo ha avanzado desde la ltima reunin
B. Lo que el miembro del equipo tiene previsto trabajar hasta la prxima reunin
C. Lo que el miembro del equipo ha aprendido al completar su trabajo
D. Las barreras que el miembro del equipo enfrenta
11. Cul es la duracin normal de una reunin Standup diaria (Daily Standup Meeting)?
A. 5 minutos
B. 1 hora
C. 15 minutos
D. Reuniones de stands-up no tienen lmite de tiempo.
12. Asegurar que las reuniones diarias de Standup se ejecutan de manera oportuna y
estructurada es la responsabilidad de
A. Scrum Master
B. Product Owner
C. Scrum Team Leader
D. Del grupo a nivel colectivo
13. El Sprint Burndown Chart es una herramienta utilizada por los equipos para
A. Medir el trabajo completado durante un Sprint.
B. Medir el trabajo que queda por realizar durante un Sprint.
C. Calcular el remanente del presupuesto del equipo.
D. Identificar los miembros de bajo rendimiento del equipo.
14. La reunin en la que el equipo discute las tareas a realizar en el prximo Sprint es conocido
como la:
A. Reunin de Visin de Producto (Product Vision Meeting).
B. Reunin de Planificacin del Sprint (Sprint Planning Meeting).
C. Reunin de Revisin de Sprint (Sprint Review Meeting).
D. Reunin de Restrospectiva del Sprint (Retrospect Sprint Meeting).
15. La reunin al final del Sprint en el que el equipo presenta su trabajo al Product Owner es
conocido como la:
16. La reunin en la que el equipo analiza el Sprint anterior e identifica mejoras potenciales
en los procesos se conoce como la:
17. Durante la reunin de revisin 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. Cul de las siguientes actividades NO es parte de la Reunin de Restrospectiva 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 cmo
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 tcnicos y de negocio se agregan al siguiente Sprint.
C. El mantenimiento del Product Backlog priorizado asegura tenerlo refinado antes de la
reunin de planificacin de Sprint para que el equipo tiene una mejor idea de los requisitos
antes de la reunin.
D.Todas las anteriores.
20. La responsabilidad de la preparacin 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. Cul de las siguientes actividades se pueden realizar en conjunto durante la reunin de
planificacin del Sprint (Sprint Planning Meeting)?
A. Estimacin Tareas y Planificacin de Entregas
B. Mantenimiento de la Pila de Producto y Planificacin de Tareas
C. Planificacin de Tareas y Tareas de Estimacin
D. Planificacin de Entregas y Mantenimiento de la Pila de Producto
22. Cul de las siguientes no es parte de la reunin de planificacin de Sprint?
A. El Product Owner, explica los principales elementos de la Pila de Producto priorizada para
el equipo.
B. El Equipo Scrum, en colaboracin con el Product Owner, estima las tareas de un Sprint
dado.
C. Sobre la base de las estimaciones, el equipo se compromete en algunas tareas que deben
completarse en el prximo Sprint.
D. El equipo recibe la retroalimentacin de las partes interesadas.
23. Usted es miembro de un equipo Scrum y se le indica que el gerente general de la empresa
ha solicitado que se desarrolle una tarea urgente que no forma parte del Sprint actual.
Qu debe hacer?
A. Hacerse responsable de la tarea, y hablar con el Product Owner para ampliar el plazo del
Sprint actual.
B. Hablar con el Scrum Master para volver a asignar las tareas a otra persona.
C. Hablar con el Product Owner para volver a a asignar las tareas a otra persona.
D. Informar al Scrum Master de la situacin para que revise la situacin con el gerente
general.
E. No realizar ninguna accin porque ya est ocupado.
24. Para cualquier Sprint en curso, cundo se pueden agregar nuevas historias de usuarios?
A. Cuando el Scrum Master agrega la historia de usuario a la Pila de Sprint (Sprint Backlog)
B. Cuando el Product Owner (propietario del producto) aprueba la historia de usuario
C. Cuando el equipo Scrum aprueba la historia de usuario
D. Nuevas historias de los usuarios nunca pueden ser aadidas al Sprint
25. Los Criterios Aceptacin:

A. Incrementan la ambigedad de los requerimientos.
B. Ayudan al equipo se ceirse a las normas de calidad relacionadas con la funcionalidad.
C. Son determinados por el Scrum Master en colaboracin con los miembros del equipo.
D. Son determinados por el Scrum Master en colaboracin con el Product Owner (propietario
del producto).
26. En cul de los siguientes procesos de la fase Iniciar se determina la duracin del Sprint?
A. Crear Visin del Proyecto
B. Desarrollar Epics
C. Crear la Pila de Producto Priorizada
D. Realizar la Planificacin de las Entregas (Conduct Release Planning)
ESCALANDO SCRUM
Escalabilidad de Scrum
Para ser eficaz, los Equipo Scrums deben tener idealmente de seis a diez miembros. Esta prctica
podra llevar a la idea errnea de que el mtodo de Scrum slo se puede utilizar para proyectos
pequeos. Sin embargo, se puede escalar fcilmente para el uso eficaz en proyectos grandes. En
situaciones donde el tamao del Equipo Scrum excede los diez miembros, mltiples Equipo Scrums
se pueden formar para trabajar en el proyecto. El proceso Convocar Scrum of Scrum facilita la
coordinacin entre los Equipo Scrums lo que permite una aplicacin efectiva en los proyectos grandes.
Los proyectos grandes o complejos a menudo se implementan como parte de un Programa o Portafolio.
El mtodo de Scrum tambin se puede aplicar para gestionar Programas y Portafolios. El enfoque
lgico de las directrices y los principios de este marco pueden utilizarse para gestionar proyectos de
cualquier tamao, que abarcan distintas geografas y organizaciones. Los proyectos grandes pueden
tener varios Equipos Scrums trabajando de forma paralela por lo que es necesario sincronizarse y
facilitar el flujo de informacin y mejorar la comunicacin.
El proceso Convocar _________ asegura esta sincronizacin. Los diversos Equipos Scrums estn
representados en esta reunin y el objetivo es proporcionar actualizaciones sobre del progreso, discutir
los retos que enfrentan durante el proyecto y coordinar las actividades. No hay reglas fijas en cuanto a
la frecuencia de estas reuniones. Los factores que determinan la frecuencia son el nivel de
dependencia entre los equipos, el tamao del proyecto, el nivel de complejidad y las recomendaciones
del Cuerpo de Asesoramiento de Scrum.
Scrum en Programas y Portafolios.
Programas
En los Programas, los roles principales para la gestin de Scrum son:
1. Product Owner del Programa define los objetivos y las prioridades estratgicas para el Programa.
2. Scrum Master del Programa Resuelve problemas, remueve Impedimentos, facilita y lleva a cabo
reuniones para el Programa.
Estas funciones son similares a las del Producto Owner y Scrum Master excepto que satisfacen las
necesidades del Programa o unidad de negocio en lugar de las de un slo Equipo Scrum.
Portafolios
En Portafolios, los roles importantes para la gestin de Scrum son:
1. Product Owner del Portafolio Define los objetivos estratgicos y las prioridades del Portafolio.
2. Scrum Master del Portafolio Resuelve problemas, elimina Impedimentos, facilita y lleva a cabo
reuniones para el Portafolio.
La siguiente figura ilustra cmo el mtodo Scrum se puede utilizar en toda la organizacin para los
Portafolio, Programa o Proyectos.
Scrum en toda la organizacin 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 pequeos 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
gestin de Programa tienen por objetivo ofrecer capacidades y llevar a cabo ciertas metas que
contribuyan a objetivos especficos del Programa. Por el contrario, el equipo de Portafolio tiene que
equilibrar los objetivos de los distintos Programas para alcanzar los objetivos estratgicos de la
organizacin en su totalidad.
La gestin de comunicacin con los equipos de Portafolio y Programas
Los problemas que se enfrentan al utilizar Scrum dentro de un Programa o Portafolio implican
principalmente la coordinacin entre los numerosos equipos. Esto puede conducir al fracaso si no
se gestiona con cuidado. Las herramientas utilizadas para la comunicacin deben ser escaladas
para que coincida con los requisitos de los equipos que participan en un Programa o un Portafolio.
Cada Equipo Scrum debe atender no slo la comunicacin interna, sino tambin la comunicacin
externa con otros equipos y los interesados del Programa o Portafolio.
Reuniones de Scrum of Scrums (SoS) Scrum of Scrums Meeting
Un Scrum of Scrums (SoS) Meeting es un elemento importante al escalar o ajustar Scrum a proyectos
___________. Por lo general, hay un representante en la reunin de cada uno de los Equipo Scrums.
Por lo general el representante es el Scrum Master, pero tambin puede asistir cualquier miembro del
Equipo Scrum si es necesario. Esta reunin es usualmente facilitada por el Jefe Scrum Master y su
objetivo es centrarse en las reas de coordinacin e integracin entre los diferentes Equipo Scrums.
Tal reunin se lleva a cabo en intervalos predeterminados o cuando lo requieran los Equipo Scrums.
En organizaciones donde hay varios Equipo Scrums trabajando en varias partes de un proyecto de
forma simultnea, SoS se puede escalar a otro nivel, esta se conoce como Scrum of Scrum of Scrums
Meeting. En esta situacin, una Reunin SoS mantiene la coordinacin de cada grupo de los Equipo
Scrums.
La Figura ilustra la dinmica de las reuniones Scrum of Scrums (SoS)
Reunin de Scrum of Scrums (SoS)
Transicin a Scrum
Los dos mtodos bsicos para hacer la transicin a Scrum son de ________________ y
de______________. En el mtodo de arriba hacia abajo, la transicin es comunicada en toda la
organizacin. Existe un esfuerzo por proveer capacitacin del cambio a todos los involucrados. Esta
comunicacin puede ser fuente de resistencia al cambio. La otra posibilidad es cambiar las cosas
gradualmente dentro de la cultura de la organizacin. Despus, la transicin a Scrum ser de forma
incremental.
Con una implementacin de arriba hacia abajo, podran haber conflictos de comunicacin. Por ejemplo,
un lder de ingeniera implant Scrum en su organizacin sin el consentimiento por parte del rea de
ventas. Esto llevara a grandes conflictos con el mismo Product Owner.
Otro aspecto a considerar de la transicin es saber el impacto de la transicin de la organizacin a los
mtodos Scrum. Toda organizacin puede hacer la transicin al mismo tiempo. Sin embargo, este
mtodo es ms susceptible a problemas que pueden resultar en la interrupcin de actividades que
generan ganancias. Por lo tanto, es generalmente preferible hacer la transicin en diferentes secciones
de forma iterativa para reducir el riesgo y proveer lecciones aprendidas para futuras iteraciones.
Mapeo de Roles tradicionales a Scrum
Los roles tradicionales del gestin de proyecto son divididos en tres roles en Scrum : ___________,
______________ y ________________.
El Producto Owner se comunica con los interesados y establece las prioridades del proyecto.
El Scrum Master ejecuta los deberes del jefe de proyecto porque remueve los impedimentos.
El Scrum Master, como el jefe de proyecto, es responsable de asegurar que los procesos
Scrum sean ejecutados adecuadamente.
Los miembros del Equipo tambin ejecutan algunos roles tradicionales del jefe de proyecto,
dado que ellos se autogestionan y son dueos de su tiempo. Esto permite que el equipo tenga
un sentido de pertenencia para que busque su propio xito.
Mantenimiento de la Participacin 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 participacin y el apoyo de los interesados.
Establecer un acuerdo de trabajo con los interesados para promover su colaboracin y
participacin efectiva.
Evaluar continuamente los cambios del proyecto que afectan a los interesados para asegurar
que nuevos interesados del proyecto estn comprometidos.
Mantener una comunicacin regular con los interesados.
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:
Comunquese 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:
Cul es el beneficio de implementar el Mtodo Scrum?

o Cmo este cambio crea __________ y / o evita ____________ para la organizacin?
o Cun imprescindible es adaptarser al actual ambiente de negocios?
Cules son los plazos lmite y costos de la transicin?
o Cul es el tiempo estimado para completar la trascicin y cul es el costo de la
transicin?
o Cules son los hitos principales para realizar la transicin?
o Qu tan frecuentemente los ejecutivos se va a reunir para revisar el avance del
proyecto?
Cules son los riesgos que involucra la transicin?
o Cules son obstculos o riesgos potenciales en la implementacin?
o Cul es el costo y tiempo adicional requerido para mitigar cada uno de estos riesgos?
Captulo Escalando Scrum - Preguntas
1. Cul de los siguientes NO es cierto con respecto a la implementacin de Scrum para
grandes proyectos?
A. Se requieren varios equipos para trabajar en sincrona.
B. Una Cartera priorizada del producto no es necesaria para monitorear el progreso de todos
los proyectos.
C. Un Jefe Product Owner es necesario para supervisar todos los proyectos.
D. Las tareas pueden no ser interdependientes entre los equipos.
2. Cul 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 podran afectar a otros equipos.
C. Hablar de los problemas que pueden haber surgido para cualquiera de los equipos de
Scrum.
D. Resolucin de Impedimentos que pueden haber surgido.
3. Cul 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 asignacin de recursos.
C. El Jefe de Producto Owner facilita el Scrum de Scrums.
D. El Jefe de Producto Owner es responsable del xito o fracaso del proyecto.
4. Cul de las siguientes es la responsabilidad del Producto Owner del programa?

A. Comunicar las metas y objetivos de Sprint a los miembros del Equpo Scrum.
B. Definir los objetivos y prioridades estratgicas para el Programa.
C. Establecer los criterios mnimos de terminado de los equipos.
D. Resolver problemas, eliminando los obstculos, facilitar y realizar reuniones para el
programa.
5. Cul de los siguientes procesos garantiza la sincronizacin y facilita el flujo de

informacin entre varios equipos Scrum que trabajan en paralelo en grandes proyectos
Scrum?
A. Convene Scrum of Scrums.
B. Conduct Daily Standup.
C. Retrospect Proyect.
D. Retrospect Sprint.

SMC Cuaderno de Trabajo

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SMC Cuaderno de Trabajo

Uploaded by

Copyright:

Available Formats

2014 SCRUMstudy.com v4.

Reglas Bsicas del Taller

Objetivos del Curso

Resultados del Curso

Metodologa del Curso

SMCTM SPOCTM AECTM

Membresa Bsica - Gratuita

Membresa Avanzada Cuota Anual

Acerca del Examen de Certificacin SMCTM Certification Exam

El gran inters 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 mtodo ms eficiente y efectivo de comunicar informacin 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 atencin continua a la excelencia tcnica y al buen diseo mejora la agilidad.

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

11. Las mejores arquitecturas, requisitos y diseos 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

Documentacin Slo mnima segn se requiera Exhaustivo

Estilo de Procesos Iterativo Lineal

Planificacin por Adelantada Baja Alta

Prioritizacin de los Segn el valor del negocio y

Garanta de Calidad Centrada en el Cliente Centrada en el Proceso

Organizacin Auto-organizada Gestionada

El Estilo de Gestin Descentralizado Centralizado

Las actualizaciones de Sistema formal de Gestin del

Liderazgo Colaborativo, Lder Servicial Mando y control

La Medicin del Rendimiento El valor del negocio Plan de la Conformidad

Al comienzo y a lo largo del

Vara en funcin del ciclo de

Scrum vs Mtodo Tradicional

2. Usted es el CEO de una empresa que maneja cuatro proyectos diferentes. En qu

3. Cul de los siguientes NO es parte del Manifiesto gil?

4. Como jefe de proyecto empleando prcticas giles en su organizacin, cul de los

5. Cul de los siguientes NO es verdadero con respecto a las metodologas giles?

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

3. En cul de los siguientes entornos proyectos Scrum NO son aplicables?

4. Cul 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 categoras:

Voz del Cliente - Voice of the Customer (VOC)

Interno (dentro de la misma organizacin)

Externo (fuera de la organizacin)

Define la Visin 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