SCRUM

1. 1
Guía del Curso
Gestión Ágil con Scrum

2. 2
Agilidad
En los últimos años ha existido una necesidad latente por parte de las empresas de ser más rentables, exitosas
y competir en un mundo cada vez más interconectado. En algunos modelos de gestión, el hecho de tener un
plan detallado de actividades para lograr resultados favorables fue aplicado en diversos ámbitos obteniendo
resultados medianamente favorables, sin embargo, con la aparición de nuevas tecnologías y escenarios cada
vez más complejos y competitivos, tener un nivel de detalle muy específico ya dejó de ser imprescindible,
puesto que se necesitan cada vez tiempos más cortos entre el nacimiento de la idea hasta su implementación.
En la gestión de proyectos de hoy día, existen dos tipos de paradigmas. El primero es el llamado Modelo
Predictivo Tradicional mientras que el segundo es denominado Modelo Ágil.
Modelo de Cascada
Es un modelo básico y sencillo que ha servido como bloque de construcción para los demás paradigmas de ciclo
de vida de desarrollo de software, se conoce también como modelo clásico, tradicional o secuencial lineal. Está
basado en el ciclo convencional de una ingeniería y su visión es muy simple ya que el desarrollo de software se
debe realizar siguiendo una secuencia de fases. Cada una de sus etapas tiene un conjunto de metas bien
definidas y las actividades dentro de cada una contribuyen a la satisfacción de metas de esa fase, se puede
decir que es un método que implica un desarrollo rígido donde la estructura de ese ciclo de vida abarca las
siguientes actividades:
En el modelo vemos una ventaja evidente y radica en su sencillez, ya que sigue los pasos intuitivos necesarios a
la hora de desarrollar el software. Pero el modelo se aplica en un contexto, así que debemos saber que:
 Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Siempre hay
iteraciones y se crean problemas en la aplicación del paradigma.
 Normalmente, al principio, es difícil para el cliente establecer todos los requisitos explícitamente. El
ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden
existir al comienzo de muchos productos.

3. 3
 El cliente debe tener paciencia hasta llegar a las etapas finales del proyecto ya que es allí donde estará
disponible una versión operativa del programa. Un error importante que no pueda ser detectado hasta
que el programa esté funcionando, puede ser muy costoso.
Modelo Ágil
Estos modelos surgen como reacción a la gestión tradicional, centrándose en el factor humano y a la entrega
de valor al cliente, permitiendo adaptar la forma de trabajo a las condiciones del proyecto, se busca a través de
ellos conseguir flexibilidad e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las
circunstancias del entorno. Las empresas que apuestan por estos modelos consiguen gestionar sus proyectos
de forma fluida, autónoma y eficaz reduciendo costos e incrementando su productividad.
Existen muchas razones de por qué usarlos y su importancia radica en que ayudan a mejorar la satisfacción del
cliente dado que él se involucra y compromete a lo largo de todo el proyecto. En cada etapa se informa de los
logros y progresos del mismo, con la visión de sumar su experiencia y conocimiento, optimizando las
características del producto final.
Otra de las ventajas es que mejora la motivación del equipo de desarrollo. Esta mejora no es casual, es decir las
metodologías ágiles permiten a todos los miembros del equipo conocer el estado del proyecto en cualquier
momento, a esto se le conoce como Transparencia, así, los compromisos son negociados y aceptados por todos
sus miembros. Cabe destacar que optar por la aplicación de una gestión ágil permite ahorrar tiempo y costos.
Se trabaja con mayor velocidad y eficiencia. Una de las características de su aplicación es que se realizan
entregas parciales del producto, de este modo, es posible entregar en el menor intervalo de tiempo una
versión mucho más funcional del producto permitiendo mejorarlo ya que la continua interacción entre los
desarrolladores y los clientes aseguran que el producto final sea exactamente lo que el cliente busca y necesita.
Es importante aclarar que el término de metodologías ágiles es usado con mucha frecuencia en el mundo del
agilismo para referirse a Marcos de Trabajo (Scrum), Metodologías (Kanban, XP, Scrumban), técnicas de

4. 4
desarrollo ágiles (TDD), técnicas para modelamiento de software (Agile Modeling) entre otros. La mayor parte
de estas metodologías se arropan sobre el pensamiento o filosofía Lean ideada por Toyota que se caracteriza
por enfocarse en el valor al cliente y en la disminución de desperdicios.
Las metodologías ágiles han llegado a convertirse en un pilar fundamental para poder generar una reacción
adecuada al mercado cambiante, validando constantemente las necesidades de los consumidores e
incorporándolas de forma temprana al roadmap de los distintos productos o servicios ofrecidos.
Es importante mencionar que no todas las organizaciones han sabido reaccionar oportunamente a este cambio
disruptivo, algunas por temas burocráticos, otras por una resistencia al cambio muy afianzada entre sus
miembros, y muchas de ellas simplemente por no contar con un acompañamiento adecuado al momento de
planificar y diseñar el cambio antes de dar el paso.
En Sybven, hemos impulsado el uso de las metodologías ágiles en todas las áreas, niveles y departamentos de
la empresa, aplicamos la trasformación digital a través de ellas como un excelente aliado y debido a esto nos
hemos convertido en una empresa en constaste cambio, con una productividad impecable.

5. 5
Manifiesto Ágil
El 17 de febrero de 2001 diecisiete críticos de los modelos de mejora del desarrollo de software basados en
procesos, convocados por Kent Beck, quien había publicado un par de años antes Extreme Programming
Explained, libro en el que exponía una nueva metodología denominada Extreme Programming, se reunieron en
Snowbird, Utah para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el
término “Métodos Ágiles” para definir a los métodos que estaban surgiendo como alternativa a las
metodologías tradicionales a las que consideraban excesivamente pesadas y rígidas por su carácter normativo y
fuerte dependencia de planificaciones detalladas previas al desarrollo.
Los integrantes de la reunión resumieron los principios sobre los que se basan los métodos alternativos en
cuatro postulados, lo que ha quedado denominado como Manifiesto Ágil, donde se expone:
12 Principios del Manifiesto Ágil
Estos son los 12 principios del Manifiesto Ágil:
1. Satisfacer al cliente.
2. Aceptar los cambios de requerimientos.
3. Entregar software funcional frecuentemente.
4. Negocio y equipo de desarrollo trabajan juntos de forma cotidiana.
5. Desarrollar los proyectos en torno a individuos motivados.
6. Conversar cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Desarrollo sostenible.

6. 6
9. Atención continua a la excelencia técnica.
10. Simplicidad.
11. Equipos auto-organizados.
12. Reflexionar y perfeccionar.
Scrum se basa en estos principios. Se trata de un marco de trabajo para gestionar el desarrollo de software
basado en el proceso iterativo e incremental que se utiliza de manera común en entornos basados en el
desarrollo ágil de software.
En el siguiente enlace podrás ver de forma más amplia los principios que fueron generados por los creadores
del Manifiesto Ágil.
http://agilemanifesto.org/iso/es/principles.html
Cultura Scrum
Los orígenes de Scrum se remontan desde la década de los 80, japoneses y americanos dieron significativos
aportes así como comunidades ágiles para hacer de Scrum lo que es hoy, la industria del desarrollo de software
ha servido de escenario para implementarlo, sin embargo se ha logrado adaptar y aplicar en otras áreas que no
son necesariamente de tecnología.
Dentro de los principios ágiles, se vive en un mundo de constante cambio e incertidumbre por lo que es
imposible predecir a futuro lo que pueda ocurrir. Scrum se basa en la teoría empírica afirmando que el
conocimiento proviene de la experiencia y la toma de decisiones se basa en lo que se conoce. La
implementación de ese proceso empírico se sostiene sobre pilares y para que Scrum tenga éxito las personas
que lo aplican deben creer en valores y ponerlos en práctica.
Historia de Scrum
1986 - Primeras investigaciones
El modelo de Scrum fue identificado y definido por los japoneses Ikujiro Nonaka e Hirotaka Takeuchi en 1986,
al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica de
Japón y los Estados Unidos tal es el caso de: Fuji - Xerox, Canon, Honda, Nec, Epson, Brother, 3M, Hewlett
Packarp.
1986 - Rugby
Nonaka y Takeuchi en su análisis compararon la nueva forma de trabajo en equipo que estaban identificando
en las empresas de tecnología, con el avance en formación de una jugada del juego de Rugby llamada scrum.
Describieron un enfoque innovador para el desarrollo de productos al que llamaron enfoque holístico o
"rugby", donde un equipo en ese deporte intenta llegar hasta el final como una unidad, pasando el balón de
adelante hacia atrás.

7. 7
1986 - Trabajo en equipo
Los japoneses basaron su enfoque en los estudios de casos de diversas industrias de fabricación como ya se ha
mencionado. Takeuchi y Nonaka propusieron que el desarrollo de productos no debe ser como una carrera de
relevos secuencial, sino que debería ser análogo al del juego de rugby, en el que el equipo trabaja en conjunto
para lograr un objetivo.
1995 - Ken Schwaber
Ken presentó una metodología de desarrollo de software, basada en un ambiente scrum y usó ese mismo
término para definir el proceso, consistía en un marco de reglas para desarrollo de software, basado en esos
principios, y que él había empleado en el desarrollo de un lenguaje de programación orientada a objetos
llamado Delphi.
1995 - Jeff Shutherland
Para ese año Jeff Sutherland utilizaba el enfoque ágil mientras trabajaba en Easel Corporation empresa
dedicada al desarrollo de macrojuegos, Jeff venía incorporando la filosofía básica de scrum que habían definido
los japoneses en el desarrollo de estos productos, su forma de trabajo implicaba ciclos de treinta días para
planificar, construir y monitorear los sprints (iteraciones).
1995 - OOPSLA
En Austin, Texas, Ken Schwaber y Jeff Sutherland desarrollaron el concepto de Scrum y su aplicabilidad al
desarrollo de software durante una presentación en la Conferencia Internacional sobre Programación,
Lenguajes y Aplicaciones Orientadas a Objetos (OOPSLA). Esta presentación documentó principalmente el
aprendizaje que Ken y Jeff habían obtenido a lo largo de los años anteriores y se hizo pública la primera
definición formal de Scrum.
2001 - Manifiesto Ágil
En marzo de 2001, 17 profesionales del software, críticos de los modelos de producción basados en procesos,
fueron convocados por Kent Beck, que había publicado un par de años antes el libro en el que explicaba la
metodología Extreme Programming (XP). Se reunieron en Salt Lake City para discutir sobre los procesos
empleados por los equipos de programación, definiendo el Manifiesto Ágil, en dicha reunión estuvieron
presentes los creadores de Scrum quienes tuvieron la oportunidad de firmar dicho manifiesto.
2005 - ScrumAlliance
En 2005 Mike Cohn, Esther Derby y Ken Schwaber constituyeron la organización “Scrum Alliance” para difundir
un marco de trabajo específico para el desarrollo de software, basado en esta metodología y a la que también
denominaron Scrum. Esta asociación se covertiría en el ente rector de todo el conocimiento de Scrum. Scrum
Alliance era, hasta hace algunos años, la única entidad que podría certificar, hoy día sigue siendo el organismo
de certificación más grande de la comunidad ágil.

8. 8
2017 - Scrum el más utilizado
Desde entonces, varios practicantes, expertos y autores de Scrum han seguido perfeccionando la
conceptualización del marco de trabajo. En los últimos años, Scrum ha aumentado en popularidad, y hoy en día
es la metodología de desarrollo de proyectos predilecta de muchas organizaciones a nivel mundial.
Pilares de Scrum
Scrum se fundamenta en la teoría de control de procesos empírica o empirismo, es decir aprendemos de los
errores del pasado. Tres pilares son los que sostienen este marco de trabajo:
Transparencia
Todos los aspectos relativos del proceso deben ser visibles a los responsables del resultado.
Ser transparente implica dar visibilidad a todo lo que está pasando, las ceremonias de scrum y sus artefactos
ayudan a mostrar los logros, resultados, progreso e impedimentos que se puedan presentar. El proceso debe
ser entendible por todo el equipo y los involucrados acerca de lo que se va a construir.
Deja que vean lo qué haces, cómo lo haces y en qué fallas ya que es la única forma de mejorar.
Inspección
Scrum promueve la inspección frecuente de los artefactos y el progreso para identificar y corregir variaciones
indeseadas. La inspección ocurre durante los eventos o ceremonias de Scrum.
El producto, la metodología, las herramientas deben inspeccionarse con frecuencia para detectar
oportunidades o ideas que pueden agregar mayor valor a lo ya planificado para que el proceso o el producto
puedan ajustarse y así maximizar el valor de lo que se entregue.

9. 9
Adaptación
Después de la inspección, se deberían hacer ajustes al proceso, a los artefactos, al comportamiento de las
personas que integran los equipos y a la interacción con el entorno.
En ceremonias por ejemplo como la retrospectiva se toma el espacio donde formalmente se llevan a cabo las
mejoras a implementar durante las iteraciones.
Estos tres pilares, sólo funcionan si se hacen de forma conjunta. De nada sirve ser transparentes, si no
inspeccionamos nada. Tampoco sirve la inspección, si después se sigue haciendo lo mismo. Tampoco son útiles
los cambios si no los hacemos públicos y si no se indican los aspectos positivos y negativos que se logran
encontrar durante la ejecución de los Sprints.
Valores de Scrum
Apertura: actitud abierta y receptiva, aprender nuevas habilidades o adquirir nuevos conocimientos para
convertirse en multi-funcionales
Compromiso: hacer lo que dices que harás, cumplir con los acuerdos de trabajo, con la planificación y objetivos
propuestos.
Coraje: proponer cambios importantes en cómo se deben hacer las cosas, pedir ayuda cuando se necesite,
perder el miedo.
Foco: hacer una cosa a la vez para que de esta forma se consigan los objetivos trazados.
Respeto: dar y pedir feedback, separar la persona del rol, compañerismo, tener confianza en los demás.
Cuando los valores de Scrum son encarnados y vividos por el equipo Scrum, los tres Pilares cobran vida y
construyen confianza para todos.

10. 10
Marco de Trabajo Scrum
"Scrum es un marco de trabajo ágil para la realización de proyectos complejos. Scrum originalmente fue
formalizado para proyectos de desarrollo de software, pero funciona bien para cualquier ámbito complejo e
innovador de trabajo. Las posibilidades son infinitas. El marco de Scrum es engañosamente simple".
Roles de Scrum
Dueño del Producto
El Dueño del Producto o “Product Owner“ según establece la guía de Scrum “es el responsable de maximizar el
valor del producto resultante del trabajo del Equipo de Desarrollo”.
Para poder cumplir con la misión de maximizar el valor, el Dueño del Producto tiene que tener un
entendimiento claro y bien definido del producto a entregar como resultado del proyecto. El Dueño del
Producto puede ser o el representante de un cliente o de un comité, se encarga de recolectar todas las
necesidades y requisitos y plasmarlas con claridad en la Lista de Producto.
La Lista de Producto (Product Backlog) suele estar conformada por Historias de Usuarios, sin embargo,
dependiendo de la organización, es posible usar opciones más tradicionales como, por ejemplo, casos de uso.
El Dueño del Producto es la única persona responsable de gestionar la Lista de Producto, en este sentido, es
importante que sus decisiones sean respetadas por toda la organización, es decir, nadie puede anular sus
decisiones o pasar por encima de ellas, el Product Owner tiene la última palabra sobre que se desarrolla y que
no.
La forma en que el Dueño del Producto (Product Owner) gestiona la Lista de Producto puede variar
dependiendo de la organización, en términos generales una buena gestión implica:
1. Plasmar con claridad los elementos de la Lista de Producto, en forma de Historia de Usuario o cualquier
otra que acuerde la organización.

11. 11
2. Ordenar y priorizar los elementos del Product Backlog para generar el máximo valor.
3. Garantizar que el Product Backlog sea visible y transparente para todos.
4. Asegurarse que el Equipo de Desarrollo entienda los elementos de la Lista de Producto a cabalidad y
estar disponible, para el equipo, a lo largo de la ejecución, en caso de dudas.
5. Hacer refinamientos de la Lista de Producto siempre que se requiera, eliminando requerimientos
obsoletos, agregando nuevos o redefiniendo las prioridades.
Además de gestionar la Lista de Producto, el Product Owner se encarga, junto con el equipo, de establecer la
Definición de Terminado (Definition of Done-DofD) y la de Definición de Listo (Definition of Ready-DofR) de los
elementos de la Lista de Producto.
Dada la naturaleza de la responsabilidad que recae sobre el Dueño del Producto: toma de decisiones
estratégicas, alineación con los Stakeholder, establecimiento de prioridades, etc., se recomienda para este rol
una persona con perfil Senior que pueda llegar a ser un verdadero Product Owner y no solo un tomador de
requisitos.
Scrum Master
La principal función del Scrum Master es asegurar el entendimiento y seguimiento de Scrum tanto por el
Equipo Scrum como por los profesionales con los que este equipo se relaciona. Al mismo tiempo, es
considerado un Coach para el equipo ayudándolo a alcanzar el máximo nivel de productividad posible.
Se puede decir que el Scrum Master, es un coach, líder, facilitador, provocador, detective y soplador de brasas.
"Un socio facilitador del aprendizaje, que acompaña al otro en una búsqueda de su capacidad de aprender
para generar nuevas respuestas”
Leonardo Wolk, Coaching El arte de soplar brasas

12. 12
Se espera, además, que el Scrum Master acompañe al equipo de trabajo en su día a día y garantice que todos,
incluyendo al Product Owner, comprendan y utilicen Scrum de forma correcta. Las responsabilidades
principales del Scrum Master según sus creadores Jeff Sutherland y Ken Schwaber definidas en la Guía oficial de
Scrum junto con otras se mencionan a continuación:
Apoyar al Dueño del Producto (Product Owner) en:
1. Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el
equipo Scrum de la mejor manera posible
2. Encontrar técnicas para gestionar la Lista de Producto(Product Backlog) de manera efectiva
3. Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y
concisos
4. Entender la planificación del producto en un entorno empírico
5. Asegurar que el Dueño del Producto conozca cómo ordenar la Lista de Producto para maximizar el
valor
6. Entender y practicar la agilidad
7. Facilitar los eventos de Scrum según se requiera o necesite

13. 13
Sirve al Equipo de Desarrollo en:
1. Ayudar a ser autoorganizado y multifuncional
2. Ayudar a crear productos de alto valor y que cumplan con el objetivo trazado en un Sprint
3. Solucionar, eliminar y gestionar posibles impedimentos que puedan surgir en un Sprint que afecten el
progreso del trabajo ya sea que los relentice o les impida avanzar
4. Guía al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún no haya sido
adoptado y entendido por completo
5. Asegurar y promover buenas prácticas de desarrollo
6. Ayudar a que las posibles mejoras detectadas en la retrospectiva de un Sprint se lleven a cabo
Promueve en la Organización a:
1. Liderar y guiarla en la adopción de Scrum
2. Planificar las implementaciones de Scrum en la misma
3. Ayuda a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico del
producto
4. Motivar cambios que incrementen la productividad del Equipo Scrum
5. Trabajar junto con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la
organización
Además de los puntos mencionados, el Scrum Master debe detectar problemas y conflictos interpersonales
dentro del equipo de trabajo. Para respetar la filosofía auto-organizativa del equipo, lo ideal es que el equipo
mismo sea quien resuelva sus problemas. En el caso de no poder hacerlo, deberá involucrarse al Scrum Master
y eventualmente a niveles más altos de la gerencia.

14. 14
En la actualidad un Scrum Master es visto como un Facilitador o Coach, incluso muchas veces se le conoce así.
Su responsabilidad es asegurar que se cumpla con el proceso de Scrum sin interferir directamente en el
desarrollo del producto final. Es importante establecer que el equipo de Scrum elige la forma de trabajo que
más prefiera, siempre que se cumplan las pautas básicas de Scrum, por ello mientras lo hagan no existe una
forma “errónea” de trabajar.
El rol del Scrum Master también incluye asegurar que el desarrollo del producto tenga la mayor probabilidad
de ser completado de forma exitosa. Para lograr este cometido, trabaja de cerca con el Product Owner
asegurando una correcta priorización de los requerimientos y con el equipo de desarrollo para convertir estos
requerimientos en un producto funcionando.
“Scrum es fácil, hacer Scrum es difícil”. Esta afirmación tiene sus fundamentos en la idea de que una cosa es
aprender Scrum y otra muy diferente es aplicar Scrum de forma exitosa. Para un Scrum Master emprender este
camino significa adoptar una filosofía de liderazgo servil.
Cuando un Scrum Master logra cubrir éxitosamente su rol, la implementación del marco de trabajo se realiza
sin contratiempos. Las responsabilidades del Scrum Master deberían cubrir la totalidad de su tiempo. Si bien
hay casos en los que el Scrum Master cumple, además de sus funciones, el rol de desarrollador, se recomienda
que como parte del equipo de desarrollo su participación sea muy pequeña para que no pierda el foco de sus
actividades como Scrum Master y evitar el riesgo de que ambas responsabilidades excedan el límite de su
capacidad generando que se descuide uno de los dos roles asumidos.

15. 15
Equipo de Desarrollo
El tercer rol dentro de Scrum, es el Equipo de Desarrollo, el “Development team”.
Son todas las personas responsables de llevar a cabo la ejecución o desarrollo del producto y de entregar, al
término de cada Sprint, el incremento del producto “Terminado”, con terminado nos referimos a que
potencialmente ese incremento puede ir a producción al cierre del Sprint.
Aunque el Scrum Master y/o el Product Owner son partes del equipo de Scrum, no son considerados partes del
equipo de desarrollo, a menos que contribuyan con la lista de pendientes definida para el Sprint.
Ahora bien, qué características debería de tener el equipo de desarrollo.

16. 16
Una característica primordial es la autoorganización, queremos lograr un equipo empoderado y capaz de
organizar y gestionar el trabajo que realizan durante cada Sprint. Para que el equipo alcance el nivel de
madurez necesario para ser autoorganizado se requiere del apoyo de la organización y del Scrum Master. En
este contexto, se demanda un cambio de cultura, un cambio en la forma tradicional de hacer las cosas, se
requiere confianza para permitir que sea el equipo quien defina el cómo ejecutar los pendientes del Sprint.
Recordamos acá a Steve Jobs quien nos dice:
“No tiene sentido contratar a personas inteligentes para decirles lo que tienen que hacer; contratamos a
personas inteligentes para que nos digan lo que tenemos que hacer“
Steve Jobs
El equipo de desarrollo no necesita que nadie les diga cómo hacer lo que se requiere, ellos cuentan con las
competencias y habilidades necesarias, son un equipo multifuncional.
El perfil de cada uno de los integrantes del equipo de desarrollo de Scrum se caracteriza por ser tipo “T”, esto
es que aunque cada uno puede tener una especialización o área en la que poseen mayor conocimiento o foco
(la vertical de la “T”) tiene conocimientos generales sobre las restantes áreas (la horizontal de la “T”) por lo
que, la responsabilidad de cumplir con el objetivo del Sprint y entregar el incremento “terminado” recae en
todo el equipo, no existen ni “títulos” ni subequipos para diferenciar o identificar áreas, especializaciones o
tipo de trabajo a realizar.
Respecto al tamaño del equipo la guía de Scrum nos dice que “El tamaño óptimo del Equipo de Desarrollo es lo
suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para completar una
cantidad de trabajo significativa” qué quiere decir esto, que el tamaño del equipo va a depender del tipo y
complejidad del producto a desarrollar, recordemos que Scrum no solo aplica al desarrollo de software se
puede utilizar perfectamente en otros ámbitos o áreas de especialización. Les recomiendo ver el video donde
nos muestran el uso de Scrum para el desarrollo de un automóvil con un equipo distribuido:
https://youtu.be/jKEUcsZVxXw
Sin embargo, se suele hablar de equipos de 7 +/- 2, es decir, mínimo cinco personas y máximo nueve, siendo
este un tamaño que suele garantizar una buena comunicación dentro del equipo de manera de mantenerlos
ágiles y que permita que se reúnan las competencias o habilidades necesarias para desarrollar el incremento al
final del Sprint. Cuando tenemos más de nueve integrantes en el equipo, aumenta la complejidad y se genera la
necesidad de una mayor coordinación, lo que puede impactar en la productividad.
Es recomendable que todos los integrantes del equipo de desarrollo manejen las mismas reglas y normas las
cuales pueden ser definidas de mutuo acuerdo entre ellos para generar una mayor integración y acoplamiento.
Los integrantes del equipo de desarrollo de Scrum asumen un conjunto mayor de responsabilidades con
respecto a enfoques más tradicionales. Así tenemos:
1. Aseguran la entrega del incremento terminado al final de cada Sprint según la definición de terminado
(Definition of Done-DofD), previamente establecida por el equipo al momento de definir las normas y
reglas, contando con el apoyo y conformidad del Product Owner y el Scrum Master.
2. El equipo definirá cómo se ejecutarán cada uno de los elementos que conforman la pila del sprint, para
ello deberán desglosar los requisitos, crear las tareas, estimar y distribuirlos entre cada integrante.

17. 17
3. En el caso de que se haga uso de herramientas para facilitar la visualización y transparencia, el equipo
de desarrollo se compromete a mantenerlos actualizado.
4. Diariamente se reúnen para revisar los avances, identificar riesgos o impedimentos y definir estrategias
de adaptación.
Eventos y Ceremonias
La inspección y la adaptación son dos de los tres pilares de Scrum. La forma de mantener el ciclo constante de
inspección y adaptación dentro de Scrum es por medio de las reuniones que se ejecutan. En Scrum estas
reuniones reciben el nombre de ceremonias y se caracterizan por estar definidas dentro de un timebox, es
decir, cada una tiene una duración máxima de tiempo establecida que varía según la duración del Sprint.
El Sprint es un bloque de tiempo (timebox) que tiene una duración máxima de un mes. Constituye el corazón
de Scrum y podemos verlo como el contenedor de los otros eventos: Planificación del Sprint, Scrum Diario,
Revisión del Sprint y la Retrospectiva.
Como resultado del Sprint se obtiene un producto completamente terminado y listo para ser usado: el
Incremento. Una vez terminado un Sprint, se inicia uno nuevo, se recomienda mantener la duración fija del
Sprint a lo largo de la ejecución de todo el proyecto. Podemos ver cada Sprint como un pequeño proyecto con
una duración no mayor a un mes, que persigue un objetivo: Sprint Goal, el cual no varía durante el Sprint.
Planificación
La primera de las ceremonias es la Ceremonia de Planificación o “Sprint Planning”.
La Sprint planning tiene una duracion máxima de ocho (8) horas para Sprint de cuatro (4) semanas, lo que lo
convierte en la ceremonia más larga dentro de Scrum. La duración del Sprint Planning varia de forma
proporcional a la duración del Sprint, así, por ejemplo, para Sprint de una semana la duración máxima es de
dos (2) horas. Se estiman dos horas por cada semana de duración del Sprint.

18. 18
El Sprint planning se divide en dos fases, en la primera parte de la reunión se define el ¿Qué puede entregarse?
y en la segunda el ¿Cómo se realizará?. Para la primera parte de la ceremonia se requiere la participación de
todo el equipo Scrum: Product Owner, Scrum Master y Equipo de Desarrollo.
Durante la primera parte de la ceremonia el Product Owner es responsable de: presentar al equipo los ítems
del Product Backlog de mayor prioridad y asegurarse de que cada ítem sea entendido con claridad. El Scrum
Master se asegura de que la reunión se realice de forma efectiva y dentro del límite de tiempo. Por su parte, el
Equipo de Desarrollo, aprovecha este espacio de la reunión para resolver cualquier duda en relación a los ítems
del Product Backlog presentados por el Product Owner, es el momento también de hacer concesiones y
renegociar en función de la capacidad y velocidad del equipo.
Como resultado de esta primera fase se define el objetivo o meta del Sprint y cuáles ítems del Product Backlog
pasarán al Sprint Backlog para ser ejecutados por el Equipo de Desarrollo durante el Sprint.
En la segunda parte del Sprint Planning se define Cómo se van a ejecutar los ítems del Sprint Backlog que el
equipo se comprometió a desarrollar en la primera parte de la reunión. En esta etapa el equipo estima cada
uno de los ítems que pasaron a formar parte del Sprint Backlog y desglosa cada uno de ellos en tareas de corta
duración.
La duración máxima de un ítem que pasa al Sprint Backlog y de las tareas que los componen va a depender de
la duración del Sprint. En términos generales una tarea no debería tener una duración mayor a 8 horas, de esta
forma es más fácil visualizar los avances del equipo de desarrollo a lo largo del Sprint y ajustar en caso de ser
necesario.
Actualmente se está desarrollando un proyecto para un importante Banco. El Equipo Scrum formado por el
Product Owner, el Scrum Master y el Equipo de Desarrollo se encuentra iniciando su segundo Sprint para el
desarrollo de un novedoso Home Banking. El Product Backlog actualmente contiene un total de 14 Historias de
Usuario a ser desarrolladas.

19. 19
Reunión Diaria
Luego de terminada la Reunión de Planificación la siguiente reunión que se lleva a cabo dentro del Equipo de
Scrum, para garantizar el ciclo de inspección y adaptación, es la Reunión Diaria (“Daily Meeting”) o Scrum
Diario.
Como su nombre lo indica es una reunión que se realiza diariamente, a la misma hora y en el mismo lugar para
reducir la complejidad. Tiene una duración máxima de 15 minutos. Su objetivo es establecer compromisos,
dentro del Equipo de Desarrollo, sobre el trabajo a realizar en las siguientes 24 horas y detectar cualquier tipo
de impedimentos que pueda poner en riesgo alcanzar el Objetivo del Sprint.
El Daily Meeting es una reunión interna del Equipo de Desarrollo, aunque el Scrum Master se debe asegurar
que la reunión se realice, es responsabilidad del equipo dirigir la reunión y son ellos los únicos que pueden
participar y hablar. En el caso de que otras personas ajenas al equipo estén presentes, el Scrum Master
colabora con el Equipo de Desarrollo, evitando que interrumpan la reunión.
El formato básico de la reunión sugiere responder a 3 preguntas:

20. 20
Se sugiere, aunque no es limitativo, que la reunión se realice de pie, con la idea de evitar excederse en el
tiempo establecido de 15 minutos. Sin embargo, aun cuando puede resultar incómodo estar de pie por mucho
tiempo, la costumbre de tener reuniones largas puede llevar a que el tiempo se exceda. Es responsabilidad del
Scrum Master garantizar que el tiempo de la reunión se encuentre dentro de lo establecido por el timebox y
ayudar al equipo a expresar sus ideas de forma clara, concreta y concisa. Con la práctica, esta tarea será cada
vez más fácil y la mayoría de las veces se podrá completar la reunión incluso antes de los 15 minutos.
La actualización de la Guía de Scrum 2017 incorporó mayor flexibilidad al formato del Daily Meeting, a partir de
la nueva actualización, la estructura de la reunión queda a cargo del Equipo de Desarrollo, pudiendo utilizar las
preguntas básicas como forma de conducir la reunión o basarla en discusiones, utilizando de referencia alguna
herramienta como pudiera ser un tablero de visualización.

21. 21
Revisión
Cuando un Sprint finaliza se revisa el resultado obtenido del tiempo que invirtió el equipo de desarrollo y el
compromiso que adquirió durante la planificación.
La Revisión del Sprint (Sprint Review) es una reunión que se realiza para comprobar el incremento,
generalmente no debe durar más de cuatro horas para Sprints muy largos es decir de un mes, lo habitual es
que con una o dos horas de duración suele ser suficiente. Se debe realizar el último día del Sprint antes de la
ceremonia de Retrospectiva.
El objetivo principal de esta ceremonia es que el Dueño del Producto compruebe el progreso del producto. Esta
reunión marca, a intervalos regulares, el ritmo de elaboración, y la trayectoria que va tomando la visión del
producto. Aquí el Dueño del Producto identifica los requerimientos que se pueden considerar como "Hechos" y
los que no. Se prueban las funcionalidades entregadas y el equipo en general obtiene feedback.
Debe asistir todo el equipo de desarrollo, el dueño del producto, el Scrum Master y todas las personas
involucradas en el proyecto si así lo desean.
La reunión es un tanto informal, su objetivo como se comentó es ver el incremento realizado, las
presentaciones gráficas y “power points” se encuentran prohibidos. El equipo no debe invertir más de cuatro
horas en desarrollar la reunión, y lo que se muestra es el resultado final: unos requerimientos terminados,
probados y operando en el entorno del cliente.
Es una reunión informativa. Su misión no es la toma de decisiones ni criticar el incremento entregado. Con esta
información posteriormente el dueño del producto tratará las posibles modificaciones sobre la visión del
producto. Se recomienda seguir el siguiente formato:
1. El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y las que se han
desarrollado

22. 22
2. El equipo hace una introducción general de sprint y demuestra el funcionamiento de las
funcionalidades desarrolladas
3. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el dueño
del producto y el equipo en general, puedan mejorar la visión del producto
4. El Scrum Master, de acuerdo con las agendas del dueño de producto y el equipo, fija la fecha para la
reunión de la preparación del siguiente sprint.
Retrospectiva
Según la wikipedia "Retrospectiva (del latín: retrospectare) es una enumeración y celebración de eventos ya
ocurridos, y normalmente organizada y presentada al final de dicho evento".
El Sprint Retrospective es una reunión que le permite al equipo darse la oportunidad de inspeccionarse y crear
un plan de mejoras que se promulgarán durante el próximo Sprint. El propósito es revisar cómo fueron las
cosas respecto al proceso, la relación entre las personas y las herramientas utilizadas. El equipo identifica qué
salió bien y qué no tan bien, e identifica potenciales mejoras.
Es una reunión cuyo tiempo máximo es de tres(3) horas para un Sprint de cuatro(4) semanas, es realizada al
final de cada Sprint donde el equipo evalúa la culminación de dicha iteración, capturando lo positivo y las
mejores prácticas, identificando nuevos retos y estrategias de mejora. Es dirigida comunmente por el Scrum
Master pero es buena práctica que los miembros del equipo puedan rotar el rol de facilitador durante la
ceremonia, la participación del Dueño del Producto (Product Owner) y otros involucrados (Stakeholders) es
opcional.
De una Retrospectiva se espera lo siguiente:
1. Reconocer fortalezas y logros
2. Espacio para ser escuchado

23. 23
3. Liberar algunas tensiones
4. Desarrollar el sentimiento de pertenencia como equipo
5. Aprendizaje en equipo
6. Comprender distintas visiones dentro del equipo
La retrospectiva es un momento especial en el cual un equipo decide hacer una pausa para: reflexionar sobre la
forma en que ha realizado el trabajo, explorar oportunidades de mejora, decidir cómo experimentar con lo
aprendido en equipo, la forma de ampliar la perspectiva de cada uno de sus miembros y ayudar a que los
equipos piensen, aprendan, decidan y actúen juntos.
Las retrospectivas juegan un rol muy importante respecto al desarrollo iterativo e incremental. En efecto, al
final de cada iteración, una retrospectiva es cumplida buscando específicamente modos de mejorar el proceso
para la siguiente iteración.
Para sacar lo mejor de cada integrante del equipo durante la sesión, existen diversas técnicas que facilitan la
transparencia y la adaptación buscada de manera recurrente por la filosofía ágil.
La técnica oficial para estas sesiones es dar respuesta a la trilogía ¿Qué ha salido bien durante el Sprint?, ¿Qué
ha fallado? y ¿Qué se puede mejorar?, este formato se puede facilitar pidiendo a los miembros del equipo
Scrum que expresen de forma escrita u oral sus inquietudes, para luego agruparlos y votar sobre aquellos ítems
que sean más relevantes, dando a todos la oportunidad de hablar y manifestar sus ideas.
Las reuniones de Retrospectivas son realizadas de forma periódica y se han convertido en una de las prácticas
ágiles más utilizadas en algunas metodologías, se considera dentro del marco Scrum como una ceremonia muy
valiosa, si bien no es una reunión para seguimiento de la evolución del producto, sino para la mejora del marco
de trabajo. Con ella se realiza una mirada al pasado, recordándoles que:
"No se puede cometer el mismo error dos veces, porque la segunda vez no es un error es una decisión"
Artefactos
Scrum tiene tres Pilares sobre los que se fundamenta: Transparencia, Inspección y Adaptación. El ciclo
constante de Inspección y Adaptación se logra por medio de los distintos eventos o ceremonias que conforman
el Scrum, para garantizar la transparencia Scrum cuenta con tres artefactos: la Lista de Producto (Product
Backlog), la Lista de Pendientes del Sprint (Sprint Backlog) y el Incremento del producto.
Cuando hablamos de transparencia es importante resaltar que todos los artefactos dentro del marco de
trabajo deben estar disponibles para todo el equipo Scrum: Dueño del Producto, Scrum Master y Equipo de
desarrollo y, adicionalmente, a todos los Interesados o Stakeholders. Es por esta razón que los stakeholder
participan en la ceremonia de revisión, la cual les brinda la oportunidad de interactuar y dar feedback sobre el
incremento resultante del Sprint y de tener acceso, real, a los avances del producto. Los demos y
presentaciones no son una opción si se quiere cumplir a cabalidad con el pilar de la transparencia.
Lista de Producto
La Lista o Pila de Producto (Product Backlog) reúne todos los requisitos, funcionalidades y mejoras del producto
o servicio a desarrollar a lo largo de los distintos Sprint y constituye la única fuente de requisitos.

24. 24
Una de las características principales de la Pila de Productos es que se encuentra priorizada por valor y ningún
ítem puede tener la misma prioridad que otro. Podemos imaginar que realizamos una formación de los ítems o
elementos de nuestra Pila de Productos uno detrás del otro, colocando en la primera posición el ítem que
genera el mayor valor a nuestro producto o servicio e ir avanzando en orden decreciente de valor hasta que
llegamos al final de la formación donde estaría el ítem que menos valor tiene, ese que, incluso, pudiéramos
llegar a eliminar.
El Dueño del Producto es el responsable tanto del contenido del Product Backlog como de determinar el valor
que tiene de cada uno de los elementos que lo conforman y de mantener la Lista de Producto ordenada según
la prioridad. Adicionalmente, es responsable de garantizar la transparencia al asegurarse que la Pila de
Producto esté disponible para todos.
Existen distintos criterios para priorizar los ítems y determinar el valor de cada uno de ellos, uno de los más
simples es empezar por establecer ¿Qué es indispensable que nuestro producto o servicio tenga para que
funcione?
El Product Backlog es un artefacto vivo, constantemente está cambiando. Es decir, el Product Owner puede
añadir nuevos elementos, eliminar algunos que ya no sean requeridos o redefinir prioridades, todo ello en
respuesta a cambios en el mercado, en las necesidades de los stakeholders o como consecuencia directa del

25. 25
feedback recibido durante la ceremonia de revisión, donde al interactuar con el producto o servicio, se pueden
detectar nuevas necesidades o ser consciente de que algunos elementos, contrario a lo que se pensaba, no son
realmente importantes para lograr un producto útil y competitivo.
No hay que desestimar nunca el valor de la Revisión, ya que permite inspeccionar y adaptar de forma
constante nuestra Lista de Producto. Recordemos que:
"Muchas veces la gente no sabe lo que quiere hasta que se lo enseñas."
Steve Jobs
Los elementos que conforman la Lista de Producto adicional al orden y el valor, tienen una descripción provista
por el Dueño del Producto y una estimación realizada por el equipo de desarrollo. Para realizar estimaciones
más exactas se requiere que los elementos tengan un mayor nivel de detalle por lo que el Equipo de Desarrollo
puede coordinar, conjuntamente con el Product Owner, un Refinamiento del Backlog para revisar los
elementos y añadir detalles. Aquellos elementos de la Lista de Producto que tienen el suficiente nivel de
detalle y un nivel de granularidad tal que puedan ser terminados dentro de un Sprint, se consideran
preparados para pasar a un siguiente Sprint.
Los elementos de la Lista de Productos también deben incluir descripciones de pruebas o criterios de validación
que serán usados por el Equipo de Desarrollo para establecer si un ítem puede ser dado como terminado y por
el Dueño del Producto para validar que los elementos estén completos según lo acordado.
Scrum no establece prescripciones sobre el tipo de elementos que conforman la Lista de Producto, sin
embargo, para efectos de este curso, se sugiere el uso de Historia de Usuarios con criterios de aceptación.
Lista de Sprint
El Sprint Backlog es un subconjunto de items del Product Backlog seleccionados para el Sprint, más un plan
para entregar el incremento del producto y conseguir el objetivo del Sprint.
Es una lista de los trabajos que debe realizar el equipo de desarrollo durante el Sprint para generar el
incremento previsto, con respecto al plan, el mismo es elaborado por el equipo de desarrollo. El Sprint Backlog
hace visible y transparente todo el trabajo que el team identifica como necesario para alcanzar el objetivo del
Sprint y sólo él tiene la potestad para alterarlo.

26. 26
Es un artefacto vivo debido a que el equipo de desarrollo puede modificarlo durante el Sprint y el Sprint
Backlog emerge durante este tiempo, a medida que el equipo de desarrollo ejecuta el plan y aprende sobre el
trabajo necesario para alcanzar el objetivo del Sprint: si se descubre que es necesario realizar nuevo trabajo, se
agrega al Sprint Backlog; si alguno de los elementos del plan del Sprint se tornan innecesarios, se remueven. En
la siguiente figura se puede observar un ejemplo donde se muestra un subconjunto de cuatro items (historias
de usuario) seleccionados para ser desarrollados durante un Sprint, dividido a su vez en tareas que aparecen en
color azul.
La pila del sprint conformadas por historias de usuario (comúnmente muy usadas en Scrum) se descomponen
en unidades de tamaño adecuado para revisar el avance diario, permitiendo la comunicación visual directa del
equipo. Es confeccionado en la reunión de planificación del sprint, por lo tanto:
o Los miembros del equipo lo realizan de forma conjunta y puede ser modificado sólo por ellos
o Permite cubrir las tareas identificadas por el equipo para conseguir el objetivo del Sprint
o Tareas grandes deben descomponerse en otras más pequeñas. Las buenas prácticas indican que una
tarea tenga un tamaño que no pase de más de un día de trabajo
o Para que sea transparente debe estar visible para todo el equipo, lo ideal es utilizar un tablero en una
pared en el mismo espacio físico donde el equipo trabaja.
Durante el sprint, el equipo actualiza a diario los tiempos pendientes de cada tarea. Al mismo tiempo, con
estos datos traza el gráfico de avance o trabajo pendiente (burn-down), que se describe más adelante.

27. 27
Incremento del producto
Las iteraciones en Scrum se conocen como Sprints. Scrum, como todos los enfoques ágiles, es un proceso de
construcción incremental e iterativo. Esto significa que el producto se construye en incrementos funcionales
entregados en periodos cortos para obtener feedback frecuente.
El incremento es la parte de producto producido en un Sprint, y tiene como característica el estar
completamente terminado y operativo, en condiciones de ser entregado al cliente, además de poder utilizarse
sin importar si el Dueño de Producto (Product Owner) decide liberarlo o no, además debe entregarse en la
ceremonia de Revisión o Sprint Review.

28. 28
Para el caso del desarrollo de software no se deben considerar como Incremento a prototipos, módulos o sub-
módulos, ni partes pendientes de pruebas o integración.
Cuando un Sprint finaliza se debe revisar el resultado obtenido del tiempo que invirtió el equipo de desarrollo y
el compromiso que adquirió durante la planificación. El resultado de cada Sprint es en primer lugar la
sumatoria de todos los Ítems del Sprint Backlog completados, y en segundo lugar el valor total de este conjunto
de Ítems, sumados a todos los incrementos de Sprints anteriores.
Como artefacto el incremento es una característica funcional nueva (o modificada) de un producto que está
siendo construido de manera evolutiva. El producto crece con cada Sprint y debe considerarse terminado, esto
significa que está en una condición tal que lo hace utilizable y que, además, cumple con la “Definición de
Terminado” conocido en inglés como "Definition of Done" del Equipo Scrum.
Herramientas
Como hemos visto en secciones anteriores Scrum se basa en tres pilares fundamentales: Transparencia, que se
logra por medio de los artefactos propios de Scrum y los ciclos continuos de Inspección y Adaptación, que
ocurren en cada una de las ceremonias. Adicionalmente, para facilitar cumplir con estos tres pilares, Scrum
hace uso de herramientas que ayudan a tener mayor visibilidad de lo que ocurre a lo largo del Sprint y facilitan
el ciclo de Inspección y Adaptación.
En esta sección veremos tres de estas herramientas: las Historias de Usuario, el Burndown Chart y el Tablero de
Scrum, aunque ninguna de ellas está prescrita dentro del marco de Scrum, se recomienda su uso,
especialmente en etapas tempranas de la adopción del marco de trabajo. En el caso de equipos con alguna
experiencia, pueden adaptar estas herramientas a las necesidades propias del equipo o de la organización y
¿por qué no?, crear opciones propias que faciliten la visibilidad, la transparencia y la toma oportuna de
decisiones en los ciclos de inspección y adaptación.

29. 29
Historias de Usuario
 Narración corta y simple de una funcionalidad, escrita desde la perspectiva de la persona que necesita
una nueva capacidad de un sistema o producto
 Representación de un requerimiento escrito en una o dos frases utilizando el lenguaje común del
usuario.
 Forma rápida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de
documentos formales.
 Es un punto para iniciar una conversación entre el cliente y el equipo
 Requieren definir el cómo se confirma su implementación, las pruebas y verificación de la misma
(criterio de aceptación).
 Las historias de usuario sólo dicen el “qué” y no el “cómo”.
El estilo de escritura de una Historia de Usuario puede ser libre lo recomendable es que debe responder a tres
preguntas: ¿Quién se beneficia?, ¿Qué se quiere? y ¿Cuál es el beneficio? algunos autores aconsejan redactar
las historias de usuario según el formato: Como (rol) quiero (objetivo) para (beneficio), además una Historia de
Usuario debe tener en un momento dado pruebas de validación lo que le permitirá a quien la desarrolle y
posteriormente al cliente, verificar si la misma ha sido completada.
Una HU debe cumplir con el atributo INVEST y debe poder ser desarrollada en un Sprint.
 Una historia debería ser independiente de otras (lo más posible)
 Una historia de usuario es conversada , razonada y discutida (negociable)
 Cada historia tiene que tener valor para el cliente
 Los desarrolladores necesitan poder estimar una historia de usuario para permitir que se pueda
priorizar y planificar.
 Una buena historia debe ser pequeña (small) en esfuerzo, manteniendo la simplicidad
 Una historia necesita poder probarse (testeable) para que ocurra la etapa de trabajo

30. 30
Burndown Chart
Un diagrama burndown es una representación gráfica del trabajo por hacer en un proyecto en el tiempo.
Usualmente el trabajo remanente se muestra en el eje vertical y el tiempo en el eje horizontal. Es decir, el
diagrama representa una serie temporal del trabajo pendiente. Es muy usado en Scrum y sirve como
herramienta en un proyecto ágil para mostrar de una forma clara al equipo qué está pasando y cómo se están
realizando los avances en cada sprint.
Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se está completando los
objetivos/requisitos. Permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado.
Tablero Scrum
La idea básica de un tablero Scrum es visualizar el trabajo que hacemos, no sólo para ayudar a enfocarnos sino
para visualizar el flujo de trabajo en un equipo.