Unidad didáctica 2

Scrum en el día a día, los sprints y sus

reuniones
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

Índice
Introducción y objetivos

1. Periodos de trabajo
1.1. El proceso Scrum
1.2. Timeboxing
1.2.1. Introducción
1.2.2. Duración
1.2.3. Contenido
1.2.4. Beneficios del timeboxing
1.3. Otras técnicas de mejora de la productividad

2. Sprints: las iteraciones incrementales

2.1. Introducción
2.2. Conceptos básicos en un Sprint
2.3. Duración del sprint
2.4. ¿Cómo se planifica un sprint?
2.5. En funcionamiento
2.6. Tips y consejos

3. Las reuniones de Scrum

3.1. Introducción
3.2. Daily Scrum
3.3. Sprint Planning
3.4. Sprint Review
3.5. Sprint Restrospective

Resumen

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

INTRODUCCIÓN Y OBJETIVOS
El desarrollo de proyectos mediante Scrum utiliza ciclos de trabajo cortos de
duración fija. Se trabaja a través de un conjunto de iteraciones que tienen un objetivo
claro: entregar un producto finalizado al finalizar la iteración.

En esta unidad veremos quién hace qué en ese ciclo corto, quién distribuye las tareas,
quién asigna el trabajo que se desarrollará en la iteración y quién se responsabiliza del
resultado a entregar al cliente, aunque lo importante en esta unidad es ver cómo se
gestiona la iteración. La auto-organización es clave para el éxito de un proyecto con
esta metodología ágil.

Los tres pilares de Scrum (transparencia, inspección y adaptación) se reflejan en la

forma de trabajar en cada una de las iteraciones, con reuniones diarias y la búsqueda
de aprendizajes y mejoras.

Dentro de la incertidumbre podemos crear momentos de certeza, claridad y foco, que

producen motivación y productividad.

Los objetivos de esta unidad son:

• Conocer cómo se trabaja en Scrum y cómo se mejora la productividad a través

de las actividades limitadas en el tiempo, así como los beneficios adicionales
de trabajar con bloques de tiempo.

• Entender lo que son los Sprints o ciclos iterativos e incrementales en los que
trabaja Scrum y qué se hace en cada Sprint. Familiarizarnos con la duración y
la acción correspondiente a ciclo con el objetivo de producir un incremento de
producto al final del Sprint.

• Comprender la importancia de hacer seguimiento y cómo hacerlo de forma

diaria sobre el proyecto a través del objetivo, los elementos elegidos y el plan
detallado.

• Descubrir cuáles son las diferentes reuniones que se realizan en Scrum, su

timeboxing, el objetivo de cada una de ellas y el beneficio para el equipo, el
cliente y la organización. En definitiva, conocer uno de los elementos
fundamentales de Scrum como son sus ceremonias o eventos.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

1. PERIODOS DE TRABAJO
1.1. EL PROCESO SCRUM
En Scrum, un proyecto se ejecuta en ciclos temporales cortos y de duración fija que
normalmente es de entre 2 y 4 semanas. Cada iteración o sprint tiene que
proporcionar un resultado completo, un incremento de producto final que sea
susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

Las actividades que se llevan a cabo en cada iteración o sprint de Scrum son las
siguientes:

-­‐ Planificación de la iteración.

-­‐ Ejecución de la iteración.
-­‐ Reunión diaria de sincronización del equipo.
-­‐ Demostración de los requisitos completados.
-­‐ Retrospectiva.
-­‐ Refinamiento de la lista de requisitos y cambios en el proyecto.
 

Una vez terminada la iteración o sprint empezaremos el siguiente, y así sucesivamente

hasta la entrega final del producto o finalización del proyecto.

Nota

Si la duración de los sprints es corta, de entre 2 y 4 semanas, debemos trabajar

con metodologías que nos permitan optimizar la productividad.

1.2. TIMEBOXING
1.2.1. INTRODUCCIÓN
En los entornos ágiles un concepto fundamental es el de bloques de tiempo (timebox).

Timebox se refiere a una cantidad predefinida y fija de tiempo que no puede

modificarse, durante la cual deberán llevarse a cabo las actividades planificadas.

Las iteraciones o sprints funcionan mediante timeboxing. También cabe destacar que
ciertas actividades de Scrum, como son las reuniones, utilizan el principio de timebox.

Los timebox o bloques de tiempo tienen dos características básicas sobre duración y
contenido.

1.2.2. DURACIÓN
Importante

Los timebox tienen una duración máxima predefinida.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

Esa duración es inamovible durante el sprint. Nunca extenderemos el timebox

previamente establecido simplemente porque no hayamos cumplido algún objetivo y
tengamos que terminar alguna cosa.

Se convierte en clave terminarlo todo dentro del timebox, y si no es posible,

priorizaremos y dejaremos por hacer aquellas actividades de menor importancia y
valor para el cliente.

Si bien cada timebox tiene un tiempo máximo, hay de dos tipos con respecto al tiempo
mínimo:

De duración fija:

-­‐ Algunos de los timebox están completamente fijos, no solo respecto a la

duración máxima, también respecto a la mínima.
-­‐ Si ya hemos hecho todo lo planificado y todavía tenemos algo de tiempo,
podemos: bien elegir nuevas actividades en base a las reglas definidas por el
marco de trabajo (por ejemplo, SCRUM) o, simplemente, tomarnos un tiempo
libre.
-­‐ Este tipo de timebox se utiliza para generar regularidad y se emplea
generalmente para grandes eventos.

De duración máxima:

-­‐ Existen timebox con una duración máxima, que no es extensible, pero no
cuentan una duración mínima.
-­‐ En este tipo de timebox, si ya hemos completado todas las actividades y
tenemos algo de tiempo, el timeboxse considerará cerrado y empezaremos un
nuevo.
-­‐ Se utiliza para maximizar la flexibilidad, junto con la regularidad, y se utiliza
generalmente para eventos más pequeños o aquellos que no pueden
incorporar actividades adicionales.

La duración de los timebox debe acordarse y prefijarse. Si bien somos libres de

cambiar la duración de dichos bloques en función de las lecciones aprendidas, no
deberíamos hacerlo en base a circunstancias puntuales.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

1.2.3. CONTENIDO
Importante

Los timebox tienen generalmente un conjunto predefinido y fijo de artículos a

completar.

Este contenido lo hemos definido por adelantado y no podemos cambiarlo. Podemos

aclararlo o refinarlo, pero no cambiarlo por completo.

Esta es la clave para ser productivos en los entornos ágiles. Por una parte, recoger los
cambios que se producen para siguientes timebox y, por otra, mantenernos centrados
durante el presente timebox.

Nota

La única excepción sería si el timebox fuera duración fija en lugar de duración

máxima, en cuyo caso podríamos añadir artículos adicionales una vez que
hubiéramos “completado” todos los predefinidos.

1.2.4. BENEFICIOS DEL TIMEBOXING

Las ventajas que el timeboxing aportan a la metodología Scrum son:

-­‐ Contribuyen a generar regularidad y disciplina y, en particular, ayudan a crear

soluciones potencialmente entregables.
-­‐ Aumenta la concentración de los miembros del equipo, especialmente en
situaciones en las que todo cambia constantemente.
-­‐ Ayudan al equipo a centrarse en aquello que genera valor y en las necesidades
del negocio. Debido a que la duración máxima siempre es fija no podemos
extender el tiempo necesario para terminar algo, en vez de eso, debemos tener
en cuenta el valor que genera cada actividad y dejar de hacer aquellas que
generan menos valor.

1.3. OTRAS TÉCNICAS DE MEJORA DE LA PRODUCTIVIDAD

Espacio de trabajo adecuado:

Siempre que sea posible trabajaremos en un espacio físico común para mejorar la
productividad. Este requisito hace referencia a que el equipo esté trabajando en la
misma localización física, en lugar de estar distribuido en los distintos departamentos
de la organización.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

Esta es sin duda una medida que contribuye a mejorar la relación entre los miembros
del equipo, y facilita su comunicación y colaboración.

Comunicación osmótica:  

Una de las consecuencias de que los miembros del equipo se encuentren en una
misma ubicación, no solo es la mejora de la conversación, sino también la
comunicación osmótica. Este tipo de comunicación aparece cuando los miembros del
equipo captan la información relevante como si fuera por ósmosis. Esto se produce
normalmente por estar en la misma habitación donde los miembros del equipo pueden
obtener información útil escuchando de “casualidad”, e implicarse y ayudarse los unos
a los otros si fuera necesario.

En la práctica, cuando una persona hace una pregunta, otros en la habitación pueden
sintonizar o desconectarse, contribuyendo a la discusión o continuando con su trabajo.

Maximizar las comunicaciones osmóticas es una buena práctica. La comunicación

osmótica se refiere a llevar la comunicación al máximo nivel.

Nos debe tomar menos de 30 segundos llevar nuestras dudas a los ojos u oídos de
quien puede resolvérnoslas, debemos sentarnos en el mismo cuarto o en cubículos
contiguos. Esta forma de comunicación nos permite conectarnos de forma más ágil a
las demás personas y abarca la posibilidad de que ambas personas se encuentren en
sintonía con sus ideas.

Los eventos de Scrum:

Una de los problemas del trabajo en equipo es la gestión de las reuniones. Bien sea
por la cantidad de reuniones, bien por la calidad de ellas, muchas veces se convierten
en una pérdida de tiempo y su consecuente desmotivación al no ser del todo
productivas.

En Scrum existen una serie de reuniones programadas o eventos que tratan de crear
regularidad y reducir al mínimo la necesidad de reuniones fuera de las definidas en
Scrum. Todas estas reuniones tienen una duración máxima (timebox) con el objetivo
de que estos eventos no se conviertan en eternos o que no nos lleven a ningún lado o
que sean una pérdida de tiempo.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

2. SPRINTS: LAS ITERACIONES INCREMENTALES

2.1. INTRODUCCIÓN

Los sprints son unos de los pilares sobre los que se basa Scrum. Recordemos que
los fundamentos de Scrum son los siguientes:

1. El desarrollo incremental de los requisitos del proyecto en bloques

temporales cortos y fijos (iteraciones de dos semanas y de hasta un mes
natural, si así se necesita).
2. La priorización de los requisitos en función del valor que se aporta al cliente
y del coste de desarrollo en cada iteración. El Product Owner es quien realiza
dicha priorización.
3. 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 Team se sincroniza diariamente y realiza las
adaptaciones necesarias.
4. La potenciación del Team. El equipo de Desarrollo se compromete a entregar
unos requisitos y para ello se le otorga la autoridad necesaria para organizar su
trabajo.
5. La sistematización de la colaboración y comunicación tanto entre el Team
como con el cliente.
6. El timeboxing de las actividades del proyecto, para ayudar a la toma de
decisiones y conseguir resultados.

El sprint es uno de los fundamentos de Scrum. Es un acontecimiento de tiempo

limitado (timebox), lo que significa que su duración está fijada cuando se inicia el
proyecto y es necesario evitar modificarla siempre que sea posible. Por lo general, los
sprints tienen una duración aproximada de dos a cuatro semanas.

Una vez iniciado el sprint, se define un objetivo para ese sprint y se seleccionan los
elementos que se realizarán durante el mismo (Sprint Backlog). Tanto el objetivo,
como esos elementos del Sprint Backlog, permanecerán invariables y no se podrán
cambiar.

Una de las recomendaciones es que la composición del Team o equipo de desarrollo

no cambie durante un sprint. Estas limitaciones que impone Scrum se han diseñado

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

para mejorar la concentración, la productividad y poder completar los elementos de

cada sprint.

¿Qué se desarrolla durante un Sprint?:

Partimos del Product Backlog o los elementos o características que va a tener el

proyecto, definidas en “historias de usuario”. Estos elementos o características
deberían poder completarse en un sprint, ya que así son mucho más fáciles de
gestionar.

• El Product Owner es quien debe tener actualizados y priorizados los elementos

del Product Backlog.
• Es el Team quien selecciona los artículos de la parte superior del Product
Backlog y genera el Sprint Backlog o elementos a desarrollar durante el
sprint.
• El objetivo es conseguir que los elementos seleccionados para ese sprint estén
"Completos" al 100% cuando el sprint termine y poder generar un Incremento.

2.2. CONCEPTOS BÁSICOS EN UN SPRINT

• Product Backlog:
El Backlog de Producto, también llamado Pila de Producto, es la principal
fuente de información sobre el producto en Scrum. Es una lista ordenada de
todos los elementos que podría necesitar el producto final, conocidos como
historias de usuario.

Es responsabilidad del Product Owner tener los elementos del Product Backlog
priorizados en función del ROI, el valor al cliente, costes...

El Product Backlog es dinámico, puede cambiar y mejorar y es visible a todo el

Team para que todos tengan una visión global del proyecto.

• Spring Backlog:
Es la lista de pendientes del sprint o el conjunto de tareas seleccionadas del
Product Backlog durante el sprint planning para el sprint actual, es decir, las
tareas necesarias para realizar un incremento de producto.

 
IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

El sprint backlog es una imagen en tiempo real del trabajo que se planea
realizar durante el sprint, es un plan que hace visible todo el trabajo que el
Team identifica como necesario para cumplir con el objetivo del sprint.

• Incrementos:
En un proyecto Scrum, el producto final se entrega después de un número
definido de iteraciones o sprints. En cada sprint se desarrolla un incremento,
que es una parte potencialmente entregable del producto final. Un incremento
es la suma de todos los elementos del Product Backlog completados hasta un
punto determinado del proyecto, que continuará creciendo tras cada Sprint
hasta que el proyecto concluya.

Un incremento es la suma de todos los elementos completados durante el

sprint actual y todos los sprints anteriores. Cada nuevo incremento, al final de
un Sprint, es una versión actualizada del incremento anterior, con nuevas
características y funcionalidades que van aportando un valor y que puede o no
entregarse al cliente, pero siempre debe ser potencialmente entregable.

• Definición de completo (DoD-Definition of Done):

Es importante llegar a un acuerdo sobre una definición de "completo" (DoD o

Definition of Done) al inicio del proyecto. No diremos que algo está "completo",
a menos que se ajuste a dicha definición.

Un elemento hecho al 99.999% no puede ser considerado como "completo", no

sería parte del incremento y por lo tanto no se mostraría al cliente durante la
Revisión del Sprint.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

Scrum se basa en un desarrollo iterativo e incremental por lo que no se espera

que una serie de historias de usuario estén completas para ejecutar las
pruebas. Las pruebas se ejecutan como parte misma de la definición de
“completo” de cada historia de usuario.

2.3. DURACIÓN DEL SPRINT

Normalmente las organizaciones trabajan con sprints de entre 2 y 4 semanas. La

elección de la duración se basa en una serie de circunstancias.

• Sprints demasiado largos:

Si trabajamos con sprints más largos existe la posibilidad de que los cambios
en las necesidades del cliente o en el mercado, y que no se han aplicado, sean
lo suficientemente "grandes y significativos" como para generar problemas,
aumentando la complejidad y el riesgo. Por lo tanto, debemos limitar los sprints
a no más de un mes de calendario.

• Sprints demasiado cortos:

Si trabajamos con sprints demasiado cortos no seremos capaces de producir

incrementos durante los sprints. Nuestro objetivo es ofrecer al cliente el
producto, o solución final, artículo por artículo, dentro de los límites de los
sprints. No queremos dividir la realización de un artículo del Product Backlog
entre varios sprints.

• Cantidad de adaptación o feedback necesarios:

Otro elemento que se emplea para decidir sobre la duración de los sprints es la
cantidad de adaptación o feedback necesario para el proyecto. Un proyecto con
sprints de dos semanas recibe casi el doble de retroalimentación y tiene el
doble de oportunidades de adaptarse que un proyecto con sprints de cuatro
semanas.

No está permitido cambiar la duración de los sprints "ad-hoc". Sin embargo, si

nos damos cuenta de que la duración de los sprints que hemos elegido no es
apropiada para el proyecto, podemos revisar y cambiar la duración para el
resto de los sprints. Podemos redefinir el resto de sprints en base a la

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

experiencia. No obstante, esperamos que no sea necesario realizar estos

cambios a menudo.

• Horas extras, márgenes de tiempo, etc.

Cuando gestionamos los sprints aparecen con frecuencia un par de cuestiones:

las horas extras, y los "márgenes" de tiempo.

o ¿Se pueden realizar horas extras para terminar todos los artículos
del Sprint Backlog?:
Digamos que no está prohibido, pero es sumamente desaconsejable.
Uno de los principios ágiles es mantener un ritmo constante, para
mantener la calidad del producto y el ánimo del equipo. Así pues, es
mejor evitar las horas extra.
o ¿Se puede establecer un margen extra de tiempo en los sprints
para asegurarnos de que podremos hacerlo todo?:
No debemos estar excesivamente preocupados por no poder hacerlo
todo. El sprint, como todos los eventos de Scrum, son de tiempo
limitado (timebox) y, por lo tanto, no debería extenderse ni siquiera un
día. Tampoco hay márgenes extra de tiempo al final de los sprint.

• Cancelar un sprint.

A pesar de que los sprint son timebox que no cambian, el Product Owner tiene
la autoridad para cancelar un sprint. Esto puede suceder cuando el objetivo de
sprint ha quedado obsoleto, bien por cambios en el Product Backlog, en la
estrategia, en el enfoque, etc. Cuando se cancela un sprint, los elementos que
están "completos" se revisan y se aceptan, y el resto de los artículos (aquellos
que no se han iniciado o están parcialmente completos) se añaden de nuevo al
Product Backlog para completarse en el futuro si fuera necesario.

2.4. ¿CÓMO SE PLANIFICA UN SPRINT?

La planificación del sprint (sprint planning) es el evento de Scrum diseñado para

asegurar que el equipo esté preparado para hacer un buen trabajo en cada iteración.

Cuando se planifica el sprint se define el alcance del sprint (sprint backlog), que estará
compuesto por:

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

1. Los distintos elementos seleccionados (historias de usuarios) del

product backlog.
2. El objetivo del sprint también se incluye en el sprint backlog. Debe
contener todos los elementos que se comprometen a completar al final
de ella. El objetivo debe ser un incremento de trabajo que se pueda
enviar, lo que significa que se puede demostrar al final del sprint. Debe
ser acordado por todo el equipo.
3. Las historias de usuarios se pueden dividir en tareas más pequeñas a
través de una planificación más detallada. Con esta planificación más
detallada se puede observar cómo las historias de usuarios se
transforman en un incremento de producto completo, consiguiendo el
objetivo del sprint. No es necesario desarrollar un plan detallado para
todos y cada uno de los elementos del sprint backlog durante la sesión
de planificación del sprint.

Nota

El sprint backlog estará listo al final de la planificación del sprint, y el team debe
ser capaz de describir los elementos que van a entregar a través del sprint y
cómo lo hará.

El sprint 0:

Técnicamente el sprint 0 es un paso previo al desarrollo de un proyecto scrum<. En

scrum no existe ninguna referencia al "sprint 0", y al respecto no hay diferencia entre el
sprint 1 y el resto de sprints. Empezamos a producir incrementos potencialmente
entregables tan pronto como se inicia el proyecto, y no pasamos por un tiempo (sprint)
de diseño o preparación.

¿Es realmente necesario un Sprint 0 en Scrum? No es obligatorio, sin embargo,

puede ser útil en dos situaciones:

-­‐ Nuestro proyecto scrum se va a desarrollar en un entorno muy cambiante en el

que vamos a tener que adaptarnos continuamente.
-­‐ Es la primera vez que trabajamos con un método ágil y necesitamos unas
bases claras.

Su importancia está en que nos permite establecer al menos 3 líneas maestras, con
las que trabajaremos durante todo el tiempo que dure el proyecto:

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

-­‐ Características del producto: En este Sprint 0 tenemos que recabar todo tipo
de información acerca del producto y las características que debe tener para su
lanzamiento. ¿Cómo? Trabajando activamente con el Product Owner.
-­‐ Estructura del Backlog: Fundamental durante esta fase. Definimos cómo
serán las historias de usuario y las dejamos preparadas para fases posteriores.
-­‐ Equipo y estructura: En una reunión con el equipo se definen funciones y se
perfila el método de trabajo que vamos a seguir.

2.5. EN FUNCIONAMIENTO
Para poner en marcha el sprint vamos a representar la información necesaria que esté
al alcance del scrum team.

Un ejemplo de presentación de documentación, almacenamiento y la presentación del

sprint backlog podría ser el siguiente tablón:

Objetivo del sprint Pendiente En progreso Completado

Item #1 t1.1
t1.2 t1.3 t1.4
t1.5 t1.6

Item #2 t2.1
t2.2 t2.3

Habilitar todas las partes

de la tienda online para
Item #3 t3.1
permitir que los usuarios
t3.2
puedan experimentar un
proceso de compra
completa. Esta hará que
otras características de la Item #4
página web sean más
significativas.
Item #5

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

En amarillo hemos puesto las tareas que se crean al descomponer cada una de las
historias de usuario (verde). Estas tareas definen lo que el equipo de desarrollo va a
hacer para entregar cada elemento, y son otros a lo largo de todo el sprint.

En el ejemplo, el sprint backlog está compuesto de:

1. El objetivo del sprint.

2. Los artículos seleccionados del product backlog.
3. Un plan detallado para convertir los elementos seleccionados (historias de
usuario) en un incremento "completo" del producto y realizar el objetivo del
Sprint.

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".

Objetivo del sprint Pendiente En progreso Completado

Item #1 t1.1
t1.2 t1.3 t1.4
t1.5 t1.6

Item #2 t2.3 t2.1 t2.2

Habilitar todas las partes

Item #3 t3.2
de la tienda online para t3.1
permitir que los usuarios t3.3 t3.4 t3.5
puedan experimentar un
proceso de compra
completa. Esta hará que Item #4 t4.1
otras características de la t4.2 t4.3
página web sean más
significativas.
Item #5

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

En esta tabla se muestra el mismo sprint después de que el primer elemento (Item 1)
se haya completado. Observa cómo los ítems 2 y 3 están en progreso. También
puedes 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.

Los elementos del sprint backlog guardan por lo general el mismo orden que tenían en
el product backlog, por lo tanto, el equipo de desarrollo debe trabajar primero en los
artículos de la parte alta de la tabla.

Más información

Un tablero Scrum no es solo para oficinas de desarrollo de software ágil, a

pesar de que es donde se originó Scrum. La estructura de Scrum se puede
utilizar en muchos entornos de producción, desde agencias de marketing hasta
empresas de construcción. De hecho, muchos de los mejores software de
gestión de proyectos incluyen algunas funcionalidades para seguir una
estructura de Scrum, incorporando elementos como los trabajos pendientes y
las funciones de planificación de iteraciones.

El software de Scrum está diseñado para facilitar la estructura de Scrum,

inclinada a la colaboración, la transparencia y la eficiencia entre los miembros
del equipo. De hecho, un “Scrum board” puede resultar beneficioso para casi
cualquier organización ya que facilita la comunicación, organiza la carga de
trabajo y ayuda a los miembros a planificar múltiples iteraciones.

2.6. TIPS Y CONSEJOS

1. Minimizar el número de requisitos en el que el equipo trabaja simultáneamente
(WIP, Work In Progress), con el fin de completar el máximo de requisitos en la
iteración. Para ello completaremos primero los requisitos que den más valor al
cliente.

2. No se puede cambiar/añadir los objetivos/requisitos del sprint en curso. En el

sprint planning se establecieron unos objetivos con unos requisitos concretos y
basó su plan y organización en ellos.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

3. Realizar el sprint planning con todo el equipo de Scrum Team (Product Owner,
Scrum Master y Team), el Product Backlog debe estar preparado, se deben
cumplir los objetivos de la reunión y respetar el timeboxing.

4. El Team debe tener una comprensión de los requisitos del cliente y del enfoque
para desarrollar el producto.

5. El Team debe funcionar como una sola unidad, aunque esté compuesto por
una heterogeneidad de perfiles, para alcanzar los objetivos del proyecto.

6. El Team debe estar comprometido. Asume el compromiso de construir lo que

considera lograble dentro del sprint, con base en las historias de usuario
priorizadas y ordenadas en el product backlog por el Product Owner.

3. LAS REUNIONES DE SCRUM

3.1. INTRODUCCIÓN
Para crear regularidad dentro del equipo y minimizar al máximo la necesidad de
reuniones innecesarias existen unas reuniones programadas dentro de Scrum,
también llamadas eventos.

Todos las reuniones o eventos tienen un timebox (duración máxima) definida y

persiguen un objetivo concreto y conocido de inspección y adaptación sobre un
aspecto del Scrum Team.

Las reuniones programadas dentro de Scrum son:

-­‐ Daily Scrum.

-­‐ Sprint Planning.
-­‐ Sprint Review.
-­‐ Sprint Retrospective.

3.2. DAILY SCRUM

Definición

El Daily Scrum o Scrum Diario es una reunión de 15 minutos para que el Team
o Equipo de Desarrollo inspeccione el trabajo realizado desde la última reunión,
se sincronice y establezca el plan para las próximas 24 horas. Debe realizarse
a diario.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

Esta reunión cuenta con el objetivo de facilitar la transferencia de información y la

colaboración entre los miembros del equipo y para aumentar su productividad al poner
de manifiesto puntos en que se pueden ayudar unos a otros.

Durante el Daily Scrum cada miembro del Team debe responder a estas tres
preguntas:

1. ¿Qué he hecho desde la última reunión para cumplir los objetivos?

2. ¿Qué voy a hacer antes de la próxima reunión para cumplir los objetivos?
3. ¿Qué obstáculos he encontrado en el camino para cumplir los objetivos?

El Team debe evaluar el progreso hacia el objetivo del sprint y pronosticar la

probabilidad de completar los artículos antes de que concluya el sprint. Debe, también,
realizar un seguimiento del progreso del sprint cada día y, por lo tanto, es una buena
idea que el tablón del Sprint (que podría ser un mural o un gráfico en la pared) este
visible durante esta reunión. Podríamos además utilizar un gráfico de avance (burn-
down chart) para monitorear el trabajo restante y prever si todos los artículos se
completaran antes del final del sprint.

Ejemplo

Observa el siguiente tablón de sprint que incluye un diagrama de avance para

Objetivo del sprint Pendiente En progreso Completado

Item #1 t1.1
Habilitar todas las partes t1.2 t1.3 t1.4
de la tienda online para t1.5 t1.6
permitir que los usuarios
puedan experimentar un
proceso de compra
Item #2 t2.3 t2.1 t2.2
completa. Esta hará que
otras características de la
página web sean más
significativas. Item #3 t3.2
t3.1
t3.3 t3.4 t3.5

Item #4 t4.1
t4.2 t4.3
Item #5

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

monitorear el progreso del sprint en base a la cantidad de trabajo pendiente:

Recomendaciones:

• No sobrepasar el timeboxing. El Team puede estar en pie para evitar relajación

y excesivo consumo de tiempo.
• El Daily Scrum no está para resolver problemas. Es una reunión de estado y
sincronización del equipo.
• Se pueden realizar reuniones de colaboración entre los miembros del Team
después de la sincronización para resolver dudas o problemas,
• Para evitar complicaciones el Scrum Diario debería celebrarse siempre en el
mismo lugar y a la misma hora durante todo el Sprint.
• Es una reunión solo para el Equipo de Desarrollo, no una reunión para todos
los interesados en el proyecto (stakeholders).

3.3. SPRINT PLANNING

En el Sprint Planning el objetivo principal es preparar y compartir entre todos qué se va
a hacer exactamente en el próximo sprint. De esta reunión deberíamos salir todos con
una idea muy clara de lo que va a pasar en las siguientes 2 semanas (o lo que dure el
sprint) y de cómo lo vamos a conseguir.

El Team no tiene que esperar hasta que el Product Backlog esté planificado al 100%
para comenzar a desarrollar el proyecto. En cuanto el Product Backlog tenga
consistencia y cuerpo suficientes el Product Owner y el Team (Equipo de Desarrollo)
comienzan con el primer sprint.

Algunas de las características del Sprint Planning son:

-­‐ Duración:

El primer día del sprint se realiza el evento de planificación del mismo. La

Planificación del Sprint es una reunión de tiempo limitado (timeboxing).

La duración de este evento suele ser de 2 horas de planificación por cada

semana de duración del sprint, por lo que a un sprint de un mes de duración le
corresponderían 8 horas de Planificación del Sprint, y así proporcionalmente.

-­‐ Asistentes:

El primer día del sprint se realiza el evento de planificación del mismo. La

Planificación del Sprint es una reunión de tiempo limitado (timeboxing).

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

La duración de este evento suele ser de 2 horas de planificación por cada

semana de duración del sprint, por lo que a un sprint de un mes de duración le
corresponderían 8 horas de Planificación del Sprint, y así proporcionalmente.

-­‐ Actividades:

Previo a la reunión, el Product Owner ya ha clasificado y ordenado los

elementos del Product Backlog en base al valor de los artículos. El Product
Owner también es responsable de asegurarse que los elementos (historias de
usuario) sean fáciles de entender.

o El Team debe estimar la capacidad de trabajo que puede ofrecer en un

solo Sprint.
o El equipo de desarrollo selecciona un número de elementos de la parte
superior del Product Backlog y los pone en el Sprint Backlog, para
completarlos y entregarlos en el sprint actual.
o El Team calcula la cantidad de trabajo que requiere cada artículo. La
cantidad total de trabajo de los elementos seleccionados del Product
Backlog debería estar cerca de la capacidad de trabajo estimada del
Team.
o Seleccionados los artículos, es responsabilidad de todo el Equipo
Scrum establecer y redactar el objetivo del sprint.

Esta reunión se divide en dos bloques:

¿Qué se va a realizar?:

En la primera parte, el Product Owner acuerda con el Team el objetivo del sprint y los
elementos del Product Backlog que lograrían dicho objetivo. Para ello, además del
propio Product Backlog, se tendrá en cuenta el último incremento del producto, el
rendimiento del equipo en otros Sprints y la capacidad estimada del Team para este
Sprint. El Team decidirá el número de elementos del Product Backlog que es capaz de
realizar.

Para finalizar este primer bloque, el equipo Scrum definirá el objetivo del Sprint, es
decir, la meta a la que se llegaría con la implementación de los elementos
seleccionados, que además sirve de guía al equipo del por qué se está desarrollando
dicho incremento.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

¿Cómo se va a hacer?

El Team decide cómo transformará los elementos seleccionados de la primera parte

en un incremento de trabajo terminado.

El Product Owner podrá ausentarse durante esta parte, aunque deberá estar
disponible tanto para resolver las dudas que surjan durante la reunión como para
reajustar la cantidad de trabajo a realizar si durante este bloque el equipo detecta que
la cantidad de trabajo es demasiada o insuficiente.

Por último, el Team debe ser capaz de explicar cómo va a crear el incremento
esperado al Product Owner y al Scrum Master.

Recomendaciones:

• Es importante cumplir con el timeboxing, y en el Sprint Planning ese

cumplimiento dependerá fundamentalmente de la preparación, de que las
historias de usuario lleguen con el tamaño adecuado y que sean fácilmente
entendibles por el Team.
• Las historias de usuario deben estar priorizadas y ordenadas en el Product
Backlog.
• Es el Team el que asume el compromiso de construir lo que considera que
pueda lograr dentro del sprint.
• Hay que sincronizar lo que se trabajará en el Sprint Planning con el cliente u
otros Stakeholders.
• Hay que indicar la fecha de comienzo y fin del sprint ya que al hacer visible la
duración, ayuda a no perder la noción del tiempo y caer en la tentación de
extender el sprint al no terminar lo que pusimos como objetivo.

3.4. SPRINT REVIEW

Definición

El Sprint Review o Demostración de Requisitos es una reunión que se realiza al

final del sprint en la que se revisan los resultados obtenidos respecto al objetivo
del sprint, problemas identificados y cómo se resolvieron.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

En esta reunión se presentan al cliente los requisitos completados en forma de

incremento de producto preparado para ser entregado y usado con el mínimo
esfuerzo. También se actualiza el Backlog de Producto, se introducen elementos
nuevos o se modifican los ya existentes.

El contenido del Sprint Review es el siguiente:

a. El Product Owner explica qué ítems del Product Backlog han sido
finalizados y cuáles no. Es importante tener en cuenta que las tareas
terminadas deben respetar el Definition of Done (DoD). Un avance del
99% de una historia de usuario es solo un 0% "completo". El propósito
de presentar el incremento en esta reunión es recabar información y
conocer las solicitudes de cambio a la mayor brevedad.
b. El Team se encarga de hacer la demostración del incremento terminado
durante el sprint.
c. El Team, principalmente, responderá a cuestiones relacionadas con el
incremento. La normal es que la mayoría de las preguntas sean
técnicas.
d. El Product Owner comenta sobre el estado del Product Backlog.
e. Se realiza una revisión del proyecto y sobre qué es lo siguiente que se
hará. En base a esto, el Product Owner se encarga de reorganizar el
Product Backlog en caso de que surgiera feedback por parte del cliente.
f. Se hace una revisión sobre tiempos, presupuesto y alcance del
proyecto para futuros sprints

Recomendaciones:

• La duración de esta reunión es normalmente de dos horas para sprints de dos

semanas. Si los sprints son más largos, la reunión será proporcionalmente más
larga.
• En Scrum no solo son bienvenidos los cambios, sino que es necesario que se
soliciten, ya que aumenta la satisfacción del cliente y contribuirán a crear un
producto final que responderá mejor a las necesidades del cliente.
• Cualquier historia de usuario que no se encuentre "completa" al final del sprint
vuelve al Product Backlog, y el Product Owner deberá reordenarla. Si dichos
elementos todavía están en la parte superior del Product Backlog, se
escogerán para completarse en el próximo Sprint, pero si se situara más abajo
deberán esperar hasta que llegue su turno.

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

• Todo el equipo de Scrum participa en la revisión del Product Backlog en base a

los resultados del sprint y el feedback del cliente.

3.5. SPRINT RESTROSPECTIVE

El Sprint Restrospective es el último evento de la secuencia del sprint. Esta reunión

permite al Team reflexionar acerca del trabajo que se acaba de completar, los
objetivos del proyecto que se acaban de cumplir e identificar los elementos que se
podrían mejorar.

Después de que se haya realizado una demostración de requisitos completados en el

sprint review, el equipo de Scrum debe tener la oportunidad de reflexionar sobre el
trabajo que se acaba de mostrar y discutir formas de mejorar. La retrospectiva es esa
oportunidad. Le da al equipo de Scrum una plataforma para discutir las cosas que van
bien, las cosas que podrían ir mejor y algunas sugerencias para efectuar cambios.
Algunas preguntas comunes que se hacen son:

-­‐ ¿Qué salió bien en la última iteración?

-­‐ ¿Qué no salió tan bien?
-­‐ ¿Qué hay que mejorar?
-­‐ ¿Qué podríamos hacer diferente para mejorar?

Nota

En Scrum se debe buscar constantemente formas de mejorar, no importa

cuánto de pequeña que sea la mejora, pero siempre debe haber una mejora.
Durante la retrospectiva del sprint inspeccionaremos el sprint actual en lo
referente a las personas, los procesos y las herramientas, e identificaremos
formas de mejorar para el próximo sprint.

Es una reunión de 1,5 horas para sprints de dos semanas, y proporcionalmente

más larga en función de la duración del sprint.

Recomendaciones:

• El Sprint debe terminar con el Sprint Retrospective. Si no se realiza la reunión

de retrospectiva, no ha terminado el Sprint

 
 IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM  

• A esta reunión deben asistir el Scrum Master y el Team. La presencia del

Product Owner es opcional.
• El resultado del Sprint Retrospective puede ser:
o Plan de acciones de mejora.
o Nuevas best practices.
o Impedimentos a escalar.
o Acuerdos del Team alcanzados.
• El Team y el Scrum Master deben tener autoridad, medios y recursos para ir
mejorando la forma de trabajar. Sin esa autoridad ni capacidad, siempre
aparecerán los mismos obstáculos insalvables, lo que produce desmotivación.

RESUMEN

En Scrum, los proyectos se ejecutan en ciclos temporales cortos y de duración fija que
normalmente son de entre 2 y 4 semanas. Son ciclos iterativos e incrementales
llamados sprints. Cada iteración o sprint tiene que proporcionar un resultado completo,
un incremento de producto final que sea susceptible de ser entregado al cliente.

Una de las claves del éxito de Scrum es el concepto de timeboxing. Tanto las
iteraciones como las reuniones de Scrum tienen una duración máxima que favorece la
regularidad, la disciplina, el foco y la concentración del equipo, centrándose en lo que
genera valor al negocio.

La duración del sprint es fija y no se puede modificar durante la iteración.

Actividades durante un sprint:

-­‐ Se planifica el sprint.

-­‐ Se desarrolla el Sprint Backlog.
-­‐ Se realizan las reuniones establecidas.

 
IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM