1

INTRODUCCIN
En el ao 1986 Takeuchi y Nonaka publicaron un artculo The New Product
Development Gameel cual dar a conocer una nueva forma de gestionar proyectos
en la que la agilidad, flexibilidad y la incertidumbre son los elementos principales.
Nonaka y Takeuchi se fijaron en empresas tecnolgicas que estando en el mismo
entorno, dentro de el se encontraban otras empresas, realizaban productos en
menos tiempo, de buena calidad y de menos costes.
Observando a empresas como Honda, HP, Canon, etc, se dieron cuenta de que el
producto no segua unas fases en las que haba equipo especializado en cada una
de ellas, si no que se parta de unos requisitos muy generals y el producto lo
realizaba un equipo multidisciplinario que trabajaba desde el comienzo del proyecto
hasta el final.
Se comparo esta forma de trabajo en equipo, con la colaboracin que hacen los
jugadores de Rugby y la utilizacin de una formacin denominada SCRUM.
SCRUM aparece como una prctica destinada a los productos tecnolgicos y sera en
1993 cuando realmente Jeff Sutherland aplique el modelo de desarrollo de software
en Ease/Corporation.
En 1996, Jeff Sutherland y Ken Schwaber presentaron las prcticas que se usaban
como proceso formal para el desarrollo de software y que pasaran a incluirse en la
lista de Agile Alliance.

MARCO TERICO
Scrum es adecuado para aquellas empresas en las que el desarrollo de los
productos se realiza en entornos que se caracterizan por tener:
1. Incertidumbre: Sobre esta variable se plantea el objetivo que se

quiere alcanzar sin proporcionar un plan detallado del producto.

Esto genera un reto y da una autonoma que sirve para generar una
tensin adecuada para la motivacin de los equipos.
2. Auto-organizacin: Los equipos son capaces de organizarse por s

solos, no necesitan roles para la gestin pero tienen que reunir las
siguientes caractersticas:

Autonoma: Son los encargados de encontrar la solucin usando

la estrategia que encuentren adecuada.

Autosuperacin: Las soluciones iniciales sufrirn mejoras.

Auto-enriquecimiento: Al ser equipos multidisciplinares se ven

enriquecidos de forma mutua, aportando soluciones que puedan
complementarse.

3. Control moderado: Se establecer un control suficiente para evitar

descontroles. Se basa en crear un escenario de autocontrol entre iguales

para no impedir la creatividad y espontaneidad de los miembros del
equipo.
4. Transmisin del conocimiento: Todo el mundo aprende de todo el

mundo. Las personas pasan de unos proyectos a otros y as comparten

sus conocimientos a lo largo de la organizacin.
Scrum al ser una metodologa de desarrollo gil tiene como base la idea de
creacin de ciclos breves para el desarrollo, que comnmente se llaman
iteraciones y que en Scrum se llamarn Sprints.
Para entender el ciclo de desarrollo de Scrum es necesario conocer las 5 fases

que definen el ciclo de desarrollo gil:

1. Concepto: Se define de forma general las caractersticas del

producto y se asigna el equipo que se encargar de su desarrollo.

2. Especulacin: en

esta fase se hacen disposiciones con la

informacin obtenida y se establecen los lmites que marcarn el

desarrollo del producto, tales como costes y agendas.
Se construir el producto a partir de las ideas principales y se
comprueban las partes realizadas y su impacto en el entorno.
Esta fase se repite en cada iteracin y consiste, en rasgos generales, en:

Desarrollar y revisar los requisitos generales.

Mantener la lista de las funcionalidades que se esperan.

Plan de entrega. Se establecen las fechas de las versiones,

hitos e iteraciones. Medir el esfuerzo realizado en el proyecto.

3. Exploracin: Se incrementa el producto en el que se aaden las

funcionalidades de la fase de especulacin.

4. Revisin: El equipo revisa todo lo que se ha construido y se contrasta

con el objetivo deseado.

5. Cierre: Se entregar en la fecha acordada una versin del producto

deseado. Al tratarse de una versin, el cierre no indica que se ha

finalizado el proyecto, sino que seguir habiendo cambios, denominados
mantenimiento, que har que el producto final se acerque al producto
final deseado.

ITERACCIONES

Revisi
n

Especulaci
n

Exploraci
n

Figura.: Ciclo de desarrollo gil.

Scrum gestiona estas iteraciones a travs de reuniones diarias, uno de los

elementos fundamentales de esta metodologa.

Figura.- 21: Ciclo principal de Scrum

Componentes de Scrum.
Para entender todo el proceso de desarrollo del Scrum, se describir de forma
general las fases y los roles. Estas fases y roles se detallarn de forma ms

concisa ms adelante.
Scrum se puede dividir de forma general en 3 fases, que podemos entender como
reuniones. Las reuniones forman parte de los artefactos de esta metodologa
junto con los roles y los elementos que lo forman.

Las Reuniones.
1. Planificacin del Backlog

Se definir un documento en el que se reflejarn los requisitos del sistema por

prioridades.
En esta fase se definir tambin la planificacin del Sprint 0, en la que se
decidir cules van a ser los objetivos y el trabajo que hay que realizar para
esa iteracin.
Se obtendr adems en esta reunin un Sprint Backlog, que es la lista de
tareas y que es el objetivo ms importante del Sprint.
2. Seguimiento del Sprint

En esta fase se hacen reuniones diarias en las que las 3 preguntas principales
para evaluar el avance de las tareas sern:

Qu trabajo se realiz desde la reunin anterior?

Qu trabajo se har hasta una nueva reunin?

Inconvenientes que han surgido y qu hay que solucionar para

poder continuar.

1. Revisin del Sprint

Cuando se finaliza el Sprint se realizar una revisin del incremento que se ha

generado.

Se presentarn los resultados finales y una demo o versin,

esto ayudar a mejorar el feedback con el cliente.

Los Roles.
Los roles se dividen en 2 grupos: cerdos y gallinas, esto surge en el chiste
sobre un cerdo y una gallina y su intencin de poner un restaurante.

1.
1. LOS CERDOS
Son las personas que estn comprometidas con el proyecto y el proceso de
Scrum.

Product Owner: Es la persona que toma las decisiones, y es la que

realmente conoce el negocio del cliente y su visin del producto. Se
encarga de escribir las ideas del cliente, las ordena por prioridad y las
coloca en el Product Backlog.

ScrumMaster: Es el encargado de comprobar que el modelo y la

metodologa funciona. 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 pequeo de unas 5-9

personas y tienen autoridad para organizar y tomar decisiones para
conseguir su objetivo. Est involucrado en la estimacin del esfuerzo de
las tareas del Backlog.

2. LAS GALLINAS
Aunque no son parte del proceso de Scrum, es necesario que parte de la
retroalimentacin d la salida del proceso y as poder revisar y planear
cada sprint.

Usuarios: Es el destinatario final del producto.

Stakeholders: Las personas a las que el proyecto les producir un

beneficio. Participan durante las revisiones del Sprint.

Managers: Toma las decisiones finales participando en la seleccin de

los objetivos y de los requisitos.

Elementos de Scrum.
Los elementos que forman a Scrum son:

Product Backlog: lista de necesidades del cliente.

Sprint Backlog: lista de tareas que se realizan en un Sprint.

Incremento: parte aadida o desarrollada en un Sprint, es un parte

terminada y totalmente operativa.

Figura.: Ciclo de desarrollo Scrum.

Product Backlog.
Es el inventario en el que se almacenan todas las funcionalidades o requisitos en
forma de lista priorizada. Estos requisitos sern 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 adems contendr

todo lo que aporte un valor final al producto.

Las tres caractersticas principales de esta lista de objetivos sern:

Contendr los objetivos del producto, se suele usar para

expresarlos las historias de usuario.

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, se basar en el ROI.

En la lista se tendrn que indicar las posibles iteraciones y los

releases que se han indicado al cliente.

La lista ha de incluir los posibles riesgos e incluir las tareas

necesarias para solventarlos.

Es necesario que antes de empezar el primer Sprint se definan cules 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. Realizar este orden de tareas tiene
como beneficios:

El proyecto no se paraliza simplemente por no tener claro los

requisitos menos relevantes, y el cliente podr ver resultados de
forma ms rpida.

Los requisitos secundarios aparecern a medida que se va

desarrollando el proyecto, por lo tanto, no se pierde tanto tiempo en
analizarlos al principio y el cliente ser ms consciente de sus
necesidades.

Los requisitos secundarios puede que no se lleguen a necesitar

porque se han sustituido o porque no reportan un retorno ROL
interesante.

Una vez definidos los requisitos se tendr que acordar cundo se tiene que
entender un objetivo como terminado o completado.
Se entiende que un producto est completado si:

Asegura que se puede realizar un entregable para realizar una

demostracin de los requisitos y ver qu se han cumplido.

Incluir todo lo necesario para indicar que se est realizando el

producto que el cliente desea.
8

Como complemento a la definicin de completado, se debera de asociar una

condicin de aceptacin o no aceptacin a cada objetivo en el mismo momento
en el que se crea la lista.
Finalmente el Product Backlog ir evolucionando mientras el producto exista en el
mercado. Esta es la forma para evolucionar y tener un valor de producto para el
cliente suficiente para ser competitivo.

Las historias de Usuario.

Son las descripciones de las funcionalidades que va a tener el software.
Estas historias de usuario, sern el resultado de la colaboracin entre el cliente y
el equipo, e irn evolucionando durante toda la vida del proyecto.
Las historias de usuario se componen de tres fases denominadas Las 3 C:

Card: Ser una breve descripcin escrita que servir como recordatorio.

Conversation: Es una conversacin que servir para asegurarse de

que se ha entendido bien todo, y concretar el objetivo.

Confirmation: Tests funcionales para fijar detalles que sean relevantes

e indicar cul va a ser el lmite.

En cuanto al formato, un modelo podra ser como el que se muestra en la siguiente

imagen:





















Figura.: Ejemplo de Historia de usuario (fuente: http://devnettips.blogspot.com.es/)

10

ID: Identificador de la historia de usuario.

TTULO: Ttulo descriptivo de la historia de usuario.

DESCRIPCIN: Descripcin sintetizada de la historia de usuario.

ESTIMACIN: Evaluacin del coste de implementacin en unidades de

desarrollo.

Estas

unidades

representarn

el

tiempo

terico

(desarrollo/hombre) que se haya estimado al comienzo del proyecto.

PRIORIDAD: Prioridad en la implementacin de la historia de usuario

respecto al resto de las historias de usuario. A mayor nmero, mayor
prioridad. Otra aproximacin a la priorizacin de tareas se hace a travs
del mtodo MoSCoW:
M Must, se debe completar este requerimiento para finalizar el
proyecto.
S Should, se debe completar este proyecto por todos los medios,
pero el xito del proyecto no depende de l.
C Could, se debera completar este requerimiento si su
implementacin no afecta a la consecucin de los objetivos principales
del proyecto.
W Would, se puede completar este requerimiento si sobra tiempo de
desarrollo (o en futuras versiones del mismo)

DEPENDENCIAS: Una historia de usuario no debera ser dependiente de

otra historia, pero a veces es inevitable. En este apartado se indicaran los
IDs de las tareas de las que depende una tarea.
Formato de la Pila Del Producto (Product Backlog).
En Scrum, la preferencia por tener documentacin en todo momento es menos
estricta. Se encuentra ms necesario el mantener una comunicacin directa con el
equipo, por eso se usa como herramienta el Backlog.
Aunque no hay ningn producto especial a la hora de confeccionar la lista, es
conveniente que incluya informacin relativa a:

10

11

Identificador para la funcionalidad.

Descripcin de la funcionalidad.

Sistema de priorizacin u orden.

Estimacin.

Figura.: Ejemplo de un Product Backlog(Fuente: Srum Manager. Gestin de Proyectos)

Sprint Backlog.
Es la lista de tareas que elabora el equipo
de

durante

la planificacin

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 ms pequeas y se
puede determinar o ver en qu tareas no se est avanzando e intentar eliminar el
problema.

11

12

Cmo funciona la lista:

Es una lista ordenada por prioridades para el cliente.

Puede haber dependencias entre una tarea y otra, por lo tanto se

tendr que diferenciar de alguna manera.

Todas las tareas tienen que tener un coste semejante que ser entre
4-16 horas.

Formato de la lista:
Hay 3 opciones:

Hojas de clculo.

Pizarras.

Herramientas colaborativas.

Generalmente, las tareas a completar se suelen gestionar mediante el Scrum

Taskboard, 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 para cambiar
el estado.
Se debe incluir:

Lista de tareas.

Persona responsable de cada tarea, el estado en el que se encuentra y el

tiempo que queda por terminarla.

Permite la consulta diaria del equipo.

Permite tener una referencia diaria del tiempo que le queda a cada tarea.

12

13

Incremento.
Representa los requisitos que se han completado en una iteracin y que son
perfectamente operativos. Segn los resultados que se obtengan, el cliente
puede ir haciendo los cambios necesarios y replanteando el proyecto.
DESARROLLO DE LAS FASES DE UN PROYECTO EN SCRUM.
Preparacin 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 producen gran nmero de inexactitudes con las
estimaciones, pero es lgico, debido a que se hacen a alto nivel, por lo 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 das.
Las tareas a realizar en el sprint 0 son:

Definir el proyecto: Se debera de indicar de forma clara el propsito del

proyecto, no es necesario entrar en detalle pero s que todo el equipo
sea capaz de entender cules son las necesidades del producto y del
cliente.

Definir terminado: Marcar el punto en el que se va a considerar que

la tarea est terminada.

Definicin del Backlog inicial: Se comienza la creacin 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, que tendr como responsabilidad
priorizar las funcionalidades que, al desarrollarlas e implementarlas
cumplan las especificaciones consiguiendo adems que su beneficio
supere a su coste.

Definicin de los entregables: Una vez que se tiene el Backlog con las
funcionalidades, es necesario establecer criterios para hacer pequeas
entregas entregables del producto y as obtener su valor y un feedback

temprano.
13

14

El plan de entregables puede sufrir modificaciones, muchas de ellas propiciadas

por:

Cambia el entorno y aparecen nuevas oportunidades para el

negocio.

Se encuentran nuevas funcionalidades y estas proporcionan un

valor si se pusiese en produccin.

Replanteamiento del entregable.

El plan de entregas lo determinar el negocio, que ser el encargado de marcar

qu funciones, calidad y coste va a tener.
De la misma manera, estar sujeto a unas determinadas condiciones
determinadas por el equipo de trabajo que sern:

Tiempo para un entregable.

La estimacin inicial.

Seleccin del Backlog del producto.

Constitucin del equipo:

Se hace una reunin inicial con todos los roles del equipo para tratar:

Dimensin del proyecto.

Revisiones del Backlog.

Organizacin del equipo y horario para establecer reuniones de

control.

14

15

Las Estimaciones del Backlog

Antes de la primera reunin de la planificacin el Equipo tiene que conocer cul
va a ser su velocidad inicial y su factor de dedicacin.
Para poder realizar las estimaciones, primeramente hay que decidir qu historias
incluir en la pila del Sprint.
La forma en la que se podr decidir qu historias poner o no se puede realizar
mediante 2 tcnicas:

De forma aproximada.

Realizando clculos de velocidad.

1. De forma aproximada:

En la estimacin aproximada, el equipo debate el nmero de historias a introducir

hasta llegar a un acuerdo. Suele funcionar de forma correcta si los Sprints son
cortos.
2. Realizando los clculos de velocidad:

Esta tcnica se realiza en dos pasos:

Seleccionar la velocidad estimada.

Calcular el nmero de historias que se pueden aadir sin pasar la

velocidad estimada.

La manera ms adecuada de estimar la velocidad, es revisar el historial del

equipo, de esta manera, basndonos en Sprints anteriores se podr deducir que
ser muy similar.

Para poder realizar esta tcnica, es necesario que los equipos tengan un historial,
que vayan hacer los prximos Sprints de la misma manera, mismo tamao de
equipo y las mismas condiciones de trabajo. La tcnica se conoce como el
tiempo que hizo ayer.

15

16

Otra forma de hacerlo es mediante el clculo de recursos.

1. Se calcula el nmero de das hombre disponible, este es un valor poco real
porque influyen factores externos de ah que tengamos que usar el factor de
dedicacin.

Nombre

Das
Planificacin de un Sprint
de
3
semanas
con
disponibilidades distintas

USER 1

15

USER 2

13

USER 3

USER 4

13

TOTAL

48 Das-Hombre Disponibles

VELOCIDAD ESTIMADA
(

) (

El factor de dedicacin se basa en estimar el estado del equipo, si es bajo

entonces se espera encontrar dificultades.
La forma ms adecuada para determinar factores de dedicacin razonable es
el estado de los ltimos Sprints.

FACTOR DE DEDICACIN
(

Velocidad real = suma de las estimaciones iniciales que se realizaron

completamente en el ltimo Sprint.

Ejemplo:
Si tenemos un equipo que complet 20 historias de usuario, con 3 personas
sumando 35 das- hombre, para calcular el prximo Sprint en el que habr un
componente ms, sumando 45 das- hombre y teniendo en cuenta que en el
ltimo Sprint se completaron 20 puntos, el resultado sera:

16

17

De esta manera se obtendr la velocidad estimada por el siguiente Sprint.

Si el equipo fuese nuevo, se puede mirar el factor de dedicacin de otros equipos
con lo que fijarte y de no haberlo, se pondra un valor aproximado para empezar
por defecto. El factor que se suele usar es de 70%.

Si el equipo fuese nuevo, se puede mirar el factor de dedicacin de otros equipos con lo que
fijarte y de no haberlo, se pondra un valor aproximado para empezar por defecto. El factor que se
suele usar es de 70%.

Planificar un Sprint.

Figura.: Entras/Salidas de un Planning Meeting.

Denominado tambin Sprint Planning Meeting, tiene como finalidad realizar

una reunin, en la que participarn el Product Owner, el Scrum Master y el
equipo, con la intencin de seleccionar

de la lista Backlog del producto las

funcionalidades sobre las que se va a trabajar, y que darn valor al producto.

Antes de comenzar la reunin el Product Owner tendr que preparar el Backlog.
La reunin se realiza en con time-box de ocho horas que se divide en 2 partes de 4
horas.

17

18

Primera parte de la reunin:

El equipo selecciona los items para transformarlos en entregables.

El equipo hace sugerencias, pero es el Product Owner el que

decidir si formarn parte del Sprint.

El equipo seleccionar el elemento a implementar, de los

seleccionados por el Product Owner para ese Sprint.

Segunda parte de la reunin:

El equipo har las preguntas necesarias que tengan sobre el
Product Baklog al Product Owner.

El equipo se encargar de encontrar la solucin adecuada para

transformar la parte seleccionada de una funcionalidad entregable.

El resultado de la segunda parte de la reunin es una lista denominada Sprint

Backlog con las tareas, estimaciones y las asignaciones de trabajo al equipo para
poder empezar a desarrollar la funcionalidad.
Las caractersticas del Backlog del producto sern las siguientes:

La estimacin ser entre 4 y 16 horas, si son mayores a este valor,

se descompondrn.

Las tareas del Sprint deben de ser como consecuencia de la

necesidad de un requerimiento del Backlog del producto.

El progreso de las tareas en las que se mide la velocidad y el

progreso del Sprint con respecto a las horas, se realizar mediante
grficos Burndown Chart.

Figura: Grfico de avance de un Sprint

18

19

El soporte en el que se presentan el Sprint Backlog puede ser:

Hoja de clculo.
Pizarra.

Herramientas colaborativas de red.

La herramienta como soporte quizs ms utilizada es el (Scrum Taskboard)

en la que en una pizarra se crea una tabla con la siguiente informacin:

1 fila: Tareas que no se han planificado pero que son necesarias de

hacer por su urgencia (errores, cambios importantes decididos por el
cliente, etc).

2 fila: Mejora continua. Se ponen las tareas de retrospectivas anteriores

que se quieren analizar en ese Sprint.

Columna tareas no empezadas: Se pondrn todas las tareas que se

han especificado en la reunin del Sprint planning.

En curso: Tareas que se estn realizando y que deberan ser mnimas y

resueltas de arriba abajo.

Hecho: Tarea realizada completamente.

Impedimentos: Lista de obstculos que impedirn continuar de forma

adecuada el proyecto. Hay que indicar quin ser el responsable de
solucionarlos.

Retrospectiva: Sirve para anotar qu partes estn bien durante la

iteracin y cules mal. Se reflejan con un + y un -

19

20

Otro ejemplo de Scrum TaskBoard sera:

Figura.: Scurm TaskBoard(Fuente: Scrum y Xp desde las trincheras)

La Estimacin del Sprint.

Planificacin De Pker.
Realizar las estimaciones para los tems seleccionados, es una tarea que deber
involucrar a todos los miembros del equipo. Para poder hacer una estimacin y
que los miembros del equipo no estn condicionados por la estimacin de los
compaeros se usar, la tcnica de Planning Poker.

20

21

1. Cada miembro del equipo tendr una baraja de 13 cartas.

2. Se propone una historia, el miembro del equipo selecciona
una carta y la coloca boca abajo. Esta carta representar
su estimacin para la historia propuesta.
3. Cuando todos los miembros han seleccionado su carta, se
le da la vuelta al mismo tiempo.
4. Se comprueban las estimaciones, y si hay muchas
discrepancias se discute sobre esas diferencias y se
ponen en comn las ideas sobre la naturaleza del trabajo.
Este proceso se repetir hasta que las estimaciones sean
5. parejas
Se comprueban
las estimaciones y si hay muchas
o aproximadas.
discrepancias se discute sobre esas diferencias y se
ponen en comn las ideas sobre la naturaleza del trabajo.
Este proceso se repetir hasta que las estimaciones sean
6. parejas
El tiempo
estimado es para el desarrollo de toda la
o aproximadas.
historia, por ese motivo la secuencia de nmeros no es
lineal y, por ejemplo, hay un salto entre 40 y 100. De esta
manera se evita sensaciones falsas para

estimaciones
Si las estimaciones
fuesen grandes.
ms detalladas las historias se podran dividir en
historias ms pequeas.
Hay 3 cartas especiales:

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

No hay idea de cunto puede ser la estimacin.

Taza de caf: Realizar un descanso para retomar despus la

estimacin.

Mantener el Backlog del Sprint.

El equipo tiene que mantener actualizado el Backlog del Sprint para poder tener
feedback y tomar cualquier decisin de manera rpida.b Es necesario, adems,
para que el grfico de Burdown del Sprint tambin est actualizado.

21

22

Interpretacin del diagrama de Burndown.

Ejemplo 1:

Trabajo restante
(puntos de historia)

50
40
30
20
10
0

10 11 12 15 16 17 18 19

Tiempo
El da 1 de Enero se estiman 7 puntos de historia, y a da 16 se observa que, incluso se est
bien de tiempo y que segn estos datos, completaramos el Sprint. Hay que tener en cuenta
que se saltan los fines de semana para no generar confusiones en la lectura del diagrama.

Trabajo restante
(puntos de historia)

Ejemplo 2:

40
30
20
10
0




50

10 11 12 15 16 17 18 19

Tiempo
Si el grfico que se genera es similar al del ejemplo 2, puede ocurrir que los puntos de historia
se hagan ms rpido de lo previsto, con lo que se podran aadir ms puntos de historia.
Ejemplo 3:

50
40
30
20
10
0
1

10 11 12 15 16 17 18

Tiemp
o es que se han escogido demasiados
En este caso, lo que nos muestra el grfico
tems para realizarlo y habra que analizar qu tems del Backlog habra que
eliminar en esta fase.

22

23

En los Sprints, el equipo trabaja para conseguir un incremento del producto, que
ser productivo para el Product Owner y los Stakeholders.
El tiempo ms conveniente est entre 2 y 4 semanas, o 30 das consecutivos
como mximo. Estos intervalos de tiempo, son los que se consideran ms
apropiados para que el Stakeholders no pierda el inters.
El desarrollo del Sprint
En los Sprints, el equipo trabaja para conseguir un incremento del producto, que
ser productivo para el Producto Owner y los Stakeholders.
El tiempo ms conveniente est entre 2 y 4 semanas, o 30 das consecutivos
como mximo. Estos intervalos de tiempo, son los que se consideran ms
apropiados para que el Stakeholders no pierda el inters.

Reuniones del Sprint

Durante la ejecucin del Sprint se van a realizar 3 reuniones:

Reunin de Planificacin (Sprint Planning Meeting).

Reunin diaria (Scrum Daily Meeting).

Reunin Revisin del Sprint (Sprint Review Meeting).

Reunin de Planificacin (Sprint Planning Meeting)

Definirn qu tareas se tienen que realizar y cules son los objetivos.
Una vez definidos, el equipo comienza su desarrollo, pero teniendo en cuenta una
serie de normas:

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.

23

24

Si durante el desarrollo del Sprint no se puede realizar, porque no

es viable, se puede realizar una nueva planificacin para realizar un
nuevo Sprint.

Si el equipo no puede comprometerse a cumplir todo el Backlog,

realizar una consulta con el Producto Owner para decidir qu tems
eliminar.

Si de la misma manera, el equipo se ve capaz de realizar ms tems

del Backlog durante el Sprint, que el indicado inicialmente,
consultar tambin con el Product Owner qu tems se podrn
aadir.

Teniendo en cuenta estas caractersticas, a lo largo del desarrollo, se producirn

adems, reuniones diarias.
Reunin Diaria (Sprint Daily Meeting)
En esta reunin, los componentes del equipo comparten informacin relativa al
desarrollo y colaborarn para hacer las adaptaciones necesarias, aumentando as
su productividad.
En esta reunin se tendr como referencia el Backlog del Sprint y el equipo
grfico burn-down con la informacin de la reunin anterior y, adems, qu tareas
hizo cada persona del equipo. La reunin no podr consumir ms de 15 minutos y
contestar a tres preguntas bsicas:

Qu se ha hecho de nuevo con respecto a la ltima reunin

diaria?

Qu ser lo siguiente a realizar?

Qu problemas hay para realizarlos?

Se usar como herramienta de apoyo, con la lista de tareas del Sprint actualizada
y con el esfuerzo pendiente de cada tare. Tambin se tendr un grfico con las
tareas pendientes en la iteracin.

24

25

Reunin Revisin del Sprint (Sprint Review Meeting)

En esta reunin, los desarrolladores presentan el producto entregable que han

implementado y, los gestores, clientes, usuarios y Product Owner analizan esa
entrega y escuchan al equipo sobre los problemas que han tenido durante el
proceso.
Esta reunin servir para tomar decisiones que ayudan a escoger el camino ms
adecuado para alcanzar las metas.
Las caractersticas de esta reunin se limitan a:

Mximo 4 horas.

Se presenta el producto completado, entendiendo como tal la

definicin 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 Stakeholders.

Se presenta la funcionalidad en equipos que pertenezcan a los

desarrolladores. Siempre se har desde un servidor lo ms parecido
posible al de produccin.

25

26

El Sprint Review transcurre siguiendo el siguiente proceso:

El ScrumMaster determina cuntas personas asistirn al Sprint

Review Meeting.
Al final de la reunin, el ScrumMaster anuncia al Product Owner y a
los Stakeholders la prxima reunin.

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 produce entonces una satisfaccin personal al comprobar y ver funcionando la

entreg

26

27

Reunin de Retrospectiva (Sprint Retrospective Meeting)

En esta reunin, el equipo debatir temas relacionados con el Sprint
recientemente finalizado y los cambios que se podran hacer para mejorar el
prximo Sprint y que sea ms productivo.
Generalmente, ser el ScrumMaster quin realiza esta reunin y tendr una
duracin mxima de 3 horas.
Las caractersticas generales de la reunin sern:

Asistirn el ScrumMaster, el Equipo y el Product Owner.

La reunin girar entorno a dos preguntas bsicas: Qu ha ido

bien durante el ltimo Sprint?, Qu ser mejorado para el
siguiente Sprint?.

El ScrumMaster toma nota delas respuestas del Equipo en un

formulario.

El Equipo hablar de las posibles mejoras que se puedan realizar,

indicando cules van a tener mayor preferencia.

El ScrumMaster ayudar a entrar mejores vas de apoyo, para las

mejoras indicadas por el Equipo.

Si hay puntos que merezca atencin se aadirn para el siguiente

Sprint, considerndolo como un Backlog no funcional, pero de alta
prioridad

27

28

Figura.: Ejemplo de Retrospectiva, de James Shore

28


29
Diagrama detallado de las fases de Scrum.
Se ha realizado de esta manera una gua por todo el proceso de creacin de
un proyecto Scrum en el que se van realizando las diferentes 5 fases en
forma de ciclos, hasta completar todas las tareas del Backlog.

REVISIN DE PLANES DE VERSIN:

Se revisa que hay que hacer y en que
punto est la distribucin actual.
SPRINT:
Es la fase de desarrollo iterativa.
Desarrollo: Anlisis, implementacin,
testing. Empaquetar: Generar paquetes
ejecutables Revisin: Resolucin de
problemas y se aaden nuevos tems.
Ajustes: Uso de los ajustes para
mejorar el producto.

SPRINT REVIEW:
Despus del Sprint se hace una
reunin con el ScrumMaster donde se
revisa el producto del Sprint anterior y
en el que se pueden aadir puntos
nuevos al backlog.

Cierre:
En esta fase se encuentran las tpicas
actividades de fin de proyecto como,
hacer una versin distribuible, testear,
marketing etc.

Tabla : Esquema de las 5 fases de desarrollo en Scrum.

29


30
CONCLUSIONES
Aplicando esta metodologa a proyectos que parecen complejos, podemos
llevarlos a la simplificacin, distribuyendo el trabajo de forma eficiente y
seccionando cada parte del proyecto.

30