Metodologı́a Scrum

Dirección de proyectos industriales e innovación tecnológica (201996)

Máster Universitario en Ingenierı́a Industrial
Curso 2019/20

Material de apoyo para su puesta en práctica

13 de noviembre de 2019

Metodologı́as ágiles
En un entorno cambiante, en que los tiempos de desarrollo se acortan, las metodologı́as
ágiles se han convertido en una alternativa atractiva. La metodologı́a ágil se centra en
la interacción, la comunicación y la reducción de elementos intermedios. Se acortan los
tiempos, sin desatender la calidad del entregable. Su factor clave, para que un proyecto
consiga finalizar de forma correcta, reside en el reconocimiento de las personas como principal
valor en el ciclo de vida de un proyecto. A diferencia de las metodologı́as tradicionales, las
metodologı́as ágiles son más adecuadas en entornos con una incertidumbre creciente.

Caracterı́sticas
Los atributos más destacables de las metodologı́as ágiles son los siguientes:

1. Gran capacidad de respuesta ante los cambios, que no se entienden como un problema
sino como algo necesario para que el producto sea mejor y satisfaga al cliente. Los
cambios formarán parte del proceso de desarrollo.

2. Las entregas no se hacen al final sino que se hacen pequeñas entregas. Estas entregas
permiten al cliente valorar el producto, además de ir trabajando con algunas funcio-
nalidades.

3. Los ciclos cortos de entrega ayudarán a disminuir los riesgos, sobre todo al principio
del proyecto.

4. Se trabaja en equipo, cliente y desarrolladores, mediante una comunicación casi diaria,

para evitar errores y documentación innecesaria.

1
 5. Eliminar el trabajo que no sea necesario y que realmente no aporta valor.

6. Buscar la mejor técnica y el mejor diseño para conseguir productos de calidad.

7. Mejorar los procesos y al equipo que realiza el desarrollo.

El desarrollo ágil se sustenta en los siguientes aspectos:

1. Se basa en el control empı́rico, en que se intuye la presencia de cambios en el contexto

del proyecto; por tanto, el control del proyecto se basará en controlar los resultados
obtenidos y, en función de estos, concebir las adaptaciones necesarias (ciclo PDCA).1

2. Las fases se plantean conforme a los objetivos del producto, definidas para cortos
perı́odos de tiempo , y en los que se hacen demostraciones del producto a los clientes.
Ası́ resulta más fácil realizar los cambios pertinentes.

3. El proceso no necesita excesivo control.

4. El cliente es parte del proyecto.

5. Todo el equipo participa en todas las fases del proyecto.

6. Hay menos roles.

7. Se incita una retrospectiva durante todo el proyecto.

Según el manifiesto Ágil, deben prevalecer las personas y sus interacciones frente a los
procesos y las herramientas, lo que funciona frente a una documentación exhaustiva, la cola-
boración con el cliente frente a una negociación contractual, y la respuesta al cambio frente
a un seguimiento rı́gido del plan previsto. Algunas de las metodologı́as ágiles más extendidas
comprenden Extreme Programming, Test Drive Development, Agile Project Management, y
Scrum.

Metodologı́a Scrum
La metodologı́a Scrum, ideada por Ikujiro Nonaka e Hirotaka Takeuchi a principios de
los años 80, comporta una nueva forma de gestionar proyectos, en la que la agilidad, la fle-
xibilidad y la incertidumbre son los elementos principales. Esta metodologı́a se fundamenta
en la idea de creación de ciclos breves en el desarrollo del proyecto, que comúnmente se
denominan iteraciones o Sprints. Para gestionar estas iteraciones se organizan reuniones
diarias, ingredientes fundamentales de la metodologı́a.

Componentes de la metodologı́a Scrum

Reuniones.

Roles.

Elementos.
1
PDCA o Planificar, Hacer, Verificar, Actuar; en inglés Plan, Do, Check, Act.

2
 Reuniones
1.a reunión Planificación del Backlog . Se describen en un documento los requisitos del proyecto,
ordenados por prioridad. Se define también la planificación del sprint 0 , en la que se
decidirán los objetivos y el trabajo que ha de realizarse para esa interacción; de esta
reunión se obtendrá un sprint backlog , una lista de tareas que conforman el objetivo
del sprint.

2.a reunión Seguimiento del sprint. En esta fase se organizan reuniones diarias, a fin de evaluar
el avance de las tareas, respondiendo a estas cuestiones:

• ¿Qué trabajo se realizó desde la última reunión?

• ¿Qué trabajo se hará hasta una nueva reunión?
• ¿Qué inconvenientes han surgido y qué contratiempos han de solventarse para
poder continuar?

3.a reunión Revisión del sprint. Cuando se finaliza el sprint se realizará una revisión del in-
cremento que se ha generado. Se presentarán los resultados finales y una demo o
versión, esto ayudará a mejorar el feedback con el cliente.

Roles
Cerdos Personas comprometidas con el proyecto.

• Product Owner . Quien toma las decisiones, la que realmente conoce el negocio
del cliente y su visión del producto. Se encarga de escribir las ideas del cliente,
las ordena por prioridad y las coloca en el Product Backlog.
• Scrum Master . Encargado de comprobar que el modelo y la metodologı́a fun-
cionan. Eliminará todos los inconvenientes que hagan que el proceso no fluya e
interactuará con el cliente y con los gestores.
• Equipo de desarrollo. Suele ser un equipo pequeño, entre 5 y 9 personas, tienen
autoridad para organizar y tomar decisiones en pro del objetivo. Se involucran
en la estimación del esfuerzo de las tareas del Backlog.

Gallinas Aunque no son parte directa del proyecto, es necesario que revisen y planifiquen cada
sprint.

• Usuarios. Destinatarios finales del producto.

• Stakeholders. Las personas a las que el proyecto les producirá un beneficio.
Participan en las revisiones del sprint.
• Managers. Toman las decisiones finales participando en la selección de los ob-
jetivos y de los requisitos.

Elementos
Product Backlog . Lista de necesidades del cliente.

Sprint Backlog . Lista de tareas que se realizan en un sprint.

Incremento. Parte añadida o desarrollada en un sprint, es un parte terminada y

totalmente operativa.

3
Product Backlog

Inventario en el que se almacenan todas las funcionalidades o requisitos en forma de

lista priorizada. Estos requisitos serán los que tendrá el producto o los que irá adquiriendo
en sucesivas iteraciones. La lista será gestionada y creada por el cliente con la ayuda del
Scrum Master, quien indicará el coste estimado para completar un requisito, y además
contendrá todo lo que aporte un valor final al producto. Las tres caracterı́sticas principales
de esta lista de objetivos serán:

1. Contendrá los objetivos del producto; se suele usar para expresar las historias de
usuario; estas son las descripciones de las funcionalidades que va a tener el producto.
Estas historias de usuario serán el resultado de la colaboración entre el cliente y el
equipo, e irán evolucionando durante toda la vida del proyecto. Un posible formato
de historia de usuario se ilustra en la figura 1.

Figura 1: Ejemplo de formato de tarjeta de historia de usuario.

2. En cada objetivo se indicará el valor que le da el cliente y el coste estimado; de esta

manera, se realiza la lista, priorizando por valor y coste.

3. En la lista se tendrán que indicar las posibles iteraciones y las entregas (releases) que
se han indicado al cliente.

4. La lista ha de incluir los posibles riesgos e incluir las tareas necesarias para solventarlos.

Es imprescindible que antes de empezar el primer sprint se definan cuáles van a ser los
objetivos del producto y tener la lista de los requisitos ya definida. No es necesario que sea
muy detallada, simplemente deberá contener los requisitos principales para que el equipo
pueda trabajar. Los requisitos secundarios aparecerán a medida que se va desarrollando el
proyecto. Una vez definidos los requisitos se tendrá que acordar cuándo se tiene que entender
un objetivo como terminado o completado. Se entiende que un producto está completado
si:

Se asegura que puede realizarse un entregable para realizar una demostración de los
requisitos y ver que se han cumplido.

4
 Se incluye todo lo necesario para mostrar que se está realizando el producto que el
cliente desea.

Como complemento a la definición de completado, deberı́a vincularse una condición de

aceptación o no aceptación a cada objetivo en el mismo momento en el que se crea la lista.
En la metodologı́a Scrum la preferencia por generar documentación en todo momento es
menos estricta. Se antoja más eficaz mantener una comunicación directa con el equipo, por
eso se usa como herramienta el Backlog. Con objeto de confeccionar la lista, es conveniente
que incluya información referida a:

Identificador para la funcionalidad.

Descripción de la funcionalidad.

Sistema de priorización u orden.

Estimación del coste temporal.

Sprint Backlog

Lista de tareas que elabora el equipo durante la planificación de un sprint. Se asignan las
tareas a cada persona y el tiempo que queda para terminarlas. De esta manera el proyecto
se descompone en unidades más pequeñas y se puede determinar o ver en qué tareas no se
está avanzando, y, de algún modo, intentar eliminar el problema.

Figura 2: Ejemplo de formato de Sprint Backlog.

Es una lista ordenada por prioridades para el cliente (ver figura 2). Puede haber depen-
dencias entre una tarea y otra, por tanto habrá que diferenciarlas de alguna manera. Todas
las tareas tienen que tener un coste semejante, comprendido entre 4 y 16 horas.
Generalmente, las tareas a completar se suelen gestionar mediante el Scrum Task-
board ; a cada objetivo se le asignan las tareas necesarias para llevarlo a cabo, se usan
post-its que se van moviendo de una columna a otra según cambia su estado (ver figura
3). Debe incluirse una lista de tareas, la persona responsable de cada tarea, el estado en
que esta se encuentra y el tiempo que queda por terminarla. Igualmente, debe permitir la
consulta diaria del equipo, ası́ como tener una referencia diaria del tiempo que resta a cada
tarea.

5
 Figura 3: Ejemplo de Scrum Taskboard.

Incremento

Representa los requisitos que se han completado en una iteración y que son perfectamente
operativos. Según los resultados que se obtengan, el cliente puede introducir los cambios
necesarios y replantear el proyecto.

Fases de un proyecto con la metodologı́a Scrum

1. Preparación del proyecto.

2. Planificación del sprint.

3. Desarrollo del sprint.

4. Revisión del sprint.

5. Retrospectiva del sprint.

Preparación del proyecto

Conocida como Sprint 0 , es la fase inicial en la que se intenta comprender el caso de
negocio con la finalidad de tomar decisiones que agreguen valor al producto. Durante esta
fase se cometen bastantes inexactitudes con las estimaciones, algo lógico, debido a que se
hacen a alto nivel; por tanto, es aconsejable no perder tiempo en buscar las estimaciones
exactas, es mejor invertir ese tiempo en el desarrollo del producto. De esta manera, el Backlog
del producto usará como unidad de tiempo los ((dı́as)). Las tareas que han de realizarse en
el sprint 0 comprenden:

6
 Definición del proyecto. Se deberı́a indicar de forma clara el propósito del proyecto,
no es necesario entrar en detalle pero sı́ que todo el equipo sea capaz de entender cuáles
son las necesidades del producto y del cliente.

Definición de ((terminado)). Marcará el punto en el que se va a considerar que la

tarea está terminada.

Definición del Backlog inicial. Se comienza la creación del Backlog del producto
para que el sprint siguiente contenga elementos de la lista suficientes para comenzar
a trabajar. Esta lista de elementos será marcada por el Product Owner, quien se res-
ponsabilizará de priorizar las funcionalidades que, al desarrollarlas e implementarlas,
satisfagan las especificaciones, consiguiendo además que su beneficio supere a su coste.

Definición de los entregables. Una vez que se tiene el Backlog con las funcionali-
dades, es necesario establecer criterios para hacer pequeñas entregas ((entregables)) del
producto, y ası́ obtener su valor y un feedback temprano.

El plan de entregables puede sufrir modificaciones, debidas a la aparición de nuevas

funcionalidades o a un replanteamiento del entregable. Por otro lado, estará sujeto a unas
determinadas condiciones establecidas por el equipo de trabajo, como el tiempo para un
entregable, la estimación inicial y la selección del Backlog del producto. A fin de constituir
el equipo, se organiza una reunión inicial con todos los roles del equipo, en función de la
dimensión del proyecto, las revisiones del Backlog, ası́ como la estructura del equipo y el
horario para establecer reuniones de control y seguimiento.

Estimación del Backlog

Previo a la primera reunión de planificación, el equipo tiene que conocer cuál va a ser
su velocidad inicial y su factor de dedicación. Para poder realizar las estimaciones,
primeramente hay que decidir qué historias de usuario incluir en la pila del sprint. La forma
en la que se podrá decidir qué historias de usuario introducir puede efectuarse mediante dos
técnicas:

1. De forma aproximada. El equipo debate el número de historias de usuario a intro-

ducir hasta llegar a un acuerdo. Suele funcionar de forma correcta si los sprints son
cortos.

2. Realizando cálculos de velocidad. Esta técnica se realiza en dos pasos:

Seleccionar la velocidad estimada.

Calcular el número de historias de usuario que se pueden añadir sin
sobrepasar la velocidad estimada.

La manera más adecuada de estimar la velocidad es revisar el historial del equipo;

de esta forma, basándose en sprints anteriores se podrá intuir cierta similitud. Para
poder realizar esta técnica, es necesario que los equipos tengan un historial, que su-
puestamente harán los próximos sprints de la misma manera, con el mismo tamaño
del equipo y las mismas condiciones de trabajo. La técnica se conoce como ((el tiempo
que hizo ayer)). Otra forma de hacerlo es mediante el cálculo de recursos, esto es, se
calcula el número de dı́as/hombre disponible; este es un valor poco realista porque
influyen factores externos, de ahı́ que suela usarse el factor de dedicación. La forma

7
 más adecuada para determinar un factor de dedicación razonable es el estado de los
últimos sprints. De este modo, la velocidad estimada (VE) asciende a

dı́as/hombre disponibles en el presente sprint × factor de dedicación en % = VE,

donde el factor de dedicación obedece a

velocidad real del último sprint

factor de dedicación en % = ,
dı́as/hombre del último sprint
en que la velocidad real comprende la suma de las estimaciones iniciales (número
de historias de usuario) que se completaron en el último sprint.
Si el equipo fuese nuevo, se puede valorar el factor de dedicación de otros equipos con
los que compararse, o, si no fuere el caso, se establecerı́a un valor aproximado por
defecto para empezar. El factor de dedicación que suele emplearse es de 70 %.

Planificación de un sprint
Denominado también Sprint Planning Meeting , tiene como finalidad realizar una
reunión, en la que participarán el Product Owner, el Scrum Master y el equipo, con la
intención de seleccionar de la lista Backlog del producto las funcionalidades sobre las que
se va a trabajar, y que darán valor al producto. Antes de comenzar la reunión, el Product
Owner tendrá que preparar el Backlog. La reunión se realiza con un timebox 2 de ocho
horas, que se divide en dos partes de cuatro horas.

Primera parte de la reunión (4 horas).

• El equipo selecciona los ı́tems para transformarlos en entregables.

• El equipo hace sugerencias, pero es el Product Owner quien decidirá si formarán
parte del sprint.
• El equipo seleccionará el elemento a implementar, de los seleccionados por el
Product Owner para ese sprint.

Segunda parte de la reunión (4 horas).

• El equipo hará las preguntas necesarias que tengan sobre el Product Backlog al
Product Owner.
• El equipo se encargará de encontrar la solución adecuada para transformar la
parte seleccionada de una funcionalidad en un entregable.

El resultado de la segunda parte de la reunión es una lista denominada Sprint Backlog

con las tareas, las estimaciones y las asignaciones de trabajo a los miembros del equipo para
poder empezar a desarrollar la funcionalidad. Las caracterı́sticas del Backlog del producto
serán las siguientes:
2
La técnica del timebox consiste en fijar el tiempo máximo para conseguir unos objetivos, tomar una
decisión o realizar unas tareas, y hacer lo mejor que se pueda en ese intervalo. De esta manera, en lugar
de ponerse a trabajar en algo hasta que esté hecho, de antemano se acuerda que solo se dedica un tiempo
limitado. La consciencia de esta limitación temporal favorece la priorización de objetivos/tareas y fuerza la
toma de decisiones.

8
 La estimación de cada tarea será entre 4 y 16 horas; si son mayores a este valor, se
descompondrán.

Las tareas del sprint deben

Probablemente derivarse
podrías de la
usar una pizarra, peronecesidad de Siun
es un desperdicio. requerimiento del Backlog
es posible,
guarda las pizarras para garabatos de diseño y usa las paredes que no sean
del producto. pizarras para los tablones de tareas.
NOTA – Si usas post-it para las tareas, no olvides pegarlos usando cinta
El progreso de las tareas,
adhesiva, en lastodos
o encontrarás que se mide
tus pos-it la velocidad
en un montoncito en el sueloycualquier
el progreso del sprint, con
día
relación a las horas, se realizará mediante gráficos Burndown Chart.
Cómo funciona el tablón de tareas

Figura 4: Ejemplo de Scrum Taskboard detallado.

El soporte en el que se presenta el Sprint Backlog puede ser un Scrum Taskboard ,

donde en una pizarra se crea una tabla con la siguiente información (ver figura 4):

1.a fila. Tareas que no se han planificado, pero que son urgentes (errores, cambios
importantes decididos por el cliente, etc.).

2.a fila. Mejora continua. Se ponen las tareas de retrospectivas anteriores que se
quieren analizar en el sprint.

Columna de tareas no empezadas. Se pondrán todas las tareas que se han espe-
cificado en la reunión del Sprint planning.

Columna de tareas en curso. Tareas que se están realizando; deberı́an ser mı́nimas
y resueltas de arriba hacia abajo.

Columna de tareas completadas. Tareas realizadas completamente.

Impedimentos. Lista de obstáculos que impedirán continuar de forma adecuada el

proyecto. Hay que indicar quién será el responsable de solucionarlos.

Retrospectiva. Sirve para anotar qué partes están bien durante el sprint y cuáles
mal. Se reflejan con un ‘+’ y un ‘−’.

9
Estimación del sprint
Realizar las estimaciones, para los ı́tems seleccionados, es una tarea que deberá involucrar
a todos los miembros del equipo. Para poder hacer una estimación, y que los miembros del
equipo no estén condicionados por la estimación de los compañeros, se usará la técnica de
Planning Poker .

1. Cada miembro del equipo dispondrá de una baraja de 13 cartas (ver figura 5).
2. Se propone una historia de usuario, el miembro del equipo selecciona una carta y la
coloca boca abajo. Esta carta representará su estimación para la historia propuesta.
3. Cuando todos los miembros han seleccionado su carta, se da la vuelta a todas las
cartas al mismo tiempo.
4. Se comprueban las estimaciones, y si hay muchas discrepancias se discute sobre esas
diferencias y se ponen en común las ideas sobre la naturaleza del trabajo. Este proceso
se repetirá hasta que las estimaciones sean similares o aproximadas.
5. El tiempo estimado es para el desarrollo de toda la historia, por ese motivo la secuencia
de números no es lineal y, por ejemplo, hay un salto entre 40 y 100. De esta manera
se evitan sensaciones falsas para estimaciones grandes.

Figura 5: Baraja de Planning Poker.

Si las estimaciones fuesen más detalladas, las historias se podrı́an dividir en historias
más pequeñas. Hay 3 cartas especiales:

O Esta historia de usuario ya está hecha o requiere poco tiempo de trabajo.

? Se desconoce cuánto puede ser la estimación.
K Realizar un descanso para retomar después la estimación.

Mantenimiento del Backlog del sprint

El equipo tiene que mantener actualizado el Backlog del sprint para poder tener feedback
y tomar cualquier decisión de manera rápida. Además, se requiere también que el gráfico
del Burndown del sprint también esté actualizado.

10
Diagrama de Burndown
El diagrama de Burndown sirve para saber el tiempo que falta para completar el tra-
bajo. Normalmente se utiliza para saber cuánto falta para terminar las historias de usuario
comprometidas en un sprint. En la práctica es un diagrama de dos ejes: en el eje de abscisas
se representa el tiempo, en dı́as, de duración del sprint, o iteración, en el eje de ordenadas
la cantidad de trabajo comprometida con el cliente durante el sprint, en las unidades que
se hayan acordado (por ejemplo, dı́as ideales). Los diagramas de Burndown resultan muy
valiosos por tres motivos:

1. Posibilitan responder a la pregunta clave: ¿cuánto falta para terminar?

2. Son visuales, resulta muy sencillo examinar un diagrama de Burndown.

3. Su mantenimiento es mı́nimo; actualizar el diagrama de Burndown resulta tan simple

como sumar el número de dı́as ideales que restan tras haber finalizado el dı́a anterior
y trazar una lı́nea.

El hecho de emplear un diagrama de Burndown obliga a seguir ciertas rutinas o prácticas

ágiles, que facilitan la planificación de un proyecto, como dividir el trabajo en iteraciones, o
ciclos de desarrollo, cuantificar lo que hay que hacer, esto es, dividir el trabajo en tareas y
estimar su duración, y, finalmente, efectuar un seguimiento diario del progreso del proyecto.
Antes de implementar un diagrama Burndown, como prerrequisitos:

Debe consensuarse con el cliente la división del trabajo en iteraciones; una iteración
es un ciclo de desarrollo en el que el equipos se compromete a desarrollar cierta fun-
cionalidad.

Deben estimarse las tareas (duración), que se desarrollarán en dı́as ideales, con alguna
técnica (planning poker, juicio de expertos, sacando la bola de cristal, diciendo un
número al azar, etc.).

Debe acordarse la funcionalidad que se desarrollará, de acuerdo con el equipo que vaya
a trabajar en el proyecto y la duración del sprint.

Por ejemplo, si en el proyecto van a trabajar 3 personas durante 15 dı́as, es factible

comprometerse a desarrollar una funcionalidad equivalente a 45 dı́as ideales. Con esa in-
formación ya puede dibujarse el diagrama de Burndown.3 Este diagrama debe permanecer
bien visible para todos los miembros del equipo, de forma que todos ellos conozcan el estado
actual del proyecto.
Generar un diagrama de Burndown es tan sencillo como introducir el número de dı́as
ideales, la duración de la iteración y ponerle un tı́tulo. La herramienta que se emplee
creará un diagrama con dos ejes y una lı́nea recta que mostrará la velocidad ideal de desa-
rrollo. Si el diagrama lleva por tı́tulo el objetivo general de la iteración, ası́ como la fecha de
entrega, los miembros del equipo estarán más enfocados y cualquiera entenderá el contexto
del diagrama. A partir de ahı́, lo único que ha de hacerse cada dı́a es reunir al equipo, para
que actualice el estado de las tareas, indicando cuánto queda para completar las tareas en
curso, se suma el total de dı́as y se actualiza la gráfica. Siempre que se vaya por debajo
de la lı́nea quiere decir que se llega a tiempo, si se va por encima de la lı́nea puede querer
3
En la página web http://www.burndowngenerator.com/ resulta inmediato dibujar un diagrama de Burn-
down.

11
decir varias cosas: una mala estimación, la presencia de algún impedimento, alguna baja,
que el equipo no está a la altura, muchos cambios en los requisitos, etc. En cualquier caso,
lo interesante de mantener el diagrama de Burndown actualizado es que permite reaccionar
pronto y poner solución a cualquier problema que haya surgido. Una vez termine la iteración,
se repite el proceso, pero con una gran ventaja. Ahora ya se dispone de una referencia de la
velocidad del equipo o cierta experiencia a la hora de estimar tiempos, acometer cambios,
etc., aparte de adecuar mejor la cantidad de funcionalidad que se puede desarrollar por
iteración, lo que contribuye a una mayor productividad.
A modo de ejemplo, lo que muestra la figura 6 es que se han escogido demasiados ı́tems
y deberı́a analizarse qué ı́tems del Backlog habrı́a que eliminar en esta fase.

Figura 6: Ejemplo de diagrama de Burndown.

Desarrollo del sprint

En los sprints el equipo trabaja para conseguir un incremento del producto, que será, en
último término, beneficioso para el Product Owner y los Stakeholders (grupos de interés).
El tiempo más conveniente está comprendido entre 2 y 4 semanas, o 30 dı́as consecutivos
como máximo. Estos intervalos de tiempo son los que se consideran más apropiados para
que los Stakeholders no pierdan el interés.

Reuniones del sprint

Durante la ejecución del sprint se realizarán cuatro reuniones:

Reunión de Planificación (Sprint Planning Meeting ).

Reunión diaria (Scrum Daily Meeting ).

Reunión de revisión del sprint (Sprint Review Meeting ).

Reunión de retrospectiva (Sprint Retrospective Meeting ).

Sprint Planning Meeting

Se definirán qué tareas se tienen que realizar y cuáles son los objetivos. Una vez definidos,
el equipo comienza su desarrollo, pero teniendo en cuenta una serie de normas:

12
 El equipo puede realizar consultas de agenda fuera del sprint.

No se permite a nadie gobernar al equipo durante el sprint. El equipo se autogestionará.

Si durante el desarrollo del sprint se advierte que no puede realizarse, porque no es

viable, se puede concertar una nueva planificación para iniciar un nuevo sprint.

Si el equipo no puede comprometerse a cumplir todo el Backlog, se consultará al

Producto Owner para decidir qué ı́tems eliminar.

Si el equipo, durante el sprint , se ve capaz de realizar más ı́tems del Backlog, que
el indicado inicialmente, se consultará también al Product Owner qué ı́tems podrán
añadirse.

Con estos antecedentes, a lo largo del desarrollo, se concertarán reuniones diarias.

Scrum Daily Meeting

En esta reunión los componentes del equipo comparten información relativa al desarrollo
y colaborarán para hacer las adaptaciones necesarias, aumentando ası́ su productividad. En
esta reunión se tendrá como referencia el Backlog del sprint y el gráfico burn-down con la
información de la reunión anterior, ası́ como qué tareas hizo cada miembro del equipo. La
reunión no podrá consumir más de 15 minutos y se responderá a tres preguntas básicas:

¿Qué se ha hecho de nuevo respecto a la última reunión diaria?

¿Qué será lo siguiente a realizar?

¿Qué problemas han surgido para realizarlos?

Esta reunión servirá como instrumento de apoyo, con la lista de tareas del sprint ac-
tualizada y con el esfuerzo pendiente de cada tarea. También se tendrá un gráfico con las
tareas pendientes en la iteración.

Sprint Review Meeting

En esta reunión los desarrolladores presentan el entregable que han implementado, y los
gestores, los clientes, los usuarios y el Product Owner analizan esa entrega y escuchan al
equipo sobre los problemas que han tenido durante el proceso. Esta reunión servirá para
tomar decisiones que ayudan a escoger el camino más adecuado a fin de alcanzar las metas.
Las caracterı́sticas de esta reunión se limitan a:

Duración máxima: 4 horas.

Se presenta el producto ((completado)), entendiendo como tal la definición acordada

con el Product Owner y los Stakeholders.

Si la funcionalidad no está completa no se puede presentar.

Artefactos que no son funcionalidades, no se presentan para no equivocar a los Sta-

keholders.

Se presenta la funcionalidad en equipos que pertenezcan a los desarrolladores. Siempre

se hará desde un servidor lo más parecido posible al de producción.

13
 El Sprint Review transcurre siguiendo el siguiente proceso:

El Scrum Master determina cuántas personas asistirán al Sprint Review Meeting.

Al final de la reunión, el Scrum Master anuncia al Product Owner y a los Stakeholders

la convocatoria de la próxima reunión.

Estas reuniones son beneficiosas para todos, puesto que se comprueba si el equipo ha
cumplido las expectativas y si el equipo ha entendido al cliente. Se suscita entonces una
satisfacción personal al comprobar que la entrega está funcionando.

Sprint Retrospective Meeting

En esta reunión el equipo debatirá temas relacionados con el sprint recientemente fina-
lizado y los cambios que se podrı́an introducir para mejorar el siguiente sprint, con objeto
de que sea más productivo (ver figura 7). En general, será el Scrum Master quien convoque
esta reunión y tendrá una duración máxima de 3 horas. Las caracterı́sticas generales de la
reunión serán:

Asistirán el Scrum Master, el equipo de trabajo y el Product Owner.

La reunión girará en torno a dos preguntas básicas: ¿qué ha ido bien durante el último
sprint? ¿Qué será mejorado para el siguiente sprint?

El Scrum Master toma nota de las respuestas del equipo en un formulario.

El equipo hablará de las posibles mejoras que se puedan realizar, indicando cuáles
tendrán mayor preferencia.

El Scrum Master ayudará a canalizar las mejores vı́as de apoyo, conforme a las mejoras
indicadas por el equipo.

Si hay puntos que merezcan especial atención, se añadirán para el siguiente sprint,
considerándolos como un Backlog no funcional, si bien de alta prioridad.

Figura 7: Ejemplo de Retrospective Meeting.

14
Diagrama detallado de las fases de la metodologı́a Scrum
La figura 8 ilustra, a modo de guı́a resumen, el proceso de creación de un proyecto, de
acuerdo con la metodologı́a Scrum, en el que se van abordando las diferentes fases cı́clica-
mente, hasta completar todas las tareas del Backlog.

Figura 8: Diagrama de fases de un proyecto Scrum.

15