SMC Cuaderno de Trabajo NH v2019
SMC Cuaderno de Trabajo NH v2019
SMC Cuaderno de Trabajo NH v2019
1
Membresía Básica - Gratuita
Esta membresía provee acceso a las principales páginas de información, foros de discusión general y
blogs limitados y recursos en línea. Los candidatos a la certificación deben tener por lo menos una
Membresía Básica para poder dar un examen de certificación de SCRUMstudy.
© 2019 SCRUMstudy.com 1
RESUMEN DE AGILE
El término agile (ágil) generalmente se refiere a ser capaz de moverse o responder rápidamente y
fácilmente. En cualquier tipo de disciplina de gestión, ser ágil es una cualidad, por lo tanto esto debe
ser una meta que se debe tratar de alcanzar. La gestión de Proyectos Agile especialmente, implica la
adaptabilidad durante la creación de un Producto, Servicio o cualquier otro Resultado.
Es importante entender que a pesar de que el desarrollo de los métodos ágiles es altamente adaptable,
de todos modos es necesario tener en cuenta la estabilidad en sus procesos de adaptación.
El permiso para copiar fue proporcionado por los autores mencionados mediante aviso en http://agilemanifesto.org/.
© 2019 SCRUMstudy.com 2
Las cuatro compensaciones de The Agile Manifesto se elaboran de la siguiente manera:
1. Individuos e interacciones sobre procesos y herramientas
2. Software funcionando sobre la documentación extensiva
3. Colaboración con el Cliente sobre la negociación contractual
4. Responder ante el cambio en vez de seguir un plan
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para que
como consecuencia procedan a ajustar y perfeccionar su comportamiento.
© 2019 SCRUMstudy.com 3
Métodos Agile
Una serie de metodologías ágiles se crearon y ganaron fuerza en la década de 1990 y principios del
2000. Si bien difieren en una variedad de aspectos, lo que tienen en común se deriva de su adhesión
a The Agile Manifesto.
Los siguientes métodos ágiles se discuten brevemente a continuación:
1. Lean Kanban
2. Extreme Programming (XP)
3. Crystal Methods
4. Dynamic Systems Development Methods (DSMD)
5. Feature Driven Development (FDD)
6. Test Driven Development (TDD)
7. Adaptive Software Development (ASD)
8. Agile Unified Process (AUP)
9. Domain-Driven Design (DDD)
Lean Kanban
El concepto de Lean optimiza el sistema de una organización para producir resultados valiosos sobre
la base de sus recursos, necesidades y alternativas, mientras reduce las pérdidas. Las pérdidas, por
ejemplo, podrían ser la construcción incorrecta de un Producto, el no saber aprender, o las prácticas
que impiden que el proceso fluya. Debido a que estos factores son de naturaleza dinámica, una
organización ágil evalúa la totalidad de su sistema y continuamente hace ajustes a sus procesos. El
fundamento de Lean es que la reducción de la duración de cada ciclo (es decir, una iteración) conduce
a un aumento de Productividad mediante la reducción de los retrasos, ayuda en la detección de errores
en una etapa temprana, y en consecuencia reduce la cantidad total de esfuerzo requerido para terminar
una tarea. Los principios de software Lean se han aplicado con éxito en el desarrollo de software.
Kanban significa literalmente un "cartel" o "cartelera” y enfatiza el uso de ayudas visuales para ayudar
y realizar un seguimiento de la producción. El concepto fue introducido por Taiichi Ohno, considerado
como el padre de los sistemas Toyota Proudction Systems (TPS).
Extreme Programming
Extreme Programming (XP), que se originó en Chrysler Corporation, ganó fuerza en la década de
1990. XP hace que sea posible mantener el costo de cambiar el software sin que éste aumente
radicalmente con el tiempo. Los atributos claves de XP incluyen el desarrollo gradual, horarios flexibles,
pruebas automatizadas de código, la comunicación verbal, el diseño en constante evolución,
Colaboración cercana y la vinculación de las unidades, de largo como de corto plazo, de todos los
involucrados.
Crystal Methods
Las metodologías de desarrollo de software Crystal fueron presentadas por Alistair Cockburn a
principios de 1990. Los métodos Crystal se centran en las personas, son ligeros y fáciles de adaptar.
Porque la gente es lo primordial, los procesos y las herramientas de desarrollo no son fijos sino que se
ajustan a las necesidades y características específicas del Proyecto.
Todos los métodos de Crystal tienen cuatro roles – patrocinador, diseñador principal, desarrolladores
y usuario experto. Los métodos Crystal recomiendan diversas estrategias y técnicas para lograr
agilidad. Un ciclo de proyectos Crystal consta de gráficos, ciclo de entrega y de recapitulación.
© 2019 SCRUMstudy.com 4
Dynamic Systems Development Methods (DSDM)
El marco Dynamic Systems Development Methods (DSDM) se publicó inicialmente en 1995 y es
administrado por el Consorcio DSDM. DSDM establece la calidad y el esfuerzo en términos de costo y
el tiempo desde el principio y ajusta los entregables del proyecto para cumplir con los criterios
establecidos, dando prioridad a las prestaciones en las siguientes categorías: lo que "deben tener",
"deberían tener", "podrían tener", y "no tendrán" (mediante la técnica Priorización MoSCoW). DSDM
es un método orientado al sistema con seis distintas fases de pre-proyecto; Viabilidad; Fundamentos;
Exploración e Ingeniería; Despliegue y Evaluación de Beneficios.
© 2019 SCRUMstudy.com 5
Scrum vs Gestión de Proyectos Tradicional
En la tabla se resumen muchas de las diferencias entre los modelos tradicionales de gestión de
proyectos y Scrum.
Gestión de Proyectos
Enfoque Scrum
Tradicional
© 2019 SCRUMstudy.com 6
Los proyectos Scrum se completan de manera iterativa entregando valor a lo largo del ciclo de vida del
proyecto. El beneficio del desarrollo iterativo es que permite la corrección a medida que todas las
personas involucradas obtengan una mejor comprensión de lo que debe ser entregado como parte del
proyecto, e incorporen lo aprendido de manera iterativa. Así, el tiempo y el esfuerzo requerido para
alcanzar el punto final definitivo, se reduce considerablemente y el equipo produce entregables que se
adaptan mejor al entorno empresarial.
Lanzamiento
© 2019 SCRUMstudy.com 7
Capítulo Visión de Agile y Scrum - Preguntas
1. ¿Cuál de las siguientes NO es una característica común de la gestión adaptativa de
proyectos?
A. Desarrollo iterativo del producto
B. Alto esfuerzo en la planificación adelantada (al inicio del proyecto)
C. Reduce el tiempo de lanzamiento al mercado
D. Entrega del producto flexible
2. Usted es el CEO de una empresa que maneja cuatro proyectos diferentes. ¿En qué
proyecto implementaría metodologías Ágiles?
A. Construcción de un edificio de departamentos multifamiliares de 5 plantas con 6
departamentos por piso.
B. Trabajo en la décima etapa de un proyecto de implementación a largo plazo de un software
en el que los requerimientos del proyecto fueron claramente definidos y la entrega, hasta
el momento, cumple con estos requerimientos.
C. El desarrollo de un aplicativo de software para un cliente para un ejercicio de gestión del
cambio que implica la identificación de las prácticas del estado actual y el desarrollo de
una hoja de ruta para el proceso del estado futuro en función de la visión del equipo de
gestión.
D. La construcción de un automóvil en una fábrica basada en un prototipo desarrollado con
anterioridad.
© 2019 SCRUMstudy.com 8
INFORMACIÓN GENERAL DE SCRUM
Scrum es una de las metodologías ágiles más populares. Emplea un enfoque adaptativo e iterativo
para gestionar proyectos y desarrollo de productos. Ha sido diseñada para ser una manera rápida,
flexible y eficaz para ofrecer valor significativo de forma ágil en todo el proyecto.
El marco de Scrum, tal como se define en la Guía SBOK™, puede ser mejor entendido a través de sus
principios, procesos y aspectos.
Principios Scrum
1. Control del Proceso Empírico —Scrum establece que la toma de decisiones basada en la
observación y experimentación es mejor que la planificación detallada al inicio del proyecto.
Se basa en las tres ideas principales: transparencia, inspección y adaptación.
© 2019 SCRUMstudy.com 9
2. Auto-organización —Este principio se centra en los miembros del equipo, quienes entregan
un valor significativamente mayor cuando son auto-organizados, lo cual genera equipos muy
comprometidos y con un alto nivel de responsabilidad compartida; a su vez, esto produce un
entorno innovador y creativo que es más propicio para el crecimiento. Además de motivar al
equipo y mejorar su rendimiento.
© 2019 SCRUMstudy.com 10
3. Colaboración —Este principio se centra en las tres dimensiones básicas relacionadas con el
trabajo colaborativo:
a. Conocimiento : Las personas que trabajan juntas deben estar al tanto del trabajo de
los demás.
b. Articulación: Los colaboradores deben repartir el trabajo en unidades, dividir las
unidades entre los miembros del equipo, y después que el trabajo esté hecho,
reintegrarlo.
c. Apropiación: La adaptación de tecnología a propia situación individual; la tecnología
puede utilizarse de una manera completamente diferente de lo esperado por los
diseñadores.
4. Priorización basada en el valor —Este principio pone de relieve el enfoque de Scrum para
ofrecer el máximo valor de negocio, desde el principio del proyecto hasta su conclusión.
5. Time-boxing —Este principio describe cómo el tiempo es considerado como una restricción
limitante en Scrum, y cómo se utiliza para ayudar a manejar eficazmente la planificación y
ejecución del proyecto.
© 2019 SCRUMstudy.com 11
6. Desarrollo Iterativo — Este principio define el desarrollo iterativo y enfatiza cómo manejar
mejor los cambios y crear productos que satisfagan las necesidades del Cliente. También
delinea las responsabilidades del Product Owner y de la organización relacionadas con el
desarrollo iterativo.
Un principio esencial de Scrum es que los requerimientos de cualquier proyecto de largo plazo no
pueden ser entendidos completamente o definidos al inicio del proyecto, especialmente si el mercado
sufre cambios constantemente, por lo que este enfoque debe permitir que el equipo sea flexible para
incorporar cambios de requerimientos. En el enfoque tradicional, el método predictivo de desarrrollo
no puede manejar tales cambios. En cambio, Scrum es especialmente útil para proyectos complejos
con gran incertidumbre en los cuales los pronósticos de largo plazo podrían conllevar a riesgos críticos.
Scrum guía a través de la transparencia, inspección y adaptación para alcanzar los resultados más
valiosos de negocio.
Aspectos Scrum
Los aspectos de Scrum se deben abordar y gestionar a lo largo de un proyecto Scrum. Los cinco
aspectos de Scrum son:
© 2019 SCRUMstudy.com 12
1. Organización
© 2019 SCRUMstudy.com 13
2. Justificación de Negocio
© 2019 SCRUMstudy.com 14
© 2019 SCRUMstudy.com 15
3. Calidad
© 2019 SCRUMstudy.com 16
4. Cambio
© 2019 SCRUMstudy.com 17
5. Riesgo
© 2019 SCRUMstudy.com 18
Procesos de Scrum
Los procesos de Scrum abordan las actividades y el flujo específico de un proyecto Scrum. En total
hay diecinueve procesos que se agrupan en cinco fases.
© 2019 SCRUMstudy.com 19
¿Por qué utilizar Scrum?*
Algunas de las ventajas principales de la utilización de Scrum en cualquier proyecto son:
1. Adaptabilidad — El Control del Proceso Empírico y la Entrega Iterativa hacen que los
proyectos sean adaptables y abiertos a la incorporación de cambios.
2. Transparencia —Todos los radiadores de información tales como el Scrumboard y el Sprint
Burndown Chart son compartidos, lo que promueve un ambiente de trabajo abierto.
3. Retroalimentación Continua — Se proporciona a través de los procesos: Ejecutar Reuniones
Diarias y Demostrar y Validar.
4. Mejora Continua —Los entregables se mejoran progresivamente Sprint por Sprint a través
del proceso de Mantenimiento del Product Backlog.
5. Entrega Continua de Valor—los procesos iterativos permiten la entrega continua de valor tan
frecuentemente como el Cliente lo requiere a través del proceso Enviar los Entregables.
6. Ritmo Sostenible — Los procesos Scrum están diseñados de tal manera que las personas
involucradas pueden trabajar a un mismo ritmo que, en teoría, se puede continuar
indefinidamente.
7. Entrega Temprana de Alto Valor—El proceso de Crear el Product Backlog Priorizado
asegura que los requisitos de mayor valor del Cliente sean los primeros en satisfacerse.
8. Proceso de Desarrollo Eficiente— El time-boxing y la reducción al mínimo el trabajo que no
es esencial conduce a mayores niveles de eficiencia.
9. Motivación—Los procesos de Ejecutar la Reunión Diaria y la Retrospectiva del Sprint
conducen a mayores niveles de motivación entre los empleados.
10. Resolución de Problemas de forma más Rápida— Colaboración y la coubicación de equipos
multi-funcionales conducen a la resolución de problemas con mayor rapidez.
11. Entregables Efectivos—El procesos de Crear el Product Backlog Priorizado y revisiones
periódicas después de la creación de entregables asegura entregas efectivas para el Cliente.
12. Centrado en el Cliente — El poner énfasis en el valor del negocio y tener un enfoque de
colaboración con los interesados asegura un marco orientado al Cliente.
13. Entorno de Alta Confianza—Los procesos de Ejecutar la Reunión Diaria y la Retrospectiva
del Sprint promueven transparencia y colaboración, dando lugar a un ambiente de trabajo de
alta confianza, asegurando así una baja fricción entre los empleados.
14. Responsabilidad Colectiva—El proceso de Aprobar, Estimar y Comprometerse con Historias
de Usuario permite que los miembros del equipo se sientan responsables del proyecto, así su
trabajo tiene una mejor calidad.
15. Alta Velocidad—Un marco de colaboración que le permite a los equipos multi-funcionales
altamente calificados alcanzar su potencial y alta velocidad.
16. Medio Ambiente Innovador—Los procesos Retrospectiva del Sprint y Retrospectiva del
Proyecto crean un ambiente de introspección, aprendizaje y capacidad de adaptación que lleva
a un entorno de trabajo innovador y creativo.
© 2019 SCRUMstudy.com 20
Capítulo Visión General Agile y Scrum - Preguntas
1. El control del proceso empírico es un principio de Scrum que:
A. Es utilizado en casos en los que las entradas están claramente definidas.
B. Se centra en proporcionar control a través de inspecciones y adaptaciones frecuentes de
los procesos que están perfectamente definidos.
C. Se utiliza en situaciones en las que los procesos generan salidas impredecibles e
irrepetibles.
D. Se utiliza cuando una entrada particular ofrece siempre una salida específica.
2. Todos los siguientes son parte de los principios del Scrum EXCEPTO:
A. La auto-organización
B. Time-boxing
C. Priorización basada en valor
D. Control de procesos definidos
© 2019 SCRUMstudy.com 21
LOS ROLES DE SCRUM
Roles Básicos —Los Roles Básicos son las funciones que obligatoriamente se requieren para
producir el producto o servicio del proyecto, estos están comprometidos con el proyecto, y son los
responsables del éxito de cada Sprint y del proyecto en su totalidad.
Roles no Básicos: son las funciones que no son obligatoriamente necesarias para el proyecto
Scrum, y pueden incluir miembros de los equipos que están interesados en el proyecto, pero no
tienen ningún papel formal en el equipo del proyecto. Ellos pueden interactuar con el equipo, pero
no son responsables del éxito del proyecto. Estos roles no esenciales también deben tenerse en
cuenta en cualquier proyecto de Scrum.
Core Roles
Hay tres Roles Básicos (roles/funciones principales) en Scrum que son los responsables de cumplir
con los objetivos del proyecto. Los roles básicos son el Product Owner, Scrum Master, y el Equipo
Scrum. Juntos se les conoce como el Equipo Central/Principal de Scrum (Scrum Core Team). Es
importante tener en cuenta que, de estos tres roles, ninguno tiene autoridad sobre los otros.
La figura presenta un resumen de los roles principales del Equipo Core de Scrum.
© 2019 SCRUMstudy.com 22
Core Role: Product Owner (Dueño del Producto)
El Product Owner representa a los interesados y es responsable de asegurar que el Equipo Scrum
entregue valor, a través del producto, al proyecto. El Product Owner escribe los requerimientos de
negocio en la forma de Historias de Usuario con apoyo de los miembros del Equipo Core Scrum;
también gestiona el Product Backlog (cartera de pendientes) en el proceso Priorizar el Product Backlog.
En algunos casos, los miembros del Equipo Scrum podrían escribir las User Stories (Historias de
Usuario) bajo la supervisión del Product Owner. El Product Owner es también responsable de asegurar
la comunicación clara de las funcionalidades del producto al Equipo Scrum, por lo que también es
conocido como la Voz del Cliente
De la misma forma que existe un rol de Product Owner en un proyecto, podría haber un Product Owner
del Programa en un Programa, o un Product Owner del Portafolio en un Portafolio.
© 2019 SCRUMstudy.com 23
Core Role: Scrum Master
La responsabilidad principal del Scrum Master es asegurarse que los procesos Scrum sean aplicados
correctamente por todos los miembros del Equipo Core Scrum, incluyendo al Product Owner. El Scrum
Master es la persona responsable de garantizar que la gestión de proyectos avance sin problemas y
que los miembros del Equipo Scrum tengan todas las herramientas necesarias para hacer su trabajo.
El rol del Scrum Master se basa en el concepto de Liderazgo Servicial en el cual los líderes logran
resultados atendiendo a las necesidades de aquellos a quienes lideran.
De la misma forma que existe un rol de Scrum Master en un proyecto, podría haber un Scrum Master
del Programa en un Programa, o un Scrum Master del Portafolio en un Portafolio.
La tabla resume las responsabilidades del Scrum Master en los diferentes procesos de Scrum.
© 2019 SCRUMstudy.com 24
Core Role: Scrum Team- Equipo Scrum
El Equipo Scrum es un grupo o equipo de personas que son responsables de la comprensión de los
requerimientos de negocio especificados por el Product Owner, de la estimación de Historias de
Usuarios y de la creación de los entregables del proyecto.
Multi-funcionales:
Un equipo coubicado conformado por expertos funcionales que colaboran para alcanzar un
objetivo común tendrá mayor probabilidad de éxito que un equipo que trabaja separado
físicamente de acuerdo a la función que realiza.
© 2019 SCRUMstudy.com 25
Cuando un Equipo Scrum necesita ser distribuido, el Scrum Master debe garantizar que las
técnicas de comunicación eficaces estén disponibles para que los equipos puedan auto-
organizarse y trabajar con eficacia.
Entrega Iterativa de Producto:
La siguiente tabla muestra las responsabilidades del Equipo Scrum durante los diferentes procesos
de Scrum.
© 2019 SCRUMstudy.com 26
Etapas de Desarrollo de Equipos
El método de Scrum inicialmente pueden parecer muy diferente y difícil para un nuevo Equipo Scrum.
Un nuevo Equipo Scrum, al igual que cualquier otro equipo nuevo, por lo general se desenvuelve a
través de un proceso de cuatro etapas. Este proceso se conoce como Modelo de Dinámica de Equipo
de Tuckman (Tuckman, 1965).
Las cuatro etapas del modelo son las siguientes:
Forming (Formación) Este a menudo se experimenta como un escenario divertido porque todo es
nuevo y el equipo aún no ha encontrado ninguna dificultad con el proyecto.
Storming (Turbulencia) Durante esta etapa, el equipo trata de cumplir con el trabajo. Sin embargo,
puede encontrar conflictos de poder y con frecuencia hay caos o confusión entre los
miembros del equipo.
Norming (Normalización) En esta fase es cuando el equipo comienza a madurar, resolver sus
diferencias internas y encontrar soluciones para así trabajar juntos.
Performing (Desempeño) Durante esta etapa, el equipo está unido y opera en su nivel más alto en
términos de rendimiento. Los miembros se han convertido en un equipo eficiente de
profesionales que son consistentemente productivos.
© 2019 SCRUMstudy.com 27
Selección del Equipo
El Equipo Scrum es la base de cualquier Proyecto de Scrum y el tener a los miembros adecuados para
el equipo es vital para la entrega exitosa del proyecto. Los miembros del Equipo Scrum son
especialistas generalistas ya que cuentan con conocimiento de diversos campos y son expertos en al
menos uno. Más allá de la experiencia en la materia, son las habilidades interpersonales de cada
miembro del equipo que determinará el éxito de los equipos auto-organizados.
Los miembros ideales del Equipo Scrum son independientes, auto-motivados, enfocados al cliente y
tienen un sentido alto de responsabilidad y de colaboración.
Cuando se selecciona el equipo, un aspecto importante es crear respaldos para cada miembro del
equipo. Esto asegura evitar que haya una disminución importante de la productividad debido a la
pérdida de miembros críticos.
Es un término colectivo que incluye a los Clientes, los usuarios y patrocinadores, que a menudo
interactúan con el Product Owner, Scrum Master y Equipo Scrum para proporcionarles
información y para ayudar en la creación del producto, servicio, o cualquier otro resultado del
proyecto. Los interesados influyen en el proyecto a lo largo del desarrollo del proyecto.
También pueden desempeñar un papel en los procesos importantes de Scrum tales como:
Desarrollo de Epic(s), Crear Product Backlog Priorizados, Ejecutar la Planificación de la
Entrega, Retrospectiva del Sprint.
© 2019 SCRUMstudy.com 28
Cliente
El Cliente es la persona o la organización que adquiere el producto, servicio, o cualquier otro
resultado del proyecto. Para cualquier organización, dependiendo del proyecto, pueden haber
Clientes internos (es decir, dentro de la misma organización) o Clientes externos (es decir,
fuera de la organización).
Usuarios
Patrocinador
El patrocinador es la persona o la organización que provee recursos y apoyo para el proyecto.
El patrocinador es también el interesado, a quien todos le deben rendir cuentas al final.
A veces, la misma persona u organización pueden desempeñar múltiples funciones – el
interesado, por ejemplo, el patrocinador y el cliente puede ser el mismo.
© 2019 SCRUMstudy.com 29
Capítulo Roles de Scrum - Preguntas
1. ¿Cuál de los siguientes es un rol esencial (core) de Scrum?
A. Product owner
B. Interesado
C. Patrocinador del proyecto
D. Administrador del proyecto
2. ¿Quién de los siguientes es responsable de proporcionar al Equipo de Scrum de un
ambiente favorable para la creación de entregables?
A. Scrum Master
B. Product Owner
C. Cuerpo de Asesoramiento de Scrum (SGB)
D. Interesados externos
3. ¿Quién de los siguientes es el responsable de crear una conciencia de las prácticas de
Scrum entre los miembros del Equipo de Scrum?
A. Scrum Master
B. Product Owner
C. Equipo de Scrum
D. Cuerpo de Asesoramiento de Scrum (SGB)
© 2019 SCRUMstudy.com 30
FASES SCRUM
La figura a continuación proporciona una visión general del flujo de un proyecto Scrum.
• El ciclo de Scrum comienza con la Fase de Inicio, durante la cual se determina la Visión del
Proyecto y se crea el Product Backlog (Cartera de Necesidades) priorizado.
• Luego el trabajo es completado en varios Sprints. Cada Sprint comienza con una Reunión de
Planificación del Sprint (Sprint Planning Meeting) durante la cual son escogidas las tareas (los
elementos con prioridad alta del Product Backlog) para el Sprint próximo a comenzar.
• Un Sprint suele durar entre 1 - 6 semanas en el cual el Equipo Scrum trabaja en la elaboración
Entregables (Deliverables) potencialmente listos en incrementos de producto.
• Las reuniones diarias (Daily Stand-up Meeting) se llevan a cabo durante el Sprint donde Los
miembros del Equipo Scrum reportan el trabajo avanzado, el trabajo que se proponen terminar y
los impedimentos que están afrotando.
• Al final del Sprint, se lleva a cabo una reunión de revisión del Sprint (Sprint Review Meeting) en el
cual se le presenta una demostración del trabajo terminado al Product Owner y a los interesados
relevantes. El Product Owner acepta o rechaza los entregables presentados.
• El ciclo de Sprint termina con una Reunión de la Retrospectiva del Sprint (Retrospect Sprint
Meeting).
© 2019 SCRUMstudy.com 31
FASE: INICIAR
La primera fase de método Scrum es la fase Iniciar. Los procesos relacionados con la iniciación de un
proyecto son los siguientes:Crear la Visión del Proyecto, Identificar al Scrum Master e interesados,
Formar el Equipo Scrum, Desarrollar Epicas, Crear la Lista de Pendientes del Producto Priorizada,
Realizar la Planificación de la Lanzamiento.
© 2019 SCRUMstudy.com 32
Caso de Negocio del Proyecto (Project Business Case) *
Un caso de negocio (business case) puede ser un documento bien estructurado o simplemente una
declaración verbal que expresa la razón para iniciar un Proyecto. Puede ser formal y detallado, o
informal y breve. Independientemente del formato, a menudo incluye información sustancial sobre los
antecedentes del Proyecto, los objetivos del negocio y los resultados deseados, un análisis FODA
(SWOT), Análisis de Brechas, una lista de los Riesgos identificados, y las estimaciones de tiempo, el
esfuerzo y costo.
El Proyecto se inicia con la presentación del Caso de Negocio. El caso de negocio se presenta a los
interesados y patrocinadores para que comprendan los beneficios de negocio esperados del Proyecto.
Finalmente los patrocinadores confirman que van a proporcionar los recursos financieros para el
Proyecto.
Reunión de la Visión del Proyecto
Reunión de la Visión del Proyecto es una reunión con los interesados del Programa, el Product Owner
del Programa, el Scrum Master del Programa y el jefe del Product Owner. Ayuda a identificar el contexto
empresarial, Requisitos del Negocio y las expectativas de los interesados con el fin de desarrollar una
Declaración de la Visión del Proyecto eficaz. Scrum cree en la participación y colaboración cercana
con todos los representantes de las compañía para que estén convencidos de apoyar al Proyecto.
Product Owner Identificado
Uno de los resultados de este proceso es identificar al Product Owner. El Product Owner es la persona
responsable de lograr el valor máximo empresarial para el Proyecto. Él o ella también es responsable
de la articulación de requisitos por parte de los Clientes y de mantener la Justificación de Negocio para
el Proyecto. El Product Owner representa la voz del Cliente.
Cada Equipo Scrum tendrá un Product Owner designado. Un pequeño Proyecto puede tener sólo un
Product Owner, mientras que los Proyectos más grandes pueden tener varios. Estos Product Owners
son responsables de la gestión del Product Backlog Priorizado. Ellos escriben los Historias de Usuarios
y gestionan el mantenimiento del Product Backlog.
© 2019 SCRUMstudy.com 33
Declaración de la Visión del Proyecto
El resultado clave del proceso Crear la Visión del Proyecto es la Declaración de la Visión del Proyecto.
Una buena visión del Proyecto explica la necesidad del negocio y que es lo que el Proyecto tiene como
objetivo satisfacer, en lugar de cómo se va a satisfacer la necesidad.
La Declaración de la Visión del Proyecto no debería ser muy específica y debe ser flexible. Es posible
que el conocimiento actual sobre el Proyecto esté basado en suposiciones que luego van a cambiar
conforme avanza el Proyecto, por lo que es importante que la visión del Proyecto sea lo suficientemente
flexible como para adaptarse a estos cambios. La visión del Proyecto debe centrarse en el problema y
no en la solución.
Un proyecto Scrum empieza cuando una necesidad de negocio y la visión son identificadas; entonces
se puede continuar con la identificación de los interesados del proyecto tales como el patrocinador,
usuarios finales, proveedores, etc, quienes estarán impactados por la necesidad de negocio o
ayudarán a llevarla a cabo. Por lo tanto, una vez que la Visión del Proyecto esté lista, el Product Owner
procede a identificar todos los interesados del proyecto. Dentro de este proceso, el Product Owner
identifica al Scrum Master, quien ayuda al Product Owner a cumplir con la Visión del Proyecto siendo
el jefe facilitador y mentor del Equipo Scrum.
© 2019 SCRUMstudy.com 34
Es importante que cuando el Product Owner seleccione al Scrum Master tenga en cuenta sus
habilidades de resolución de conflictos, que encarne el estilo de gestión : Liderazgo Servicial y que se
comprometa a brindar al Equipo Scrum un ambiente propicio para la entrega exitosa del proyecto.
Criterios de selección
La selección adecuada del Scrum Master y la identificación de los interesados adecuados es crucial
para el éxito de cualquier proyecto. En algunos proyecto puede haber pre-condiciones que estipulen
determinados miembros del equipo y sus roles.
Cuando hay flexibilidad en la elección del Scrum Master, se deben considerar los siguientes criterios
de selección:
1. Habilidades para la resolución de problemas—Es uno de los principales criterios a considerar al
seleccionar al Scrum Master. El Scrum Master debe tener las habilidades y experiencia necesarias
para ayudar a eliminar cualquier Impedimento que encare el Equipo Scrum.
2. Disponibilidad—El Scrum Master debe estar disponible para agendar, supervisar y facilitar las
reuniones, incluyendo Release Planning Meeting, Daily Standup Meeting, y otras reuniones
relacionadas al Sprint.
3. Compromiso—El Scrum Master se debe comprometer a que el Equipo Scrum esté dotado de un
ambiente de trabajo propicio para asegurar la entrega exitosa del proyecto Scrum.
4. Líder Servicial
En la identificación de los Interesados es importante recordar que los Interesados incluyen a todos los
clientes, los usuarios y patrocinadores, quienes a menudo interactúan con el Product Owner, Scrum
Master y Equipo Scrum para proveer entradas y facilitar la creación de los productos del Proyecto. Los
Interesados influyen en el proyecto a lo largo de su ciclo de vida.
Scrum Master Identificado
Un Scrum Master es un facilitador y Líder Servicial que se asegura de que el Equipo Scrum esté dotado
de un ambiente propicio para completar el Proyecto con éxito. El Scrum Master guía, facilita y enseña
prácticas de Scrum a todos los involucrados en el Proyecto; elimina impedimentos que encara el
equipo; y asegura que se estén siguiendo los procesos de Scrum. Es la responsabilidad del Product
Owner identificar al Scrum Master para un proyecto Scrum.
Interesados Identificados
Los interesados, término colectivo que incluye a los Clientes, los usuarios y los patrocinadores, quienes
con frecuencia interactúan con el Equipo Core Scrum, influyen en el Proyecto durante todo el proceso
de desarrollo de Productos.
© 2019 SCRUMstudy.com 35
El Product Owner y el Scrum Master colaboran para formar el Equipo Scrum. El Equipo Scrum es
formado teniendo en cuenta la Visión del Proyecto porque el tipo de proyecto y el tipo de industria son
factores cruciales en la selección de expertos técnicos. Sin embargo el Product Owner y el Scrum
Master podría considerar otros factores como los requerimientos de personal, disponibilidad y
compromiso de las personas y la matriz de destrezas requeridas.
Una vez que el Equipo Scrum es seleccionado, el Equipo Core Scrum (Product Owner, Scrum Master
y Equipo Scrum) está completo. La salida más importante de este proceso es un equipo multifuncional
y auto-organizado.
Los miembros ideales del Equipo Scrum son independientes, auto-motivados, se enfocan en el Cliente,
y tienen un alto sentido de responsabilidad y colaboración. El equipo debe ser capaz de fomentar un
ambiente de reflexión independiente y de tomar decisiones con el fin de extraer los mayores beneficios
de la estructura.
© 2019 SCRUMstudy.com 36
Personas son personajes de ficción con descripción muy detallada que representan a la mayoría de
los usuarios u otros interesados que no utilizan directamente el producto final.
La Reunión de Grupo de Usuarios involucre a los interesados del proyecto, principalmente los usuarios
o Clientes del Producto. Ellos proporcionan al Equipo Core de Scrum información de primera mano
acerca de las expectativas del usuario. Esto ayuda en la formulación de los Criterios de Aceptación
para el Producto y proporciona información valiosa para el desarrollo de Epics.
Creación de una Persona
Esto implica la asignación al personaje de un nombre ficticio y preferentemente una foto. A la Persona
se le incluirán atributos muy específicos como su edad, género, nivel de educación, entorno, intereses
y metas. Una cita que ilustra las necesidades de la persona puede ser incluida también. A continuación
se muestra un ejemplo de una Persona para un sitio web de viajes.
© 2019 SCRUMstudy.com 37
Proceso 5: Crear la Lista de Requerimientos Pendientes del Producto
Priorizada
© 2019 SCRUMstudy.com 38
La priorización tienen en cuenta tres factores principales: valor, riesgo e incertidumbre, y
dependencias. El Equipo Core Scrum podría utilizar varios métodos de priorización como los
mencionados a continuación:
Análisis Kano : El análisis Kano fue desarrollado por Noriaki Kano (1984) , Esta técnica puede
ser utilizada para clasificar las preferencias del cliente en cuatro categorías, a las cuales nos
referiremos como Exciters/ Delighters, Satisfiers, Dissatisfiers e Indifferent.
o Entusiamados (Exciters/Delighters): Funcionalidades nuevas o de alto valor para el
cliente.
o Satisfechos (Satisfiers): Funcionalidades que ofrecen valor al cliente.
o Insatisfechos (Dissatisfiers): Funcionalidades que, si no están presentes, probablemente
causen que el cliente esté disgustado con el producto, sin embargo no afecta el nivel de
satisfacción si ellos están presentes.
o Indiferentes (Indifferent): Funcionalidades que no afectan al cliente de ninguna forma y
deben ser eliminadas.
© 2019 SCRUMstudy.com 39
Esquema de Priorización MoSCoW—El esquema de priorización MoSCoW deriva su nombre
de las primeras letras de las frases "Must have" (Debe tener), “Should have” (Debería tener),
"Could have” (Podría tener), y "Would like to have, but not at this time” (Quisiera tenerlo, pero
no ahora). Las etiquetas están en orden decreciente de prioridad. "Debo tener" estas Historias
de Usuarios: son aquellas que si no son incluidas en el producto, este no tendrá valor y
"Quisiera, pero no ahora" estas Historias de Usuarios: son aquellas que, a pesar de que sería
bueno tenerlas, no es necesario incluirlas.
Comparación por Pares (Paired Comparison)— En esta técnica se prepara una lista de
todas las Historias de Usuarios del Product Backlog Priorizado. Luego, cada Historia de
Usuario se toma de forma individual y se compara con las otras Historias de Usuarios en la
lista, uno a la vez. Cada vez que dos Historias de Usuarios se comparan, se toma una decisión
sobre cuál de los dos es más importante. A través de este proceso, se puede obtener una lista
priorizada de las Historias de Usuarios.
Método de los 100 Puntos (100-point method) — Fue desarrollado por Dean Leffingwell y
Don Widrig (2003). Se trata de dar al Cliente 100 puntos que puede usar para votar por las
Historias de Usuarios más importantes. El objetivo es dar más peso a las Historias de Usuarios
que son de mayor prioridad en comparación con las otras Historias de Usuarios disponibles.
Cada miembro del grupo asigna puntos a las diversas Historias de Usuarios, dando más puntos
a aquellas que consideran más importantes. Al finalizar el proceso de votación, la Priorización
se determina calculando el total de puntos asignados a cada Historia de Usuario.
Criterios de Terminado (“Done”)
Es un conjunto de reglas que se aplican a todas las Historias de Usuarios. Una definición clara de
“Done” es crítica, ya que elimina la ambigüedad de los requisitos y ayuda a que el equipo se adhiera a
las normas de calidad obligatorias. Esta definición se utiliza para crear los Criterios de Terminado, que
son un resultado del proceso de Crear la Lista de Requerimientos Pendientes del Producto. Una
Historia de Usuario se considera Terminada (“Done”) cuando se muestra y es aprobada por el Product
Owner que juzga sobre la base de los Criterios de Terminado y los Criterios de Aceptación de la Historia
del Usuario.
© 2019 SCRUMstudy.com 40
Proceso 6: Realizar la Planificación de Versiones
© 2019 SCRUMstudy.com 41
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.
© 2019 SCRUMstudy.com 42
El formato de una Historia de Usuario es el siguiente:
Como <rol del usuario> deseo <descripción del requerimientos> para <beneficio>.
Junto con las Historias de Usuario, el Equipo Core Scrum escribe los Criterios de Aceptación. Las
Historias de Usuario son a veces subjetivas, por lo que los Criterios de Aceptación brinda la objetividad
requerida para las Historias de Usuario para ser consideradas como Terminadas o no Terminadas
durante la Revisión de un Sprint.
Los Criterios de Aceptación ayudan al equipo a entender qué se espera de una Historia de Usuario,
eliminan la ambigüedad de los requerimientos y ayuda a alinear expectativas. El Product Owner define
y comunica el Criterio de Aceptación al Equipo Scrum. En los Sprint Review Meetings, el Critero de
Aceptación brinda el contexto para que el Product Owner decida si la Historia de Usuario ha sido
completada satisfactoriamente. Es importante, y es responsabilidad del Scrum Master, asegurar que
el Product Owner no cambie los Criterios de Aceptación de una Historia de Usuario, mientras este se
esté ejecutando, que ya está comprometida a un Sprint,.
© 2019 SCRUMstudy.com 43
Algunas herramientas conocidas que se pueden utilizar para este proceso son:
Wideband Delphi
Es una técnica de estimación grupal para determinar cuánto trabajo está involucrado y cuánto
tiempo tomará completarlo. Los participantes de forma anónima proveen estimaciones de cada
funcionalidad, y estas estimaciones iniciales son graficadas en un cuadro. El equipo entonces
discute sobre los factores que influenciaron en sus estimations y se procede a realizar una
segunda ronda de estimación. Este proceso se repite hasta que el estimado de los participantes
converja y se llegue a un consenso en el estimado final. La información de cada participantes se
recolecta de forma que se evite el problema de pensamiento de grupo (group think).
Planificación Poker (Planning Poker)
También llamada Estimación Poker, es una forma de aplicar Wideband Delphi. Es una técnica de
estimación donde se utiliza el consenso para estimar tamaños relativos de Historias de Usuario o
el esfuerzo requerido para crearlos.
En Planificación Poker, a cada miembro se le asigna una baraja de cartas, cada carta está
numerada en una secuencia. Estos números representan la complejidad del problema, en
términos de tiempo o esfuerzo. El Product Owner escoge una Historia de Usuario del Product
Backlog Priorizado y lo presenta al equipo. Los miembros del Equipo Scrum evalúan la Historia
de Usuario y tratan de entenderla mejor antes de dar su estimación para desarrollarla. Entonces
cada miembro elige una carta de la baraja que represente su estimado para la Historia de Usuario.
Si la mayoría o todos los miembros del equipo eligen la misma carta, entonces esta será la
estimación de la Historia de Usuario. Si no hay consenso, entonces los miembros del equipo
discuten las razones por la que seleccionaron diferentes cartas o estimaciones. Después de la
discusión, vuelven a escoger una carta. Se siguen los mismos pasos hasta que los supuestos
sean comprendidos y los malentendidos sean resueltos, de esta forma se alcanzará consenso en
la estimación. La Planificación Poker promueve la interacción entre los participantes y mejora la
comunicación. También permite el pensamiento independiente de los participantes evitando el
fenómeno de pensamiento de grupo.
© 2019 SCRUMstudy.com 44
El número de dedos usados para votar indica cuán de acuerdo está el participante con el tema
propuesto y si tiene observaciones que desea discutir con el grupo:
Un dedo: Estoy en desacuerdo con la conclusión del grupo y tengo preocupaciones
importantes que deseo revisarlas con el grupo.
Dos dedos: Estoy en desacuerdo con la conclusión del grupo y quisiera revisar con el
grupo algunas preocupaciones menores.
Tres dedos: No estoy seguro pero elijo estar de acuerdo con la conclusión del grupo.
Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y quisiera discutir algunos
temas menores.
Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo.
Estimación Relativa / Puntos de Historia (Relative Sizing / Story Points)
Además de ser utilizada para la estimación de costos, los story points pueden también servir para
la estimación de toda una Historia de Usuario o funcionalidad. Este enfoque asigna un valor de
Story Point basado en una evaluación completa del tamaño de la Historia de Usuario considerando
el riesgo, el esfuerzo requerido y el nivel de complejidad. Esta evaluación será llevada a cabo por
el Equipo Scrum y un valor de story point será asignado. Una vez que la evaluación de una Historia
de Usuario del Product Backlog Priorizada es efectuada, el Equipo Scrum puede evaluar las otras
Historias de Usuario de forma relativa considerando la primera historia.
Por ejemplo, una funcionalidad que tiene asignada 2 story point debe tener el doble de dificultad
que una funcionalidad que tiene asignada 1 story point; una que tenga 3 story point debe tener el
triple de dificultad que una con 1 story point.
© 2019 SCRUMstudy.com 45
Proceso 3: Comprometer Historias de Usuarios
Commit User Stories
© 2019 SCRUMstudy.com 46
Proceso 4: Identificar Tareas
Identify Tasks
En las fases iniciales donde se ponen por escrito los requerimientos, la mayoría de las Historias de
Usuario recaban información de funcionalidades de alto nivel, por lo que éstas tienen que ser
desglosadas en tareas realizables y simples.
En las reuniones de planificación del sprint, el Equipo Scrum se reúne para planear el trabajo a realizar
en sprint. El equipo revisa cada historia de usuario comprometida para el sprint e identifica actividades
accionables o las tareas necesarias para implementar los entregables necesarios para cumplir
totalmente y cumplir los criterios de aceptación de usuarios de usuario. El Product Owner se encuentra
presente durante esta reunión en caso de que se necesita una aclaración relacionada a las historias
de usuario comprometidas a fin de ayudar al equipo a tomar decisiones sobre diseño.
Determinación de dependencia
Una vez que el Equipo Scrum ha seleccionado las historias de usuario para un determinado sprint,
deben considerar las dependencias, incluyendo aquellas relacionadas a la disponibilidad de personal,
así como cualquier dependencia técnica. Documentar adecuadamente las dependencias ayuda a los
equipos Scrum a determinar el orden relativo en el cual deben ejecutarse las tareas para crear los
entregables del sprint.
Las dependencias destacan también la relación e interacción entre las tareas dentro del Equipo Scrum
que trabaja en un determinado Sprint y con otros equipos Scrum en el proyecto.
Existen numerosos tipos de dependencias: obligatorias y discrecionales; internas y externas, o alguna
combinación de estas. Por ejemplo, una dependencia puede ser tanto obligatoria como externa.
• Dependencias obligatorias—Dependencias que son inherentes en la naturaleza del trabajo (como
una limitación física) o pueden darse debido a obligaciones contractuales o por requerimientos legales.
Por ejemplo, el trabajo en el primer piso no puede iniciar hasta que se hayan terminado los cimientos
del edificio. A las dependencias obligatorias también se les llama comúnmente como “lógica dura” (hard
logic).
• Dependencias discrecionales—Las dependencias discrecionales son aquellas que se colocan en
el flujo de trabajo por decisión propia. Normalmente, el Equipo Scrum determina cuáles son las
© 2019 SCRUMstudy.com 47
dependencias discrecionales con base en experiencias anteriores o las mejores prácticas en un campo
o dominio específico. Por ejemplo, el equipo puede optar por completar una tarea antes de trabajar en
otra ya que sería una mejor práctica, aunque no obligatoria. Por ejemplo, el equipo pudiera optar por
construir marcos de puertas y ventanas antes de toda la pared esté en pie.
• Dependencias externas—Las dependencias externas son aquellas que están relacionadas a las
tareas, actividades o productos fuera del alcance del trabajo a realizar por el Equipo Scrum, pero que
son necesarias para concluir una tarea del proyecto o crear un entregable del proyecto. Las
dependencias externas generalmente están fuera del alcance del Equipo Scrum. Por ejemplo, si el
Equipo Scrum no está a cargo de la adquisición de los materiales necesarios para la construcción de
paredes, entonces dichos materiales y las tareas relacionadas a su adquisición se considerarían
dependencias externas.
• Dependencias internas—Las dependencias internas son aquellas entre las tareas, productos o
actividades que están bajo el control del Equipo Scrum y dentro de un enfoque de trabajo a ser
ejecutado por dicho equipo. Por ejemplo, la instalación de paneles de yeso debe ser completada antes
de pintar la pared. Este es un ejemplo de una dependencia interna ya que ambas tareas son parte del
proyecto. En este caso, también es obligatorio, ya que se basa en una limitación física.No es posible
pintar la pared antes qué la pared esté seca.
Lista de tareas*
Es una lista integral que contiene todas las tareas a las que se ha comprometido el Equipo Scrum en
el actual sprint. Contiene descripciones de cada tarea, así como las estimaciones obtenidas durante el
proceso de Identificar tareas. La lista de tareas, o Task List, debe incluir cualquier prueba o actividad
de integración a fin de que el incremento del producto del sprint puede integrarse con éxito en los
entregables de previos sprints.
Aun cuando las tareas generalmente se basan en tareas, el nivel de granularidad al que se segmentan
las tareas lo decide el Equipo Scrum.
Como parte de las reuniones de planificación del sprint, el Equipo Scrum estima el esfuerzo necesario
para completar una tarea o serie de tareas y estimar el esfuerzo en cuestión de personal y recursos
necesario para llevar a cabo las tareas en un determinado sprint. Los miembros del Equipo Scrum
© 2019 SCRUMstudy.com 48
utilizan la lista de tareas para estimar la duración y el esfuerzo para las historias de usuario que serán
completadas en el sprint.
Uno de los beneficios clave de esta técnica es que permite al equipo contar con una perspectiva
compartida de las historias de usuario y los requerimientos de forma que pueda estimar de forma viable
el esfuerzo requerido.
Criterios de estimación
Los criterios de estimación pueden expresarse de muchas formas. Dos ejemplos comunes son los
puntos de historia y el tiempo ideal. Los valores de puntos de historia se utilizan para representar el
esfuerzo relativo o comparativo para completar tareas. Mientras que el tiempo ideal normalmente
describe el número de horas que los miembros de un Equipo Scrum trabajan exclusivamente en el
desarrollo de los entregables del proyecto sin incluir ningún tiempo dedicado a otras actividades o a
trabajo ajeno al proyecto. Los criterios de estimación le facilitan al Equipo Scrum estimar el esfuerzo y
le permiten evaluar y atender las ineficiencias cuando es necesario.
Effort Estimated Task Last*
La llama Effort Estimated Task List (lista de tareas del esfuerzo estimado) es una lista de tareas
asociadas con las historias de usuario incluidas en un sprint. Típicamente la precisión de las
estimaciones varía dependiendo de las habilidades del equipo El esfuerzo estimado se expresa en
términos de los criterios de estimación acordados por el equipo. El Equipo Scrum utiliza la Effort
Estimated Task List durante las reuniones de planificación del sprint a fin de crear el Sprint Backlog y
el Sprint Burndown Chart. Se utiliza también para determinar cuándo el equipo necesita reducir su
compromiso o asumir historias de usuario adicionales durante la planificación del sprint.
Lista de tareas actualizada*
La lista de tareas, desarrollada como parte del proceso de Identificar tareas, incluyendo las
estimaciones iniciales de historias de usuario que deben revisarse con base en actividades de
estimación más detalladas llevadas a cabo en el proceso de Estimar tareas. También pueden ser re-
estimaciones que resulten después de revisar los primeros sprints o cambiar el entendimiento colectivo
del Equipo Scrum sobre los requerimientos de las historias de usuario.
© 2019 SCRUMstudy.com 49
Parámetros de seguimiento del sprint
Los parámetros que se utilizan en los proyectos Scrum incluyen: velocidad, valor empresarial
entregado y cantidad de historias.
Valor empresarial entregado: Mide el valor de las historias de usuario entregadas desde la
perspectiva del negocio.
Número de historias: Describe cuántas historias de usuario se entregan como parte de un solo
sprint. Se puede expresar en términos de un simple conteo o de un conteo ponderado.
Es importante monitorear el progreso del Sprint y conocer el avance del Equipo Scrum midiendo
las tareas completadas del Sprint Backlog. Una de las herramientas de seguimiento es el
Scrumboard, conocido como Tablero de tareas y Cuadro de Avance.
Un Scrumboard estándar contiene 4 columnas que indican el progreso de las treas estimadas
para el Sprint: la columna “Pendiente” (“To Do”) para las tareas que aún no empiezan, la columna
“En Progreso” (“In Progress”) para tareas que empezaron pero no han sido completadas aún, la
columna “En Pruebas” (“Testing”) para tareas que han sido completadas pero se encuentran en
el proceso de ser probadas y la columna “Terminado” (“Done”) para tareas terminadas y probadas
exitosamente. Una columna opcional es la quinta: “Stories”. Al inicio del Sprint, todas las tareas
se colocan en la columna “To Do” y se van moviendo a las columnas siguientes de acuerdo al
avance.
© 2019 SCRUMstudy.com 50
La siguiente figura muestra un ejemplo de un Scrumboard:
Las principales salidas de este son el Sprint Backlog y el Gráfico Sprint Burndown.
1. Sprint Backlog (Lista de Pendientes del Sprint) – Es la lista de las tareas a ser ejecutadas por
el Equipo Scrum en el próximo Sprint. Es una práctica común que el Sprint Backlog se muestre en
un Scrumboard o tablero de tareas, este proporciona una representación visible y constante de la
situación de las Historias de Usuarios en el backlog. También se incluyen en el Sprint Backlog
algunos Riesgos asociados con las diversas tareas. Las actividades de mitigación a los riesgos
identificados podrían ser incluidas como tareas en el Sprint Backlog.
Una vez que el Sprint Backlog se haya finalizado y el Equipo Scrum se haya comprometido al
mismo, no deben añadirse nuevas Historias de Usuarios; sin embargo, puede ser necesario añadir
las tareas que pueden haberse pasado por alto o ignorado. Si surgen nuevas necesidades durante
un Sprint, se añadirán al Product Backlog Priorizado y se incluirán en un Sprint posterior.
2. Sprint Burndown Chart – Es un gráfico que muestra la cantidad de trabajo que queda por hacer
en el Sprint actual. El Gráfico Sprint Burndown inicial es acompañado por un Burndown planeado.
El Gráfico Sprint Burndown debe actualizarse al final de cada día laborable.
La siguiente figura muestra un ejemplo del Sprint Burndown Chart:
© 2019 SCRUMstudy.com 51
Este gráfico muestra el trabajo estimado pendiente (en el eje Y) y el tiempo (en el eje X).
Al final del día, los miembros del Equipo Scrum actualizan el gráfico con el trabajo
completado.
El gráfico Sprint Burndown es un buen indicador de la velocidad del equipo en el Sprint actual
y permite hacer pronósticos para saber si el equipo podrá completar o no todas las Historias
de Usuario comprometidas.
© 2019 SCRUMstudy.com 52
FASE: IMPLEMENTAR
La fase de Implementar abarca las ejecución de las tareas y actividades para crear el producto, servicio
o resultado del proyecto. Estas actividades incluyen la creación de varios entregables, llevar a cabo la
Reunión diaria y el mantenimiento del Product Backlog (es decir revisar, ajustar y actualizar
periodicamente).
El esfuerzo principal de desarrollo recae en el Equipo Scrum, y como este es auto-organizado y multi-
funcional, la decisión de cómo desarrollar algunas tareas recae en los miembros del Equipo Scrum. Ni
los interesados, ni el Scrum Master, tampoco el Product Owner puede dirigir al equipo en la forma de
desarrollar los entregables. Los miembros del Equipo Scrum son expertos en sus dominios, y su juicio
y experiencia son aplicadas a todos los aspectos técnicos y de gestión del proyecto durante este
proceso.
La salida más importante de este proceso es el entregable del Sprint, también conocido como el
incremento del producto, el cual satisface todas las características y funcionalidades definidas en las
Historias de Usuario del Sprint. Si los miembros del Equipo Scrum enfrentan cualquier obstáculo
mientras completan los entregables del Sprint, ellos los registran en el Impediment Log. Un Impediment
Log es mantenido por el Scrum Master, y es su responsabilidad resolver los problemas y eliminar los
impedimentos.
Cuando el Product Owner quiere hacer cambios en medio del Sprint, el alcance del Sprint en curso no
es modificado. Si el cambio que se requiere es tan importante que el resultado del Sprint en curso
podría ser inútil sin hacer estas modificaciones, entonces el actual Sprint debería ser terminado, y un
nuevo Sprint que incorpora el cambio debe ser iniciado. Caso contrario, el cambio será incluido en un
Sprint posterior.
Impediment Log*
© 2019 SCRUMstudy.com 53
Un impedimento es cualquier obstáculo o barrera que reduce la productividad del Equipo Scrum. Los
impedimentos deben identificarse, resolverse y eliminarse si el equipo sigue trabajando eficazmente.
Los impedimentos pueden ser internos en un equipo, tales como un flujo de trabajo ineficiente o la falta
de comunicación, o bien, pudieran ser externos. Algunos ejemplos de impedimentos externos pudieran
ser problemas relacionados a licencias de software o requisitos de documentación innecesaria. El
framework de Scrum, con su transparencia inherente, facilita la rápida y fácil identificación de
impedimentos. Si no se identifican o se atienden los impedimentos, pudiera ser muy costoso. El Scrum
Master debe registrar formalmente los impedimentos en un Impediment Log y se pueden analizar
durante las Daily Standups y en las reuniones de revisión del sprint según sea necesario.
1. Refactorización (Refactoring)
La refactorización es una herramienta específica para proyectos de software. El objetivo de esta técnica
es mejorar el mantenimiento del código existente y hacerlo más sencillo, más conciso y más flexible.
Refactorizar significa mejorar el diseño del código actual sin cambiar el comportamiento del mismo.
Implica lo siguiente:
• Eliminación de código repetitivo y redundante
• Separar los métodos y las funciones en rutinas más pequeñas
• Definir claramente las variables y los nombres de los métodos
• Simplificar el diseño del código
• Hacer que el código sea más fácil de entender y de modificar
La refactorización constante optimiza el diseño del código poco a poco durante cierto periodo. Enúltima
instancia, la refactorización da como resultado en un código más limpio y más fácil de mantener,
preservando a la vez todas las funcionalidades.
2. Patrones de diseño
Los patrones de diseño proporcionan una manera formal de registrar una resolución a un problema de
diseño en un campo específico de especialización. Dichos patrones registran tanto el proceso que se
utiliza como la resolución, misma que puede reutilizarse después para mejorar la tomar de decisiones
y la productividad.
© 2019 SCRUMstudy.com 54
La colaboración se promueve en el Equipo Scrum a través de la Reuniones Diarias (Daily Standup
Meetings). Esta es una reunión diaria de corta duración, generalmente 15 minutos como máximo. En
esta los miembros del Equipo Scrum informan su estado y sus planes para las siguientes 24 horas al
resto del equipo. Se revisa el trabajo completado desde la última Reunión Diaria y se proyecta el trabajo
que debe ser hecho antes de la siguiente Reunión.
La duración de las reuniones es muy corta y se espera que todos los miembros del Equipo Scrum
asistan. Sin embargo, la reunión no se cancela o se retrasa si uno o más miembros no pueden asistir.
En estas reuniones cada miembro del Equipo Scrum responde a estas tres preguntas específicas:
¿Qué terminé ayer?
¿Qué voy a terminar hoy?
¿Qué impedimentos u obstáculos (si los hay) estoy enfrentando en la actualidad?
Aparte de la colaboración, las Reuniones Diarias promueven la transparencia entre los miembros del
Equipo Core Scrum. El Scrum Master ayuda a los miembros del equipo a resolver problemas e
impedimentos. El Scrum Master sólo es un facilitador, no dirige la reunión. El Daily Standup Meeting
solo es un foro de intercambio de información. Cualquier discusión sobre la resolución de un problema,
si es necesaria, se realiza después de la reunión diaria. El Scrum Master recolecta información de los
impedimentos que los miembros del Equipo Scrum están enfrentando al realizar los trabajos del Sprint
y los resuelve después de la reunión.
El tercer proceso en la fase de Implementar es el proceso Groom Prioritized Product Backlog. Para
asegurar que los elementos priorizados del Product Backlog estén refinados, es recomendable que
entre el 7% al 10% de cada Sprint sea destinado para refinar el backlog. El Product Owner es
responsable de refinar el Product Backlog Priorizado, lo que conlleva a añadir o cambiar algunos
elementos para satisfacer cambios de requerimientos y para detallar Historias de Usuario para el
siguiente Sprint.
Este proceso asegura que el Product Backlog Priorizado esté refinado bien antes del siguiente Sprint,
así el Equipo Scrum tendrá un grupo de historias bien analizadas y claramente definidas que permitirá
agilizar el desglose de tareas y el proceso de estimación. También permite que el desarrollo sea más
flexible porque se podrá incorporar requerimientos recientes técnicos y de negocio en el siguiente
Sprint. De acuerdo a la informacón del cliente, cambios externos del mercado y conocimiento ganado
del Sprint actual y de los anteriores, el Product Backlog Priorizado es repriorizado.
Scrum no considera que este tipo de reuniones tenga una restricción de tiempo (timebox). Este proceso
es una tarea permanente del Product Owner.
© 2019 SCRUMstudy.com 55
FASE: REVISIÓN Y RETROSPECTIVA
La fase Revisión y Retrospectiva se ocupa de la revisión de los entregables y del trabajo que se ha
hecho, y determina las mejores prácticas y métodos utilizados para hacer el trabajo relacionado al
proyecto.
© 2019 SCRUMstudy.com 56
Proceso 2: Retrospectiva del Sprint
Retrospect Sprint
Luego de la Reunión de Revisión del Sprint (Sprint Review Meeting) el Equipo Scrum se reúne en la
Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting). Esta es una oportunidad para que el
Equipo Scrum se tome un momento para mirás hacia atrás y examinar el Sprint que acaba de terminar
para identificar mejoras potenciales en el proceso. Estas mejoras pueden resultar no solo en un simple
acuerdo entre miembros del equipo para hacer las cosas de otra forma, también puede definir
elementos no funcionales para el Product Backlog Prioritizado.
En la Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting) participan el Scrum Master y los
miembros del Equipo Scrum. El Product Owner podría asistir pero no es obligatoria su presencia.
Los miembros del equipo revisan qué se hizo bien y qué no en el Sprint que acaba de terminar.
Plantean los problemas que enfrentaron durante el Sprint y discuten cómo se podrían direccionar estos
temas. El Equipo identifica mejoras potenciales en la forma de trabajo y también sugiere mejoras en la
definición de Done basándose en su experiencia.
© 2019 SCRUMstudy.com 57
Para llevar a cabo una reunión efectiva de Retrospectiva, el evento puede tener estos 5 pasos:
Set the Stage (Preparar el ambiente): Se le da la bienvenida al equipo, se establece un
consenso sobre el propósito de la reunión y se evalúa la predisposición de los asistentes
para participar activamente.
Gather data (Obtener información): El equipo comparte información sobre el Sprint que
acaba de terminar y discuten sobre las fortalezas y debilidades. Este estado permite que
los participantes se enteren sobre las cosas más importantes que sucedieron en el Sprint.
Generate insight (Generar ideas): Este paso está enfocado en la pregunta “Por qué”?
(¿por qué algunas cosas funcionaron bien y por qué otras necesitan cambiar?) Este ayuda
a los participantes a tener perspectiva y a saber la causa raíz de los problemas.
Action (Acción): El equipo descubre la solución para mejorar el trabajo que se viene
haciendo y para reducir o prevenir errores.
Circle of questions and Closing (Círculo de preguntas y Cierre): Cada miembro del equipo
tiene la oportunidad de preguntar o compartir sus preocupaciones. En esta etapa se
clarifican las acciones que se realizarán en el siguiente Sprint. Finalmente, los miembros
del equipo se agradecen entre si y se cierra la reunión.
La información, opiniones, discusiones y los puntos acordados que son expuestos en la Reunión
de Retrospectiva del Sprint (Retrospect Sprint Meeting) son registradas en el Retrospect Sprint Log.
Explorador—Comprador—Vacacionista—Prisionero (ECVP)
Es un ejercicio que se puede llevar a cabo al inicio de la reunión de retrospectiva del sprint para
entender la mentalidad de los participantes y establecer el tono de la reunión. Se les pide a los
asistentes que indiquen de forma anónima lo que mejor representa su punto de vista en la reunión.
• Explorador (Explorer)—Quiere participar y aprender todo lo que se discutió en la retrospectiva
• Comprador (Shopper)—Quiere escuchar todo y elegir lo que entiende de la retrospectiva
• Vacacionista (Vacationer)—Quiere relajarse y ser turista en la retrospectiva
© 2019 SCRUMstudy.com 58
• Prisionero (Prisoner)—Quiere estar en otro lugar y asiste a la retrospectiva por ser obligatorio
El Scrum Master reúne las respuestas; prepara y comparte la información con el grupo.
Speed Boat
El Speed Boat es una técnica que se puede utilizar para llevar a cabo la reunión de retrospectiva
del sprint. Los miembros juegan el rol de la tripulación en una lancha. La lancha debe llegar a una
isla: simbólicamente la visión del proyecto. Los asistentes utilizan notas adhesivas para llevar un
registro de motores y anclas.
Los “motores” ayudan a llegar a la isla, mientras que las “anclas” son cosas que están
obstaculizando la llegada. Este ejercicio tiene un time-box de unos cuantos minutos. Una vez que
se documentan todos los elementos, se reúne la información, se discute y se prioriza por medio
de un proceso de votación. Se reconocen los motores y se planifican las acciones de mitigación
para las anclas dependiendo de la prioridad.
© 2019 SCRUMstudy.com 59
FASE: LANZAMIENTO
La fase de lanzamiento (release) destaca la entrega de los Entregables Aceptados al Cliente y la
identificación, documentación e internalización de las lecciones aprendidas del proyecto.
Ship Deliverables
Después que el Product Owner valida los entregables del Sprint basándose en los Criterios de
Aceptación y de Terminado, los Entregables Aceptados están listos para la entrega o lanzamiento a
los Interesados. Sin embargo, no todos los Sprints terminan en un lanzamiento. La decisión de cuándo
la entrega es un incremento de producto potencialmente comercializable para los interesados es hecha
en el proceso Conduct Release Planning.
El Cronograma de Planificación de Versiones (Release Planning Schedule) documenta qué
entregables serán liberados y cuándo. De este modo, las entradas principales para este proceso son
los Entregables Aceptados y el Cronograma de Planificación de Versiones.
Los entregables son lanzados utilizando los Métodos de Despliegue de la Organización. Cada
organización tiene sus propios Métodos de Despliegue. Estos guían cómo y cuándo los entregables
serán liberados a los interesados. Las principales salidas de este proceso son los Entregables
Trabajados, Acuerdos de Entregables Trabajados y Lanzamientos de Producto.
© 2019 SCRUMstudy.com 60
Proceso 2: Retrospectiva del Proyecto
Retrospect Project
El último proceso del flujo Scrum es la Retrospectiva del Proyecto, la cual es similiar al proceso
Retrospectiva del Sprint, pero a nivel de proyecto. Después que todos los incrementos de producto son
entregados exitosamente a los interesados, el Equipo Core Scrum o los equipos revisan, analizan e
identifican qué se hizo bien y que no durante el ciclo del proyecto.
La reunión de Retrospectiva del Proyecto (Retrospect Project Meeting) tiene el objetivo de identificar
las mejores prácticas y recomendaciones para el Cuerpo de Asesoramiento Scrum (Scrum Guidance
Body). No solo ayuda a mejorar la colaboración y eficiencia del equipo, también identifica mejoras para
toda la implementación Scrum. Las sugerencias, opiniones y conocimientos obtenidos en la reunión
de Retrospectiva del Proyecto son registrados para referencias futuras.
© 2019 SCRUMstudy.com 61
Capítulo Flujo Scrum - Preguntas
1. El conjunto de prioridades de trabajo a realizar se conoce como
A. Una historia de usuario.
B. La Cartera priorizada del producto.
C. Un gráfico Burndown.
D. Aceptado entregables.
6. ¿Cuál de los siguientes NO es una entrada para el proceso de Envío de Entregables (Ship
Deliverables)?
A. Entregables Aceptados
B. Crnonograma de Planificación de Entregas
C. Product Owner
D. Impediment Log
© 2019 SCRUMstudy.com 62
8. ¿Cuál de las siguientes herramientas es utilizada por el Equipo Scrum para estimar en el
proceso de Estimación de Tareas?
A. Experiencia en la escritura de Historias de Usuario
B. Wideband Delphi
C. Comparativo por Pares
D. Sesiones JAD
A. Velocidad del equipo es una medida de la cantidad de trabajo que un equipo puede
completar en un Sprint.
B. Velocidad histórica del equipo que se utiliza como un indicador en la asignación de tareas
para cada Sprint.
C. La velocidad del equipo es independiente de la composición del equipo.
D. La velocidad del equipo se utiliza en la decisión de los plazos de entrega.
10. ¿Cuál de los siguientes no es discutido en una reunión Standup diaria (Daily Standup
Meeting)?
A. Lo que el miembro del equipo ha avanzado desde la última reunión
B. Lo que el miembro del equipo tiene previsto trabajar hasta la próxima reunión
C. Lo que el miembro del equipo ha aprendido al completar su trabajo
D. Las barreras que el miembro del equipo enfrenta
11. ¿Cuál es la duración normal de una reunión Standup diaria (Daily Standup Meeting)?
A. 5 minutos
B. 1 hora
C. 15 minutos
D. Reuniones de stands-up no tienen límite de tiempo.
12. Asegurar que las reuniones diarias de Standup se ejecutan de manera oportuna y
estructurada es la responsabilidad de
A. Scrum Master
B. Product Owner
C. Scrum Team Leader
D. Del grupo a nivel colectivo
13. El Sprint Burndown Chart es una herramienta utilizada por los equipos para
A. Medir el trabajo completado durante un Sprint.
B. Medir el trabajo que queda por realizar durante un Sprint.
C. Calcular el remanente del presupuesto del equipo.
D. Identificar los miembros de bajo rendimiento del equipo.
14. La reunión en la que el equipo discute las tareas a realizar en el próximo Sprint es conocido
como la:
A. Reunión de Visión de Producto (Product Vision Meeting).
B. Reunión de Planificación del Sprint (Sprint Planning Meeting).
C. Reunión de Revisión de Sprint (Sprint Review Meeting).
D. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting).
© 2019 SCRUMstudy.com 63
15. La reunión al final del Sprint en el que el equipo presenta su trabajo al Product Owner es
conocido como la:
A. Reunión de Visión de Producto (Product Vision Meeting).
B. Reunión de Planificación del Sprint (Sprint Planning Meeting).
C. Reunión de Revisión de Sprint (Sprint Review Meeting).
D. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting).
16. La reunión en la que el equipo analiza el Sprint anterior e identifica mejoras potenciales
en los procesos se conoce como la:
A. Reunión de Visión de Producto (Product Vision Meeting).
B. Reunión de Planificación del Sprint (Sprint Planning Meeting).
C. Reunión de Revisión de Sprint (Sprint Review Meeting).
D. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting).
18. ¿Cuál de las siguientes actividades NO es parte de la Reunión de Retrospectiva del Sprint
(Retrospect Sprint Meeting)?
A. El equipo discute los aspectos positivos y negativos del Sprint anterior.
B. El equipo identifica los problemas que enfrentaron en el Sprint anterior y discute cómo
mitigar estos temas en Sprints futuros.
C. El equipo revisa e identifica posibles mejoras en su trabajo.
D. Sobre la base de los cambios propuestos, el equipo procede a cambiar la prioridad de la
Pila de Producto priorizada (Prioritized Product Backlog).
19. La ventaja del proceso Grooming the Prioritized Product Backlog (Mantenimiento de los
Pendientes Priorizados del Producto) es la siguiente:
A. El conocimiento ganado a partir de un Sprint anterior se incorpora en Sprints futuros.
B. Los últimos requisitos técnicos y de negocio se agregan al siguiente Sprint.
C. El mantenimiento del Product Backlog priorizado asegura tenerlo refinado antes de la
reunión de planificación de Sprint para que el equipo tiene una mejor idea de los requisitos
antes de la reunión.
D.Todas las anteriores.
21. ¿Cuál de las siguientes actividades se pueden realizar en conjunto durante la reunión de
planificación del Sprint (Sprint Planning Meeting)?
A. Estimación Tareas y Planificación de Entregas
B. Mantenimiento de la Pila de Producto y Planificación de Tareas
C. Planificación de Tareas y Tareas de Estimación
D. Planificación de Entregas y Mantenimiento de la Pila de Producto
© 2019 SCRUMstudy.com 64
22. ¿Cuál de las siguientes no es parte de la reunión de planificación de Sprint?
A. El Product Owner, explica los principales elementos de la Pila de Producto priorizada para
el equipo.
B. El Equipo Scrum, en colaboración con el Product Owner, estima las tareas de un Sprint
dado.
C. Sobre la base de las estimaciones, el equipo se compromete en algunas tareas que deben
completarse en el próximo Sprint.
D. El equipo recibe la retroalimentación de las partes interesadas.
23. Usted es miembro de un equipo Scrum y se le indica que el gerente general de la empresa
ha solicitado que se desarrolle una tarea urgente que no forma parte del Sprint actual.
¿Qué debe hacer?
A. Hacerse responsable de la tarea, y hablar con el Product Owner para ampliar el plazo del
Sprint actual.
B. Hablar con el Scrum Master para volver a asignar las tareas a otra persona.
C. Hablar con el Product Owner para volver a a asignar las tareas a otra persona.
D. Informar al Scrum Master de la situación para que revise la situación con el gerente
general.
E. No realizar ninguna acción porque ya está ocupado.
24. Para cualquier Sprint en curso, ¿cuándo se pueden agregar nuevas historias de usuarios?
A. Cuando el Scrum Master agrega la historia de usuario a la Pila de Sprint (Sprint Backlog)
B. Cuando el Product Owner (propietario del producto) aprueba la historia de usuario
C. Cuando el equipo Scrum aprueba la historia de usuario
D. Nuevas historias de los usuarios nunca pueden ser añadidas al Sprint
26. ¿En cuál de los siguientes procesos de la fase Iniciar se determina la duración del Sprint?
A. Crear Visión del Proyecto
B. Desarrollar Epics
C. Crear la Pila de Producto Priorizada
D. Realizar la Planificación de las Entregas (Conduct Release Planning)
© 2019 SCRUMstudy.com 65
ESCALANDO SCRUM
Escalabilidad de Scrum
Para ser eficaz, los Equipo Scrums deben tener idealmente de seis a diez miembros. Esta práctica
podría llevar a la idea errónea de que el método de Scrum sólo se puede utilizar para proyectos
pequeños. Sin embargo, se puede escalar fácilmente para el uso eficaz en proyectos grandes. En
situaciones donde el tamaño del Equipo Scrum excede los diez miembros, múltiples Equipo Scrums
se pueden formar para trabajar en el proyecto. El proceso Convocar Scrum of Scrum facilita la
coordinación entre los Equipo Scrums lo que permite una aplicación efectiva en los proyectos grandes.
Los proyectos grandes o complejos a menudo se implementan como parte de un Programa o Portafolio.
El método de Scrum también se puede aplicar para gestionar Programas y Portafolios. El enfoque
lógico de las directrices y los principios de este marco pueden utilizarse para gestionar proyectos de
cualquier tamaño, que abarcan distintas geografías y organizaciones. Los proyectos grandes pueden
tener varios Equipos Scrums trabajando de forma paralela por lo que es necesario sincronizarse y
facilitar el flujo de información y mejorar la comunicación.
El proceso Convocar Scrum de Scrum asegura esta sincronización. Los diversos Equipos Scrums
están representados en esta reunión y el objetivo es proporcionar actualizaciones sobre el progreso,
discutir los retos que enfrentan durante el proyecto y coordinar las actividades. No hay reglas fijas en
cuanto a la frecuencia de estas reuniones. Los factores que determinan la frecuencia son el nivel de
dependencia entre los equipos, el tamaño del proyecto, el nivel de complejidad y las recomendaciones
del Cuerpo de Asesoramiento de Scrum.
Programas
En los Programas, los roles principales para la gestión de Scrum son:
1. Product Owner del Programa — Define los objetivos y las prioridades estratégicas para el Programa.
2. Scrum Master del Programa — Resuelve problemas, remueve Impedimentos, facilita y lleva a cabo
reuniones para el Programa.
Estas funciones son similares a las del Product Owner y Scrum Master excepto que satisfacen las
necesidades del Programa o unidad de negocio en lugar de las de un sólo Equipo Scrum.
Portafolios
En Portafolios, los roles importantes para la gestión de Scrum son:
1. Product Owner del Portafolio —Define los objetivos estratégicos y las prioridades del Portafolio.
2. Scrum Master del Portafolio —Resuelve problemas, elimina Impedimentos, facilita y lleva a cabo
reuniones para el Portafolio.
© 2019 SCRUMstudy.com 66
La siguiente figura ilustra cómo el método Scrum se puede utilizar en toda la organización para los
Portafolio, Programa o Proyectos.
Los problemas que se enfrentan al utilizar Scrum dentro de un Programa o Portafolio implican
principalmente la coordinación entre los numerosos equipos. Esto puede conducir al fracaso si no
se gestiona con cuidado. Las herramientas utilizadas para la comunicación deben ser escaladas
para que coincida con los requisitos de los equipos que participan en un Programa o un Portafolio.
Cada Equipo Scrum debe atender no sólo la comunicación interna, sino también la comunicación
externa con otros equipos y los interesados del Programa o Portafolio.
© 2019 SCRUMstudy.com 67
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
grandes . Por lo general, hay un representante en la reunión de cada uno de los Equipo Scrums. Por
lo general el representante es el Scrum Master, pero también puede asistir cualquier miembro del
Equipo Scrum si es necesario. Esta reunión es usualmente facilitada por el Jefe Scrum Master y su
objetivo es centrarse en las áreas de coordinación e integración entre los diferentes Equipo Scrums.
Tal reunión se lleva a cabo en intervalos predeterminados o cuando lo requieran los Equipo Scrums.
En organizaciones donde hay varios Equipo Scrums trabajando en varias partes de un proyecto de
forma simultánea, SoS se puede escalar a otro nivel, esta se conoce como Scrum of Scrum of Scrums
Meeting. En esta situación, una Reunión SoS mantiene la coordinación de cada grupo de los Equipo
Scrums.
Transición a Scrum
Los dos métodos básicos para hacer la transición a Scrum son de arriba a abajo y de abajo a arriba.
En el método de arriba hacia abajo, la transición es comunicada en toda la organización. Existe un
esfuerzo por proveer capacitación del cambio a todos los involucrados. Esta comunicación puede ser
fuente de resistencia al cambio. La otra posibilidad es cambiar las cosas gradualmente dentro de la
cultura de la organización. Después, la transición a Scrum será de forma incremental.
Con una implementación de arriba hacia abajo, podrían haber conflictos de comunicación. Por ejemplo,
un líder de ingeniería implantó Scrum en su organización sin el consentimiento por parte del área de
ventas. Esto llevaría a grandes conflictos con el mismo Product Owner.
Otro aspecto a considerar de la transición es saber el impacto de la transición de la organización a los
métodos Scrum. Toda organización puede hacer la transición al mismo tiempo. Sin embargo, este
método es más susceptible a problemas que pueden resultar en la interrupción de actividades que
generan ganancias. Por lo tanto, es generalmente preferible hacer la transición en diferentes secciones
de forma iterativa para reducir el riesgo y proveer lecciones aprendidas para futuras iteraciones.
© 2019 SCRUMstudy.com 68
Mapeo de Roles tradicionales a Scrum
Los roles tradicionales de la gestión de proyecto son divididos en tres roles en Scrum : Product Owner
, Scrum Master y Scrum Team.
El Product Owner se comunica con los interesados y establece las prioridades del proyecto.
El Scrum Master ejecuta los deberes del jefe de proyecto porque remueve los impedimentos.
El Scrum Master, como el jefe de proyecto, es responsable de asegurar que los procesos
Scrum sean ejecutados adecuadamente.
Los miembros del Equipo también ejecutan algunos roles tradicionales del jefe de proyecto,
dado que ellos se autogestionan y son dueños de su tiempo. Esto permite que el equipo tenga
un sentido de pertenencia para que busque su propio éxito.
Evaluar continuamente los cambios del proyecto que afectan a los interesados para asegurar
que nuevos interesados del proyecto estén comprometidos.
Mantener una comunicación regular con los interesados.
Es importante que los ejecutivos que financian el proyecto tengan claridad respecto a los siguientes
temas:
© 2019 SCRUMstudy.com 69
Capítulo Escalando Scrum - Preguntas
© 2019 SCRUMstudy.com 70