1

Bienvenidos estimados alumnos a esta clase la cual tiene el título de; metodología
Scrum, en esta clase tenemos los siguientes objetivos:

1. Manejar los conceptos del método Scrum

2. Aplicar dicha metodología en proyectos software
3. Manejar los diferentes procesos
4. Mostrar los tipos participantes de Scrum Modelo scrum

Introducción

En muchas empresas se comete el error de no poder dimensionar el trabajo que se

debe hacer, la participación del usuario o cliente queda relegada a los inicios cuando
se recaba información sobre los requerimientos, para llegar al producto final el
cliente debe esperar y muchas veces al final no obtiene lo que espera, la
funcionalidad no cumple con lo que el necesita, por tanto se ha perdido un tiempo
valioso, los cambios implican mayor inversión en esfuerzo, tiempo y costos, la
perdida puede llegar implicar perdidas de oportunidades en el campo competitivo
de la empresa. Todo lo anterior implica le poder desarrollar bajo los métodos agiles,
lo cual tiene la filosofía de entregar incrementos sobre el producto software,
haciendo esto mas visible en cuanto a funcionalidad para el cliente, para el dueño
del producto

Orígenes
Rugby una jugada por tener el balón entre ambos equipos formándose una especie
de melee, el que lo tiene inicia el juego
La historia de Scrum se puede rastrear desde 1986 en un artículo de la Harvard
Business Review, “El nuevo juego para el desarrollo de productos” por Hirotaka
Takeuchi y Ikujiro Nonaka.
El concepto de Scrum tiene su origen en un estudio de 1986 sobre los nuevos
procesos de desarrollo utilizados en productos exitosos en Japón y los Estados
Unidos (cámaras de fotos de Canon, fotocopiadoras de Xerox, automóviles de
Honda, ordenadores de HP y otros). Los equipos que desarrollaron estos productos
partían de requisitos muy generales, así como novedosos, y debían salir al mercado
en mucho menos del tiempo del que se tardó en lanzar productos anteriores. Estos
equipos seguían patrones de ejecución de proyecto muy similares. En este estudio
se comparaba la forma de trabajo de estos equipos altamente productivos y
multidisciplinares con la colaboración entre los jugadores de Rugby y su formación
de Scrum (melé en español).

1
 2

En 1993 se realizó el primer Scrum para desarrollo de software, Jeff Sutherland,

John Scumniotales y Jeff McKenna concibieron, ejecutaron y documentaron el
primer Scrum para desarrollo ágil de software en 1993, utilizando el estudio de
gestión de equipos de Takeuchi y Nonaka como base. 1995 el proceso fue
formalizado En 2001 un grupo de personas muy relevantes en lo que empezaba a
ser el desarrollo ágil escribieron los valores fundamentales de los procesos ágiles.
Desde 1995 miles de proyectos en todo el mundo han utilizado Scrum para el
desarrollo de productos, tanto en empresas pequeñas, “startups” con tan sólo 3
personas desarrollando un producto, como en multinacionales, entre las que se
encuentran las siguientes:

¿Por qué estudiar el método Scrum?

Las empresas exigen nuevas formas de realizar los proyectos que permitan obtener
el máximo de rendimiento del tiempo empleado en sus actividades y procesos y que
sean capaces de producir resultados satisfactorios. Indudablemente que estos
resultados van encaminados a dejar una buena sensación al cliente y por ende al
usuario final
Tiempo atrás, el desarrollo de software implicaba que el cliente tenía que esperar
hasta el final, en otras palabras cuando ya el sistema estaba terminado, el cliente
podía ver en su totalidad el sistema terminado, y en muchas ocasiones el cliente se
sentía decepcionado,
• Primero porque en la mayoría de casos el tiempo estipulado de la entrega no
era el acordado por tanto los costos se habían incrementados
• segundo lo que obtenía como producto final de alguna forma no cumplía con
sus necesidades lo que llamaremos requerimientos

2
 3

Se crearon por tanto métodos que fueran más agiles, que hicieran que el cliente
participara activamente y poder entregarle partes del sistema.

Se pueden imaginar que un cliente pueda comenzar a trabajar pronto con las partes
del sistema que el considere más urgentes. Estas partes en la metodología scrum
se llaman incrementos

Concepto Scrum
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene
origen en un estudio de la manera de trabajar de equipos altamente productivos.

Buenas prácticas
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible en proyectos complejos desarrollados en entornos dinámicos y cambiantes
de un modo flexible.

A los fundamentos de Scrum y estos podemos decir que son:

• El desarrollo incremental de los requisitos del proyecto en bloques
temporales cortos y fijos (iteraciones de un mes natural y hasta de dos
semanas, si así se necesita).
• La priorización de los requisitos por valor para el cliente y coste de desarrollo
en cada iteración.
• El control empírico del proyecto. Por un lado, al final de cada iteración se
demuestra al cliente el resultado real obtenido, de manera que pueda tomar
las decisiones necesarias en función
de lo que observa y del contexto del proyecto en ese momento. Por otro lado,
el equipo se sincroniza diariamente y realiza las adaptaciones necesarias.
• La potenciación del equipo, que se compromete a entregar unos requisitos y
para ello se le otorga la autoridad necesaria para organizar su trabajo.

Su aplicación
• Equipos pequeños: cuando en tus proyectos los equipos de trabajo no
superan las 8 personas. Aunque existen casos de empresas que la han
utilizado con éxito en equipos más grandes, no es recomendable.
• Poca necesidad de documentación: si el cliente te exige que todo el proyecto
esté muy bien documentado desde el principio (fases de consultoría y de

3
 4

tomas de requerimientos largas) SCRUM no es tu metodología. Sin embargo,

si sus expectativas son las entregas rápidas y tener mucho control sobre el
proyecto, el SCRUM te resultará muy útil porque se enfoca precisamente en
este aspecto.
• Proyectos con riesgos de cambios durante el proceso: como la metodología
SCRUM ejecuta el proyecto en fases cortas de dos a cuatro semanas,
permite mucha flexibilidad a la hora de acometer cambios a mitad del
proyecto, ya que tras cada fase se replantean las tareas y los objetivos.
• Confianza en la metodología: serás el encargado de velar que se cumpla, por
lo tanto, antes de trabajar en un proyecto con SCRUM debes aprender bien
cuáles son sus principios y maneras de operar y sentirte cómodo con ellos,
para poder traspasar esa confianza al resto de los actores de tu proyecto.

Requisitos

1. Cultura de empresa basada en trabajo en equipo, delegación,

creatividad y mejora continua
La cultura de la empresa proveedora del proyecto debe estar alineada con la
filosofía de una gestión ágil de proyectos como Scrum. Debe fomentar:
El trabajo en equipo y la colaboración entre todas las personas implicadas
en un proyecto. Equipos auto gestionados a los que se ha delegado la
responsabilidad y autoridad para hacer su trabajo, en contraposición a la
dirección y control de personas que ejercería un jefe de proyecto tradicional
(en lugar del jefe de proyecto existe la figura del Facilitador).
La creatividad del equipo.
La transparencia y la mejora continua, tanto del contexto de la organización
y del proyecto y como de las herramientas del equipo.
Scrum sistematiza la identificación de obstáculos que pueden impedir el
correcto progreso del proyecto. Los problemas previamente existentes en la
organización (procesos, personas, herramientas, etc.) y que atentan contra
la productividad se harán más evidentes cuando se aplique Scrum y será
necesario irlos solucionando.

2. Compromiso del cliente

Scrum exige del cliente una alta implicación y una dedicación regular:
El cliente tiene la responsabilidad de dirigir los resultados del producto o
proyecto:

4
 5

El cliente debe disponer de una visión de alto nivel del producto o proyecto y
tener reflejadas sus expectativas en forma de lista de requisitos priorizada
donde ha indicado el valor que le aportará cada uno. A partir de los costes
de desarrollo que le proporcione el equipo, priorizará los requisitos en función
del Retorno de la Inversión (ROI) más rápido.
El cliente re planifica el proyecto en cada iteración para maximizar este ROI
de manera continua.
Al tratarse de un proyecto que va entregando resultados en iteraciones
regulares, el cliente debe colaborar participando en el inicio de cada iteración
(reunión de planificación) y en el fin de cada iteración (demostración), y debe
estar disponible durante la ejecución de cada iteración para resolver dudas.

3. Compromiso de la dirección
Se harán muy evidentes los obstáculos ya existentes y por venir que impiden
el correcto desarrollo de los proyectos (a nivel de expectativas del cliente,
productividad, calidad, etc.), sean organizativos, técnicos, procesos,
relaciones entre personas/departamentos, habilidades de los equipos, etc.
Será necesario tomar decisiones, realizar cambios organizativos, alinear a
personas y proporcionar recursos para hacer la transición. Gestores y
equipos deberán desaprender formas de trabajar y de relacionarse a las que
estaban habituados y aprender nuevas dinámicas.
Un proyecto ya no consistirá en que cada Departamento/Área/Unidad realice
su parte del trabajo y se la pase al siguiente. Será necesario formar equipos
auto gestionados y multidisciplinares capaces de conseguir un objetivo por
ellos mismos.
Habrá gestores que tendrán que cambiar sus roles para ser Facilitadores
(Ver el artículo "El buen gestor de un equipo ágil") o Clientes, en una
jerarquía de equipos haciendo Scrum de Scrum
Se tendrá que gestionar aquellas conductas personales que no permiten que
otras personas puedan aportar ideas sobre el qué y el cómo de un proyecto,
que defienden a toda costa su parcela de responsabilidad, que les cuesta
mucho cederla al equipo y dejar de controlarlo, que no son capaces de
delegar tareas o de colaborar con otras personas en la resolución de
problemas.

5
 6

4. Compromiso del equipo

Scrum se basa en el compromiso conjunto y la colaboración entre los
miembros del equipo. La transparencia entre todos es fundamental para
poder inspeccionar la situación real del proyecto y así poder hacer las
mejores adaptaciones que permitan conseguir el objetivo común. Por ello,
será difícil trabajar utilizando Scrum para las personas que:
No confían en los demás, no permiten que otras personas puedan aportar
ideas sobre el qué y el cómo, no son capaces de colaborar en la resolución
de problemas ni de delegar tareas. No son transparentes respecto a su
trabajo personal, sea por que defienden a toda costa su parcela de
responsabilidad o por inseguridad para comunicarse o colaborar, cosa que
no permite que sean ayudados.
Su modo de relación se basa en la generación de conflicto o bien evitan
entrar en conflictos sanos en que ambas partes ganen (ganar/ganar), con lo
que los problemas realmente no se resuelven sino que crean
conversaciones veladas, de manera que estas personas no acaban de
adquirir un compromiso real con el equipo.
Priorizan su ego, sus intereses personales, de carrera o de departamento,
por encima de los intereses del equipo.
No son capaces de cambiar sus hábitos y salir de su zona de confort, tienen
miedo al cambio, prefieren que se les diga qué tienen que hacer o quieren
decir a los demás qué tienen que hacer.
Quieren seguir siendo los héroes que solucionan los proyectos y/o las
personas de las que depende la empresa
.
5. Facilidad para realizar cambios en el proyecto
Para poder utilizar Scrum se debe poder ir incorporando requisitos de
manera incremental en el producto del proyecto y realizar cambios de forma
controlada sin un coste prohibitivo para el cliente. Para ello es necesario:
Disponer de técnicas y herramientas que faciliten el crecimiento incremental
y la introducción de cambios.
Mantener la simplicidad y calidad interna del producto que se está creando.
Para cubrir los requisitos actuales del cliente no hay que realizar más
esfuerzo del que sea necesario y, a la vez, se debe vigilar no hacer nada en
contra de futuros requisitos.

6
 7

6. Tamaño del equipo

El tamaño de un equipo está entre 5 y 9 personas. Por debajo de 5 personas
cualquier imprevisto o interrupción sobre un miembro del equipo compromete
seriamente el compromiso que han adquirido y, por tanto, el resultado que
se va a entregar al cliente al finalizar la iteración. Por encima de 9 personas,
la comunicación y colaboración entre todos los miembros se hace más difícil
y se forma subgrupos.

De cualquier manera, se puede hacer Scrum con 3 personas y se ha utilizado

en proyectos con 250 personas en varios equipos. Cuando es necesario que
más de un equipo trabaje de manera ágil en un mismo proyecto, existen
diferentes técnicas que permiten esta colaboración, desde el Scrum de
Scrums hasta equipos de integración que dedican parte de su tiempo a
trabajar con los equipos de desarrollo, siempre completando incrementos de
producto de manera regular, con el resultado integrado de los diferentes
equipos.

7. Equipo trabajando en un mismo espacio

Todos los miembros del equipo trabajan en la misma localización física, para
poder maximizar la comunicación entre ellos mediante conversaciones cara
a cara, diagramas en pizarras blancas, tarjetas en el tablón de tareas, etc.
De esta manera se minimizan otros canales de comunicación menos
eficientes (llamadas telefónicas, correos electrónicos, documentos, etc.), que
hacen que las tareas se transformen en un “pasa pelota” o que hacen perder
el tiempo en el establecimiento de la comunicación (como cuando se tiene
que llamar repetidas veces por teléfono a una persona que no está en su
puesto, o cuando se interrumpe con una llamada telefónica a una persona
que está concentrada en una tarea).

BENEFICIOS
• Cumplimento de expectativas: El cliente establece sus expectativas
indicando el valor que le aporta cada requisito / historia del proyecto, el equipo
los estima y con esta información el Product Owner establece su prioridad.
De manera regular, en las demos de Sprint el Product Owner comprueba que
efectivamente los requisitos se han cumplido y transmite se feedback al
equipo.
• Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de
requerimientos generados por necesidades del cliente o evoluciones del

7
 8

mercado. La metodología está diseñada para adaptarse a los cambios de

requerimientos que conllevan los proyectos complejos.
• Reducción del Time to Market: El cliente puede empezar a utilizar las
funcionalidades más importantes del proyecto antes de que esté finalizado
por completo.
• Mayor calidad del software: La metódica de trabajo y la necesidad de obtener
una versión funcional después de cada iteración, ayuda a la obtención de un
software de calidad superior.
• Mayor productividad: Se consigue entre otras razones, gracias a la
eliminación de la burocracia y a la motivación del equipo que proporciona el
hecho de que sean autónomos para organizarse.
• Maximiza el retorno de la inversión (ROI): Producción de software
únicamente con las prestaciones que aportan mayor valor de negocio gracias
a la priorización por retorno de inversión.
• Predicciones de tiempos: Mediante esta metodología se conoce la velocidad
media del equipo por sprint (los llamados puntos historia), con lo que
consecuentemente, es posible estimar fácilmente para cuando se dispondrá
de una determinada funcionalidad que todavía está en el Backlog.
• Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más
valor en primer lugar y de conocer la velocidad con que el equipo avanza en
el proyecto, permite despejar riesgos eficazmente de manera anticipada.

Roles
Product Owner:
• El Dueño de Producto es la única persona autorizada para decidir sobre
cuáles funcionalidades y características funcionales tendrá el producto. Es
quien representa al cliente, usuarios del software y todas aquellas partes
interesadas en el producto.
• Tiene una visión del producto, desde la generación de la idea y/o
conceptualización del producto, hasta la operación del mismo
• Es el responsable de decidir “QUÉ” se quiere conseguir en cada Sprint.
• Responsable de aceptar o rechazar el sprint
• Creador de las historias
• Crea el product backlog
• Es el garante del ROI del producto Funciones
• Definir el objetivo de cada sprint con claridad
• Gestionar el backlog del producto para cumplir el objetivo

8
 9

• Priorizar el backlog para cumplir el objetivo

• Desglosar adecuadamente cada uno de los elementos priorizados del
backlog
• Expresar claramente los elementos para ser entendidos por el equipo de
especialistas
• Negociar con el equipo de especialistas el alcance de cada sprint
• Planificar las entregas del producto

Scrum master
Scrum Master o facilitador de proyectos, es la figura que lidera los equipos en la
gestión ágil de proyectos. Su misión es que los equipos de trabajo alcancen sus
objetivos hasta llegar a la fase de
“sprint final”, eliminando cualquier dificultad que puedan encontrar en el camino
1. Es el garante del Modelo Scrum.
2. Es un líder “influyente” al servicio del Equipo Scrum y de la Organización.
3. Tiene conocimiento y experiencia en el marco de trabajo y en el modelo
organizativo Scrum.
4. Sirve al Product Owner, ayudándole a entender:
o La planificación del producto en un entorno empírico o El
mantenimiento de una Lista de Producto clara y priorizada
5. Sirve al Equipo Técnico, enseñándole:
o A ser un equipo auto-organizado y multifuncional o A eliminar
impedimentos para su progreso
6. Sirve a la Organización, liderando la adopción de Scrum:
o Planificando su implementación
o Motivando cambios que incrementen la productividad del
Equipo Scrum
7. Es el máximo responsable de asegurar que el modelo es entendido y
aplicado. Funciones
• Enseñar el Modelo Scrum
• Asegurar su entendimiento y aplicación
• Facilitar los eventos de Scrum según se requiera
• Ayudar a eliminar impedimentos
• Motivar cambios que incrementan la productividad del Equipo Scrum

9
 10

• Trabajar con otros Scrum Masters para aumentar la efectividad del modelo
en la Organización.

EQUIPO TÉCNICO
El Equipo Técnico es el equipo de especialistas que se organizan en torno a la
entrega de un incremento de producto, con el fin de garantizar su entrega en el
menor tiempo posible y con la máxima calidad posible.
En este contexto, el Equipo Técnico:
1. Es el garante del incremento del producto.
2. En su conjunto es el líder del proceso.
3. Es un equipo auto-gestionado y multifuncional.
4. El team es el responsable de decidir “CÓMO” se va a conseguir el incremento
en cada Sprint.
5. Y también es el responsable de la calidad del incremento “terminado”,
entendiendo terminado como que cumple las condiciones de aceptación
consensuadas con el Producto Owner.
6. El ET es el máximo responsable de cumplir los compromisos adquiridos con
el Product Owner. El Equipo Técnico se caracteriza por:
• Ser una unidad indivisible en cuanto a la responsabilidad de la entrega del
incremento.
• No existir jerarquía en su organización. No se reconocen títulos ni
dependencias jerárquicas entre ninguno de los componentes del equipo.
Tampoco se reconocen sub-equipos por dominios
• Está empoderado por la organización para auto-gestionarse, respetando sus
decisiones Estar formado por al menos 3 personas, y no más de 9

El proceso en Scrum
La planeación del sprint (sprint planning)
Lo primero que debe hacerse en cada Sprint es la Planificación del Sprint. La
Planificación del Sprint es una reunión de tiempo limitado a 8 horas para Sprint con
una duración de un mes, y que será proporcionalmente más corta en el caso de
Sprint duren menos. Los tres roles deben asistir a esta reunión.
El equipo de desarrollo debe estimar la capacidad de trabajo que puede ofrecer en
un solo Sprint. Previamente el Dueño del Producto ya ha clasificado y ordenado los
elementos del Backlog del Producto en base al valor de los artículos.

10
 11

En esta reunión junto con todo el equipo Scrum en pleno que se responden estos
dos aspectos:
• ¿Qué puede entregarse en el incremento resultante del Sprint que comienza?
• ¿Cómo se conseguirá hacer el trabajo necesario para entregar el incremento?
Primera parte de la reunión. Se realiza en un timebox de cómo máximo 4 horas:
• El cliente presenta al equipo la lista de requisitos priorizada del producto o
proyecto, pone nombre a la meta de la iteración (de manera que ayude a tomar
decisiones durante su ejecución) y propone los requisitos más prioritarios a
desarrollar en ella.
El Dueño del Producto también es responsable de asegurarse que los elementos
(historias) sean fáciles de entender.
• El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade
más condiciones de satisfacción y selecciona los objetivos/requisitos más
prioritarios que se compromete a completar en la iteración, de manera que
puedan ser entregados si el cliente lo solicita.

Segunda parte de la reunión. Se realiza en un timebox de cómo máximo 4 horas.

Haciendo las actividades siguientes:
• Define las tareas necesarias para poder completar cada objetivo/requisito,
creando la lista de tareas de la iteración (Sprint Backlog) basándose en la
definición de hecho.
• Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.
• Cada miembro del equipo se auto asigna a las tareas que puede realizar.

El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor

resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado
que ha adquirido un compromiso, es el responsable de organizar su trabajo y es
quien mejor conoce cómo realizarlo el equipo de desarrollo selecciona un número
de elementos de la parte superior del Backlog del Producto y los pone en el Backlog
del Sprint, para completarlos y entregarlos en el Sprint actual
Seleccionados las historias, el Equipo Scrum debería redactar el objetivo del Sprint.
El objetivo del Sprint es el objetivo que debería alcanzarse durante el Sprint a través
del desarrollo de los elementos seleccionados del Backlog del Producto, y
proporciona orientación al Equipo de Desarrollo sobre por qué se está construyendo
el incremento. Ejemplos del objetivo o meta del sprint

11
 12

Vamos a habilitar todas las partes de ingreso de los datos del cliente, vehículo y sus
aseguradoras, para permitir un proceso completo de servicio al cliente. Haciendo
que las consultas y controles de los procesos del vehículo sean un seguimiento en
línea para el cliente del taller Al final de la reunión el equipo tiene definidos:
• El objetivo del sprint
• Una lista de pendientes del sprint (sprint backlog)
Además del número total de puntos de historia (esfuerzo) que se construirán en el
sprint que comienza

El alcance del sprint

El alcance del Sprint, que está compuesto por los distintos elementos seleccionados
del Backlog del Producto, podría necesitar un mayor grado de detalle conforme el
Sprint vaya evolucionando. Este mayor grado de detalle deberá estar siempre
alineado con el Objetivo del Sprint, y en el caso que fuera necesario negociarse,
deberá estar presente el Dueño del Producto. El objetivo del Sprint también se
incluye en el Backlog del Sprint.
Una vez seleccionado los elementos a entregar y establecido el objetivo del Sprint,
es momento de planificar cómo los distintos artículos del Backlog del Sprint van a
“transformarse” en un incremento del producto “Completo”, y como a través de estos
se hará realidad el objetivo del Sprint. Esta es la última parte del Backlog del Sprint.
No es necesario desarrollar un plan detallado para todos y cada uno de los
elementos del Backlog del Sprint durante la sesión de Planificación del Sprint. Es
suficiente con tener un plan detallado de los elementos en los que se trabajará los
primeros días; el equipo de desarrollo puede ir preparando el resto de planes
detallados posteriormente durante el Sprint.
Un plan detallado es un elemento del Backlog de Producto (historias de usuario)
descompuesto en tareas que habrá que hacer con el fin crear dicho elemento. Cada
tarea puede contener estimaciones, dependencias y cualquier otra información
similar necesaria para su seguimiento.
No hay una regla específica sobre la documentación, almacenamiento, y la
presentación del Backlog del Sprint. Podrías emplear un tablón similar al que
aparece en la siguiente figura

Tablón de Sprint
Las notas adhesivas amarillas (post-its) son las tareas que se crean al descomponer
cada una de las historias de usuario (azules). Estas tareas (en amarillo) definen lo
que el equipo de desarrollo va a hacer para entregar cada elemento, y son

12
 13

responsables de su preparación. Algunas tareas se crean en la reunión de

Planificación del Sprint, y otros a lo largo de todo el Sprint.

El Backlog del Sprint está compuesto de:

1. El Objetivo del Sprint
2. Los artículos seleccionados del Backlog de Producto, que se entregarán a
través de la Sprint (en azul)
3. Un plan detallado para convertir los elementos seleccionados (historias o
historias de usuario) en un Incremento “Completo” del producto y realizar el
objetivo del Sprint

Puede observar en el Tablón del Sprint los tres elementos del Backlog del Sprint:
1) el Objetivo del Sprint
2) los elementos seleccionados del Backlog del Producto para completar en el
Sprint 3) el plan detallado.
El tablón cuenta además con otras características adicionales que permiten el
seguimiento de las tareas en las columnas “Pendiente“, “En Progreso” y
“Completado“.
En la imagen anterior se puede observar el mismo Sprint después de que el primer
elemento (Item#1) se haya completado. Observe cómo los ítems # 2 y # 3 están en
progreso. También se puede observar que se han añadido tareas adicionales a los
elementos situados en la parte baja del cuadro (ítem # 3 al # 5). Son el resultado de
la planificación detallada que se lleva a cabo durante el Sprint.

El Scrum diario
Durante el desarrollo del Sprint los miembros el Equipo de Desarrollo mantienen
una serie de reuniones diarias que se conocen como Scrum Diario. Estás reuniones

13
 14

tienen una duración máxima de 15 minutos, y son solo para los desarrolladores;
nadie más puede participar. Bueno, cualquiera puede “asistir” a la reunión pero en
“modo de silencio”.
Durante el Scrum Diario los desarrolladores responden a tres preguntas:
1. ¿Qué hice desde ayer?
2. ¿Qué voy a hacer hasta mañana?
3. ¿Qué obstáculos he encontrado o podría encontrar?
En las organizaciones que han adoptado la metodología Scrum. Normalmente,
estas reuniones se hacen cada día en el mismo sitio y a la misma hora.
Habitualmente, las Reuniones Diarias de Scrum se conducen por la mañana con el
fin de ayudar a establecer el contexto para el día de trabajo. Sin embargo, cuando
trabajas en una organización distribuida globalmente, la reunión puede ocurrir a una
hora establecida de común acuerdo entre los miembros del equipo. Las Reuniones
Diarias de Scrum se limitan a 15 minutos de duración para mantener la discusión
rápida e importante.
El equipo se reúne cada día para ponerse al tanto rápidamente. Esta reunión es
considerada como una de las partes más sobresalientes del marco Scrum.
Beneficios de mantener la Reunión Diaria de Scrum:
• Permite al equipo estar en sincronía con cómo están ocurriendo las cosas
• Permite hacer correcciones en el sprint
• Construye confianza entre los miembros del equipo
• Estimula la planificación personal
• Genera gran visibilidad del progreso
• Permite que el equipo se auto gestione
Es obligatorio para todos los miembros del equipo participar en la Reunión Diaria de
Scrum. Se espera que el Propietario del Producto y el Scrum Master también
participen en estas reuniones. Se requiere que el Scrum Master solamente capte
los impedimentos que se reconozcan en la reunión Diaria de Scrum, y que no trate
de discutirlos o resolverlos en la reunión. Este evento se considera un círculo de
retroalimentación “centrado en el trabajo”, que los miembros del equipo utilizan para
comunicar y evaluar el progreso e identificar impedimentos. No se intenta que la
reunión sea una herramienta de reporte de gestión o de estatus.
Dentro del equipo, diariamente se recalca el compromiso y la responsabilidad. Estas
reuniones son dirigidas por el equipo y para el equipo. Las reuniones ayudan al
grupo a estar enfocado en el objetivo y también ayuda a la auto-organización y
colaboración. El tiempo ocupado en estas reuniones puede considerarse como

14
 15

tiempo bien invertido cuando finalmente se realiza el entregable del proyecto. Estas
reuniones ayudan al equipo a darse cuenta de qué hizo cada persona ayer, y qué
planea lograr hoy. El Scrum Diario ayuda a mejorar el compromiso de cada persona
con el equipo. Crea un equipo auto-organizado con ambiente positivo

Reunión Revisión del sprint (Sprint Review) 4 horas máximo

• Se lleva a cabo al final del Sprint, para inspeccionar el incremento y adaptar,
si es necesario, el Product Backlog
• El Equipo Scrum y las partes interesadas colaboran durante la revisión de lo
que se hizo en el Sprint.
• Durante el Sprint, los asistentes trabajan en las próximas cosas que se
podrían hacer. Esta es una reunión informal, y la presentación del incremento
está destinada a obtener retroalimentación y fomentar la colaboración La
revisión de Sprint incluye los siguientes elementos:
• Los asistentes son el Equipo Scrum y los interesados clave invitados por el
Dueño de Producto
• El propietario del producto identifica lo que se ha "hecho" y lo que no se ha
"hecho“
• El equipo de desarrollo discute lo que anduvo bien durante el Sprint, qué
problemas hubo y cómo se resolvieron
• El resultado de la revisión del Sprint es un Product Backlog revisado que
define los ítems del Product Backlog de mayor valor o probables para el
siguiente Sprint. El Product Backlog también se puede ajustar en general
para satisfacer las nuevas oportunidades.

Retrospectiva (Sprint Retrospective). 4 horas máximas

• El propósito de la retrospectiva de Sprint es:
• Revisar cómo fue el último Sprint en lo que respecta a las personas,
relaciones, procesos y herramientas;
• Identificar y ordenar los temas principales que salieron bien y las potenciales
mejoras
• Crear un plan para la implementación de mejoras con respecto a cómo el
Equipo Scrum hace su trabajo.

15