Qu es SCRUM

Scrum es
complejos.

una metodologa gil para

desarrollar

los

productos

Scrum se utiliz originalmente para proyectos de desarrollo de

software, pero su enfoque y su flexibilidad hacen que los procesos
SCRUM sean ideales para proyectos que requieren velocidad en el
cambio. Las posibilidades son infinitas.
La metodologa Scrum es simple y se puede aplicar a cualquier
proyecto o desarrollo de producto. Scrum proporciona la base para la
entrega de los objetivos de negocio de una manera sana y creativa.
La metodologa Scrum es un marco Agil, slido que puede ser
adaptado a cualquier tipo de proyecto y el equipo.

ROLES EN SCRUM
Un equipo Scrum tiene tres funciones:

Scrum Master - ayuda al equipo en hacer un mejor utilizo de SCRUM por

la creaccion del producto

Product Owner - tiene la visin del producto

Development team - Crea el producto

Los valores en que se basan Scrum son:

Respeto todos los participantes son tratados como

valiosos, individuos nicos con una importante
contribucin que hacer. De cada miembro se espera
ofrecer esta cortesa a todas las dems personas con las
que interacta.

Compromiso Se espera que los participantes se

dediquen plenamente al equipo, eligiendo anteponer los
objetivos del equipo antes de los propios. A veces, los
miembros del equipo pueden optar por hacer sacrificios
razonables para un mejor beneficio del equipo.

Confianza los participantes pueden depender de sus

compaeros de trabajo para llevar a cabo sus funciones
con los ms altos estndares profesionales. Los
participantes actuarn con intenciones positivas y
asumirn que los dems estn actuando tambin con
intenciones positivas.

Visibilidad nada en Scrum est oculto a la vista. Cada

accin, decisin, artefacto, resultado y conversacin estn
libremente a disposicin de otros para su reflexin y
debate.

Valor los individuos y los equipos mostrarn fortaleza

ante la adversidad. Los miembros del equipo se
enfrentarn a los problemas que puedan surgir sin miedo,
confiados de que se pueda encontrar una solucin dentro
de sus capacidades y habilidades.

A partir de estos valores, Scrum se basa en

estos principios esenciales:

Priorizacin Es vital para el xito la ordenacin

peridica de los deseos y necesidades en conflicto. Se
realizarn conversaciones sobre el ranking que implicarn
a los afectados por estas decisiones y se tomarn en
cuenta sus deseos y necesidades.
Rendicin de cuentas todos son responsables de sus
decisiones, palabras, acciones y no acciones. Cada persona
tiene la facultad de apoyar a otros para cumplir con sus
compromisos, producir un trabajo de calidad, seguir el
marco de trabajo Scrum y cumplir el espritu de Scrum.
Inspeccin y adaptacin a intervalos regulares, el
equipo comprobar su progreso y har ajustes. Los equipos
de Scrum utilizan datos empricos para tomar sus
decisiones.
Ritmo Los equipos se esforzarn por desarrollar sus
acciones a una cadencia uniforme. El ritmo reduce la
variabilidad y aumenta la previsibilidad del equipo.
Retroalimentacin los participantes aceptan y
reciben nueva informacin sobre sus circunstancias y

entorno. Los ciclos de retroalimentacin se comprimen lo

ms breve posible para amplificar el efecto de los nuevos
conocimientos y hacer correcciones para el beneficio de la
empresa y los participantes.

Colaboracin ms all de la mera cooperacin, nos

esforzamos por contribuir en la mejora de los talentos y las
ideas de los dems. Colaborar inicia el cambio de
simplemente mejor a resultados de negocio sorprendentes.

La auto-organizacin Los miembros del equipo son

las personas ms adecuadas para movilizar sus esfuerzos
en torno a sus objetivos y para permanecer centrados en el
objetivo. Metas claras, lmites y autonoma son necesarias
para que esto ocurra.

Concentracin A los individuos se les dar tiempo y

espacio para concentrarse. Scrum trata de eliminar las
interrupciones innecesarias para que la gente pueda
finalizar sus tareas.
El proceso
En Scrum un proyecto se ejecuta en bloques temporales cortos y
fijos (iteraciones que normalmente son de 2 semanas, aunque
en algunos equipos son de 3 y hasta 4 semanas, lmite mximo de
feedback y reflexin). Cada iteracin tiene que proporcionar un
resultado completo, un incremento de producto final que sea susceptible
de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del

producto, que acta como plan del proyecto. En esta
lista el cliente prioriza los objetivos balanceando el valor que le
aportan respecto a su coste y quedan repartidos en iteraciones y
entregas.
Las actividades que se llevan a cabo en Scrum son las siguientes:

Planificacin de la iteracin
El primer da de la iteracin se realiza la reunin de planificacin de la
iteracin. Tiene dos partes:
1.

Seleccin de requisitos (4 horas mximo). El cliente presenta

al equipo la lista de requisitos priorizada del producto o proyecto. El
equipo pregunta al cliente las dudas que surgen y selecciona los
requisitos ms prioritarios que se compromete a completar en la
iteracin, de manera que puedan ser entregados si el cliente lo solicita.

2.

Planificacin de la iteracin (4 horas mximo). El equipo

elabora la lista de tareas de la iteracin necesarias para desarrollar los
requisitos a que se ha comprometido. La estimacin de esfuerzo se hace
de manera conjunta y los miembros del equipo se auto asignan las
tareas.

Ejecucin de la iteracin
Cada da el equipo realiza una reunin de sincronizacin (15 minutos
mximo). Cada miembro del equipo inspecciona el trabajo que el resto
est realizando (dependencias entre tareas, progreso hacia el objetivo
de la iteracin, obstculos que pueden impedir este objetivo) para poder
hacer las adaptaciones necesarias que permitan cumplir con el
compromiso adquirido. En la reunin cada miembro del equipo responde
a tres preguntas:

Qu he hecho desde la ltima reunin de sincronizacin?

Qu voy a hacer a partir de este momento?

Qu impedimentos tengo o voy a tener?

Durante la iteracin el Facilitador (Scrum Master) se encarga de que el
equipo pueda cumplir con su compromiso y de que no se merme su
productividad.

Elimina los obstculos que el equipo no puede resolver por s

mismo.

Protege al equipo de interrupciones externas que puedan afectar

su compromiso o su productividad.
Durante la iteracin, el cliente junto con el equipo refinan la lista de
requisitos (para prepararlos para las siguientes iteraciones) y, si es
necesario, cambian o replanifican los objetivos del
proyecto para maximizar la utilidad de lo que se desarrolla y el retorno
de inversin.

Inspeccin y adaptacin
El ltimo da de la iteracin se realiza la reunin de revisin de la
iteracin. Tiene dos partes:
1.

Demostracin (4 horas mximo). El equipo presenta al cliente

los requisitos completados en la iteracin, en forma de incremento de
producto preparado para ser entregado con el mnimo esfuerzo. En
funcin de los resultados mostrados y de los cambios que haya habido
en el contexto del proyecto, el cliente realiza las adaptaciones
necesarias de manera objetiva, ya desde la primera iteracin,
replanificando el proyecto.

2.

Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido

su manera de trabajar y cules son los problemas que podran impedirle
progresar adecuadamente, mejorando de manera continua su
productividad. El Facilitador se encargar de ir eliminando los obstculos
identificados.
Ver en detalle las diferentes actividades, responsabilidades y herramientas
en cmo funciona Scrum.

Los 3 pilares del empirismo son la transparencia, la inspeccin y la

adaptacin
Existen tres roles en Scrum: Product Owner, Scrum
Master y Development Team
Hay tres artefactos en Scrum: Product Backlog, Sprint Backlog e
Incremento (tablero scrum)
Cinco eventos: Sprint, Sprint Planning, Daily Scrum, Sprint Review
y Sprint Retrospective.
Pilares del Scrum:

Artefactos en Scrum: claves para una organizacin diaria

En este captulo hablaremos sobre las herramientas que Scrum,
propone para mantener organizado un proyecto de desarrollo de
Software: el backlog de producto, el backlog de sprint y Scrum
Taskboar, y el incremento de funcionalidad.

Introduccin
Scrum, propone tres herramientas o "artefactos" para mantener organizados
nuestros proyectos. Estos artefactos, ayudan a planificar y revisar cada uno de los
Sprints, aportando medios ineludibles para efectuar cada una de las ceremonias
que veremos en un siguiente captulo.
Describiremos ahora, cada uno de los artefactos, su definicin e importancia para
Scrum.
Backlog de Producto
El Backlog de Producto es un listado dinmico y pblicamente visible para todos los
involucrados en el proyecto.

En l, el Dueo de Producto, mantiene una lista actualizada de requerimientos

funcionales para el software. Esta lista, representa "qu es lo que se pretende"
pero sin mencionar "cmo hacerlo", ya que esta ltima, como vimos en el captulo
anterior, ser tarea del Scrum Team.
El Backlog de Producto, es creado y modificado nicamente por el Dueo de
Producto. Durante la ceremonia de planificacin, el Scrum Team obtendr los
items del producto, que deber desarrollar durante el Sprint. Formato del Backlog de
Producto

El Backlog de producto, es una lista de items que representan los requerimientos

funcionales esperados para el software.
Para cada uno de estos tems, ser necesario especificar:
1.

El grado de prioridad

2.

Esfuerzo que demanda

3.

Granulidad

4.

Criterios de aceptacin

Priorizacin de los tems del Backlog de Producto

Los items del backlog de producto, deben guardar un orden de prioridad, cuya base se
apoye en:

Beneficios de implementar una funcionalidad

Prdida o costo que demande posponer la implementacin de una funcionalidad

Riesgos de implementarla

Coherencia con los intereses del negocio

Valor diferencial con respecto a productos de la competencia

Estimacin de esfuerzo
A diferencia de las metodologas tradicionales, Scrum, propone la estimacin de esfuerzo
y complejidad que demanda el desarrollo de las funcionalidades, solo para aquellas cuyo
orden sea prioritario.

Estas estimaciones, no se efectan sobre items poco prioritarios ni tampoco sobre

aquellos donde exista un alto grado de incertidumbre.
De esta manera, se evita la prdida de tiempo en estimaciones irrelevantes,
postergndolas para el momento en el cual realmente sea necesario comenzar a
desarrollarlas.
Granulidad de los tems

Los items del Backlog de Producto no necesariamente deben tener una granulidad
pareja. Es posible encontrar tems tales como "es necesario contar con un mdulo
de control de stock y logstica" o uno tan pequeo como "Modificar el color de
fondo de los mensajes de error del sistema, de negro a rojo".
tems de tan baja granulidad, suelen agruparse en un formato denominado
"Historias de Usuario" mientras que los de alta granulidad, son los denominados
Temas o Epics.
Una historia de usuario es aquella que puede escribirse con la siguiente frase:

Como [un usuario], puedo [una funcionalidad] para [un beneficio]

Como usuario registrado, puedo cargar un voucher para calcular mi descuento en la compra.

Criterios de Aceptacin
Cada tem del Backlog de Producto, es necesario que especifique cuales son los
criterios de aceptacin (o test de aceptacin que debe superar), para considerar
cumplido el requisito.

Ejemplo:

Adems, las Historias de Usuario deben cumplir las

siguientes caractersticas para que puedan realizar su
funcin de manera correcta:

Independientes. Deben ser atmicas en su definicin.

Es decir, se debe intentar que no dependa de otras
historias para poder completarla.

Negociables. Como he dicho anteriormente, son

entidades vivas. Deben ser ambiguas en su enunciado
para poder debatirlas, dejando su concrecin a los
criterios de aceptacin.

Valoradas. Deben ser valoradas por el cliente. Para

poder saber cunto aporta al Valor de la aplicacin y
junto con la estimacin convertirse en un criterio de
prioridad.

Estimables. Aunque sea siempre un poco como leer

de una bola de cristal, deben poder ser estimadas. Tener
su alcance lo suficientemente definido como para poder
suponer una medida de trabajo en la que pueda ser
completarla.

Pequeas. Para poder realizar una estimacin con

cierta validez y no perder la visin de la Historia de
Usuario, se recomienda que sean mayores de dos das y
menores de dos semanas.

Verificables. Este es el gran avance de las Historias

de Usuario. Que, junto con el cliente, se acuerdan unos
Criterios de Aceptacin que verifican si se ha cumplido
con las funcionalidades descritas y esperadas.

Ejemplo real
Para finalizar este artculo, quiero compartir una Historia
de Usuario real para que sirva de ejemplo de lo que estoy
hablando.

Como usuario validado.

Quiero poder dar de alta anticipos.
Para poder recibir dinero anticipado para gastos.

Criterios de aceptacin:

Quiero poder de alta un anticipo rellenando el

formulario de anticipos.

Quiero poder dar de alta la peticin de un anticipo del

tipo permanente.

No debo poder solicitar dos anticipos permanentes.

No debo poder solicitar dos anticipos normales.

Debo poder solicitar un anticipo permanente y uno

normal, y viceversa.

Cuando pulse Aceptar o Grabar debe de registrarse

la solicitud en el sistema y desencadenar el flujo de
aprobaciones.

Cuando pulse Aceptar o Grabar el formulario debe

quedar bloqueado para su edicin.

Backlog de Sprint
El Backlog de Sprint es la recopilacin sinttica de items del Backlog de Producto,
negociados entre el Dueo de Producto y el Scrum Team en la ceremonia de
planificacin, reunin que se realiza al comienzo del Sprint.

Esta recopilacin, que durante la planificacin ha sido propuesta por el Dueo de

Producto y ya negociada, es aquella que el Scrum Team se compromete a
construir durante el Sprint en curso.
El Backlog de Sprint, generalmente (y muy recomendado), se visualiza mediante
tableros fsicos tambin llamados Scrum Taskboard - que hacen visible el
proceso de construccin, a toda persona que ingrese al rea de desarrollo.
Para armar el Backlog de Sprint, el Scrum Team, divide los items en tareas tasks
de que no demanden una labor superar a una jornada de trabajo. Es decir, que
una tarea, no debera superar las 8 horas de trabajo.
Estas tareas, sern divididas en pendientes, en curso y terminadas y cada una de
ellas, debe permitir visualizar, como mnimo, el esfuerzo que demanda su
construccin y el nombre del miembro del equipo que se ha asignado dicha tarea.
Es muy frecuente, a la vez de ser una prctica recomendada, que cada tarea sea
a la vez, "etiquetada", diferenciando, por ejemplo, cuando representa un bug, una
tarea de diseo, un test, etc.
Dividiendo un tem del Backlog de producto en tareas
La estrategia consiste en desmembrar el item a la mnima expresin posible,
encuadrada en un mismo tipo de actividad. El desmembramiento debe hacerse
"de lo general a lo particular, y de lo particular al detalle".
Retomando el ejemplo anterior, intentaremos desmembrar, el primer tem del
Backlog de Producto:
Como administrador quiero poder administrar las secciones del sistema para poder
establecer el orden de visualizacin de las mismas
Yendo de lo general (un ABM de secciones) a lo particular (hacer los modelos,
vistas - lgica y layot - y controladores; testearlo, integrarlo y documentarlo),
obtenemos una lista de tareas tentativa:

1.

Crear modelos ? actividad: programar

2.

Crear la lgica de las vistas ? actividad: programar

3.

Disear el layout de las vistas ? actividad: disear

4.

Crear los controladores ? actividad: programar

5.

Correr los test ? actividad: testear

6.

Integrar el ABM al sistema ? actividad: integrar

7.

Documentar el ABM en el manual del usuario ? actividad: documentar

Luego, de lo particular, se ir al detalle. Los detalles, son aquellas restricciones

que debern considerarse para todo lo anterior. Por ejemplo, la creacin del
modelo, repercutir en la base de datos. Por lo cual, tras crear los nuevos
modelos, habr que correr el ORM para que modifique las tablas.
Otro detalle a considerar, es el tiempo que demanda cada tarea. Por ejemplo,
correr un ORM lleva solo algunos minutos, pues no puede ser considerado una
nica tarea. Entonces, puede "sumarse como detalle" a la tarea "crear modelos".
De manera contraria, documentar en el manual del usuario, llevar todo un da de
trabajo. Por lo cual, debe asignarse a una nica tarea.

Tableros de Scrum
Con la lista de tareas ya armada, estamos en condiciones de crear el tablero.
Un Scrum Taskboard, bsicamente se divide en 3 columnas: pendientes, en curso
y terminadas y se complementa la informacin con un Diagrama de Burndown que
mostrar el esfuerzo restante para concluir el Sprint.
En Scrum este espacio se llama Task Board y se colocan all todas las historias
de usuario (necesidades) correspondientes a un Sprint (un determinado perodo
de tiempo, considerado un ciclo del proceso de desarrollo).

Para la organizacin de tareas es til disponer de un espacio (pizarrn, cartulina o

sobre la misma pared) que sirve para que todo el equipo tenga visible las
necesidades, dispuestas en orden de prioridad, que sern resueltas en el corto
plazo y todas las tareas involucradas.
En el estado inicial todas las tareas estn en la primer columna Pendiente, y a
medida que se van encarando, pasan a En curso donde se asigna por lo menos
una persona. Cuando se cumple con los criterios de aceptacin acordados, pasan
a la tercera y ltima columna Terminado.
De forma opcional, se pueden agregar en el mismo espacio la Visin y los
impedimentos.
Scrum es una de las metodologas giles ms conocidas en la actualidad. Aunque su
funcionalidad es diversa, se trata de una herramienta especialmente til en espacios donde
los grupos de trabajo tienen dificultades para operar y emprender las acciones necesarias
que les lleven a objetivos comunes.
Ms an, casi diramos que su medio natural sonlos entornos complejos, donde los
resultados se deben obtener a corto plazo y los requisitos para alcanzar las metas son
cambiantes.
Tambin aporta soluciones valiosas en situaciones que pueden obstaculizar el normal ritmo
de un proyecto, como por ejemplo cuando las fechas de entrega se alargan demasiado, los
costes estn por encima de lo presupuestado o la calidad del producto no es la que el cliente
ha solicitado. Esto explica que los principios bsicos de la metodologa Scrum son la
innovacin, la competitividad, la flexibilidad y, sobre todo, la productividad y la
unidad de los equipos involucrados en un proyecto.

Qu son las iteraciones en la metodologa

Scrum?
La caracterstica principal de Scrum es que las tareas de un proyecto se realizan en entregas
parciales y regulares. De ah que el proyecto se efecte en bloques temporales, cuyos plazos de
ejecucin pueden variar de dos semanas a un mes. A estos bloques se les conoce como iteraciones. El
plazo de cada iteracin puede definirse en funcin de lo solicitado por los clientes y la capacidad
productiva de los equipos. El punto de partida es la definicin de los objetivos del proyecto, los
cuales tienen que ser priorizados de antemano por el cliente. La jerarquizacin de los objetivos
definir las acciones ms importantes en cada proyecto y ayudar a trazar el itinerario del mismo, dando
lugar, de paso, a las iteraciones.

El proceso de Scrum: cmo aplicar las

iteraciones
Pero vayamos al proceso de diseo e implementacin de la metodologa Scrum, que est dividido en tres
etapas:
1) Planificacin de la iteracin: Esta etapa tiene a su vez dos momentos. En el primero, los
responsables del proyecto se renen con el cliente y ste les presenta la lista de requisitos y las
prioridades. Con base en esto, las dos partes disean las iteraciones y definen los plazos de entrega.
Luego, en una reunin posterior, los miembros del equipo definen las tareas y designan los responsables
para cada una de ellas.
2) Ejecucin:
El equipo de trabajo realiza reuniones diarias (15 minutos como mximo) para poner en comn la
evolucin de las tareas designadas, los obstculos que han encontrado durante la ejecucin y, a la vez,
disear posibles adaptaciones o soluciones a los fallos. El lder se encargar de que sus colaboradores no
bajen su productividad. A su vez, el cliente puede intervenir en las reuniones si lo considera necesario.
3) Inspeccin y adaptacin:
Esta etapa tiene lugar el ltimo da del proceso. El equipo de trabajo, en cabeza de su lder, presenta al
cliente los resultados con base a la lista de prioridades que ste ha entregado en la primera instancia del
proyecto. Teniendo en cuenta los cambios en el contexto y la eficacia de los resultados, el cliente
decidir si es suficiente o si deben ser adoptadas algunas medidas de adaptacin.
Si los resultados son satisfactorios, el equipo de trabajo realizar una ltima reunin para evaluar lo que
ha sido el proceso hasta ese momento.

Al inicio de cada uno de estos sprints se produce una reunin en la que se establecen los
objetivos a cumplir durante ese sprint.
En esta reunin existen tres figuras principales:

Product Owner. Es el encargado de representar la voz del cliente o Stakeholder.

Debe colocar aquellas tareas a realizar en una lista de objetivos priorizada, a la que se conoce
como product backlog.

Scrum Master (facilitador). Su tarea es facilitar que los miembros del equipo
consigan llegar al objetivo establecido. Para ello debe eliminar obstculos que puedan impedir
cumplir con las tareas y coordinar los equipos. Es importante destacar que no se trata del lder
de ninguno de los equipos, dado que cada uno de ellos se autoorganiza sin necesidad de
tener un jefe externo.

Equipo de desarrollo. Son los encargados de ejecutar las tareas. Se rigen por una
organizacin horizontal y colaborativa.
Al final de cada uno de estos sprints se produce una nueva reunin llamada retrospectiva del
sprint o sprint retrospective en la cual se analiza el grado de cumplimiento de los objetivos
fijados, los cambios que se han debido realizar durante la ejecucin del trabajo y se analiza
todo el proceso en un intento de aplicar el principio de mejora constante (kaizen).

Documentos del Scrum

Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene
descripciones genricas de todos los requerimientos, funcionalidades deseables,
etc. priorizadas segn su valor para el negocio (business value). Es el qu va a ser
construido. Es abierto y cualquiera puede modificarlo.

Sprint backlog

El sprint backlog es un documento detallado donde se describe el cmo el equipo

va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen
en horas con ninguna tarea de duracin superior a 16 horas. Si una tarea es
mayor de 16 horas, deber ser rota en mayor detalle. Las tareas en el sprint
backlog nunca son asignadas, son tomadas por los miembros del equipo del modo
que les parezca oportuno.

Burn down
La burn down chart es una grfica mostrada pblicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.
Dibujando una lnea que conecte los puntos de todos los Sprints completados,
podremos ver el progreso del proyecto. Lo normal es que esta lnea sea
descendente, hasta llegar al eje horizontal, momento en el cual el proyecto se ha
terminado.

Reuniones en Scrum

FORMAS DE INSPECCION:
Daily Scrum

La reunin diaria de 15 minutos comienza puntualmente a su hora.

Todos los asistentes deben mantenerse de pie.

La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los

das.

Durante la reunin, cada miembro del equipo contesta a tres preguntas:

1.

Qu has hecho desde ayer?

2.

Qu es lo que ests planeando hacer hoy?

3.

Has tenido algn problema que te haya impedido alcanzar tu objetivo?

Reunin de Planificacin del Sprint (sprint planning meeting)

Al inicio del ciclo Sprint (cada 15 o 30 das), una Reunin de Planificacin

del Sprint se lleva a cabo.

Seleccionar qu trabajo se har

Ocho horas como lmite

Al final del ciclo Sprint, dos reuniones se llevarn a cabo: la Reunin de

Revisin del Sprint y la Retrospectiva del Sprint

Reunin de Revisin del Sprint (sprint review meeting)

Revisar el trabajo que fue completado y no completado.

Presentar el trabajo a los interesados.

El trabajo incompleto no puede ser demostrado.

Cuatro horas como lmite

Retrospectiva del Sprint (sprint retrospective)

Despus de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual
todos los miembros del equipo dejan sus impresiones sobre el sprint recin
superado. El propsito de la retrospectiva es realizar una mejora continua del
proceso. Esta reunin tiene un tiempo fijo de cuatro horas.