Qu es SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas

prcticaspara trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene
origen en un estudio de la manera de trabajar de equipos altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por
el beneficio que aportan al receptor del proyecto. Por ello, Scrum est especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener
resultados pronto, donde los requisitos son cambiantes o poco definidos, donde
la innovacin, la competitividad, laflexibilidad y la productividad son
fundamentales.
Scrum tambin se utiliza para resolver situaciones en que no se est entregando al
cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reaccin ante la competencia, cuando la moral de los equipos es baja y la
rotacin alta, cuando es necesario identificar y solucionar ineficiencias
sistemticamente o cuando se quiere trabajar utilizando un proceso especializado
en el desarrollo de producto.
Ver en detalle cuales son los beneficios de Scrum, sus fundamentos y sus requisitos.

El proceso
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de
un mes natural y hasta de dos semanas, si as se necesita). 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. De manera regular el cliente puede maximizar la utilidad de lo que se
desarrolla y el retorno de inversinmediante la replanificacin de objetivos del
producto, que realiza durante la iteracin con vista a las siguientes iteraciones.
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:
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 autoasignan las tareas.
Ejecucin de la iteracin
1.

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.
Inspeccin y adaptacin

El ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos

partes:
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.
1.

Cmo funciona Scrum

Scrum
Vase tambin: medio scrum

Ciclos de desarrollo.

Ficha sinptica

Marco de Trabajo SCRUM

Scrum es el nombre con el que se denomina a los marcos de desarrollo giles caracterizados
por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificacin y

ejecucin completa del producto.

Basar la calidad del resultado ms en el conocimiento tcito de las personas en

equipos autoorganizados, que en la calidad de los procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra
en un ciclo secuencial o de cascada.
ndice
[ocultar]

1 Historia

2 Caractersticas de Scrum

3 Roles en Scrum
o

3.1 Roles Principales

3.2 Roles Auxiliares

4 Reuniones en Scrum
o

4.1 Daily Scrum o Stand-up meeting

4.2 Scrum de Scrum

4.3 Reunin de Planificacin del Sprint (Sprint Planning Meeting)

4.4 Reunin de Revisin del Sprint (Sprint Review Meeting)

4.5 Retrospectiva del Sprint (Sprint Retrospective)

5 Sprint

6 Beneficios de Scrum

7 Documentos
o

7.1 Product backlog

7.2 Sprint backlog

7.3 Burn down chart

8 Notas

9 Referencias

10 Vase tambin

11 Enlaces externos

Historia[editar]
Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de
los 80, al analizar cmo desarrollaban los nuevos productos las principales empresas de
manufactura tecnolgica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y HewlettPackard (Nonaka & Takeuchi, The New New Product Development Game, 1986)
En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el
avance en formacin de mel (scrum en ingls) de los jugadores de Rugby, a raz de lo cual
qued acuado el trmino scrum para referirse a ella.
Aunque esta forma de trabajo surgi en empresas de productos tecnolgicos, es apropiada
para proyectos con requisitos inestables y para los que requieren rapidez y flexibilidad,
situaciones frecuentes en el desarrollo de determinados sistemas de software.
En 1995 Ken Schwaber present Scrum Development Process en OOPSLA 95 (ObjectOriented Programming Systems & Applications conference)(SCRUM Development Process),
un marco de reglas para desarrollo de software, basado en los principios de scrum, y que l
haba empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation

(compaa que en los macrojuegos de compras y fusiones, se integrara en VMARK, y luego

en Informix y finalmente en Ascential Software Corporation)

Caractersticas de Scrum[editar]
SCRUM es un modelo de referencia que define un conjunto de prcticas y roles, y que puede
tomarse como punto de partida para definir el proceso de desarrollo que se ejecutar durante
un proyecto. Los roles principales en Scrum son el ScrumMaster, que procura facilitar la
aplicacin de scrum y gestionar cambios, el ProductOwner, que representa a
los stakeholders (interesados externos o internos), y el Team que ejecuta el desarrollo y
dems elementos relacionados con el. Durante cada sprint, un periodo entre una y cuatro
semanas (la magnitud es definida por el equipo y debe ser lo mas corta posible), el equipo
crea un incremento de software potencialmente entregable(utilizable). El conjunto de
caractersticas que forma parte de cada sprint viene del Product Backlog, que es un conjunto
de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog
Item). Los elementos del Product Backlog que forman parte del sprint se determinan durante la
reunin de Sprint Planning. Durante esta reunin, el Product Owner identifica los elementos
del Product Backlog que quiere ver completados y los hace del conocimiento del equipo.
Entonces, el equipo conversa con el Product Owner buscando claridad y magnitud adecuadas
(Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede
comprometerse a completar durante el siguiente sprint. 1 Durante el sprint, nadie puede
cambiar el Sprint Backlog, lo que significa que los requisitos estn congelados durante el
sprint.
Scrum permite la creacin de equipos autoorganizados impulsando la co-localizacin de todos
los miembros del equipo, y la comunicacin verbal entre todos los miembros y disciplinas
involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes
pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamadorequirements
churn), y que los desafos impredecibles no pueden ser fcilmente enfrentados de una forma
predictiva y planificada. Por lo tanto, Scrum adopta una aproximacin pragmtica, aceptando
que el problema no puede ser completamente entendido o definido, y centrndose en
maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos
emergentes.
Las caractersticas ms marcadas que se logran notar en Scrum seran: gestin regular de las
expectativas del cliente, resultados anticipados, flexibilidad y adaptacin, retorno de inversin,
mitigacin de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por ltimo
equipo motivado. Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado
de manera regular en un conjunto de buenas prcticas para el trabajo en equipo y de esa
manera obtener resultados posibles.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van
desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores
ventajas de Scrum es que es muy fcil de aprender, y requiere muy poco esfuerzo para
comenzarse a utilizar.

Roles en Scrum[editar]
Roles Principales[editar]
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum
trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner
escribehistorias de usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los
obstculos que impiden que el equipo alcance el objetivo del sprint.
El ScrumMaster no es el lder del equipo (porque ellos se auto-organizan), sino que
acta como una proteccin entre el equipo y cualquier influencia que le distraiga. El
ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El
ScrumMaster es el que hace que las reglas se cumplan.
Equipo de desarrollo
El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 3 a
9 personas con las habilidades transversales necesarias para realizar el trabajo
(anlisis, diseo, desarrollo, pruebas, documentacin, etc).

Roles Auxiliares[editar]
Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol
formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo
deben ser tomados en cuenta. Un aspecto importante de una aproximacin gil es
la prctica de involucrar en el proceso a los usuarios, expertos del negocio y otros
interesados (stakeholders). Es importante que esa gente participe y entregue
retroalimentacin con respecto a la salida del proceso a fin de revisar y planear
cada sprint.
Stakeholders (Clientes, Proveedores, Vendedores, etc)
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producir
el beneficio acordado que justifica su produccin. Slo participan directamente durante
las revisiones del sprint.
Administradores (Managers)
Es la gente que establece el ambiente para el desarrollo del producto.

Reuniones en Scrum[editar]

Daily Scrum o Stand-up meeting[editar]

Cada da de un sprint, se realiza la reunin sobre el estado de un
proyecto. Esto se llama daily standup o Stand-up meeting. El scrum tiene
unas guas especficas:

La reunin comienza puntualmente a su hora.

Todos son bienvenidos, pero slo los involucrados en el proyecto

pueden hablar.

La reunin tiene una duracin fija de 15 minutos, de forma

independiente del tamao del equipo.

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: 2

Qu has hecho desde ayer?

Qu es lo que hars para maana?

Has tenido algn problema que te haya impedido alcanzar tu

objetivo? (Es el papel del ScrumMaster recordar estos
impedimentos).

Scrum de Scrum[editar]
Estas reuniones por lo general se realizan cuando en la organizacin
existan varios equipos Scrum, y les permiten discutir su trabajo,
enfocndose especialmente en reas de solapamiento e integracin. Se
hace normalmente cada da normalmente despus del Daily Scrum o
mximo cada dos das. Asiste una persona asignada por cada equipo
Scrum.
La agenda ser la misma que la del Daily Scrum, aadiendo adems las
siguientes cuatro preguntas:

Qu ha hecho tu equipo desde nuestra ltima reunin?

Qu har tu equipo antes que nos volvamos a reunir?

Hay algo que demora o estorba a tu equipo?

Ests a punto de poner algo en el camino del otro equipo?

Reunin de Planificacin del Sprint (Sprint Planning Meeting)

[editar]
Al inicio de cada ciclo de Sprint (cada 15 o 30 das), se lleva a cabo
una reunin de planificacin del Sprint. Se pretende:

Seleccionar qu trabajo se har.

Preparar, con el equipo completo, el Sprint Backlog que detalla el

tiempo que llevar hacer el trabajo.

Identificar y comunicar cunto del trabajo es probable que se realice

durante el actual Sprint.

Realizarse esta planificacin en ocho horas como tiempo lmite.

Al final del ciclo Sprint se hacen dos reuniones ms: la reunin de

revisin del Sprint y la retrospectiva del Sprint.

Reunin de Revisin del Sprint (Sprint Review Meeting)

[editar]

Revisar el trabajo que fue completado y no completado

Presentar el trabajo completado a los interesados (alias demo)

El trabajo incompleto no puede ser demostrado

Cuatro horas como lmite

Retrospectiva del Sprint (Sprint Retrospective) [editar]

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.

Sprint[editar]

El Sprint es el perodo en el cual se lleva a cabo el trabajo en s. Es

recomendado que la duracin de los sprints sea constante y definida por
el equipo con base en su propia experiencia. Se puede comenzar con una
duracin de sprint en particular (2 o 3 semanas) e ir ajustndolo con base
en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada
sprint, el equipo deber presentar los avances logrados, y el resultado
obtenido es un producto potencialmente entregable al cliente. Asimismo,
se recomienda no agregar objetivos al sprint o sprint backlog a menos
que la falta de estos objetivos amenace al xito del proyecto. La
constancia permite la concentracin y mejora la productividad del equipo
de trabajo.

Beneficios de Scrum[editar]

Flexibilidad a cambios. Gran capacidad de reaccin ante los cambiantes

requerimientos generados por las necesidades del cliente o la evolucin del
mercado. El marco de trabajo est diseado para adecuarse a las nuevas
exigencias que implican proyectos complejos.

Reduccin del Time to Market. El cliente puede empezar a utilizar las

caractersticas ms importantes del proyecto antes de que est completamente
terminado.

Mayor calidad del software. El trabajo metdico y la necesidad de obtener una

versin de trabajo funcional despus de cada iteracin, ayuda a la obtencin de un
software de alta calidad.

Mayor productividad. Se logra, entre otras razones, debido a la eliminacin de la

burocracia y la motivacin del equipo proporcionado por el hecho de que pueden
estructurarse de manera autnoma.

Maximiza el retorno de la inversin (ROI). Creacin de software solamente con

las prestaciones que contribuyen a un mayor valor de negocio gracias a la
priorizacin por retorno de inversin.

Predicciones de tiempos. A travs de este marco de trabajo se conoce la

velocidad media del equipo por sprint, con lo que es posible estimar de manera
fcil cuando se podr hacer uso de una determinada funcionalidad que todava
est en el Backlog.

Reduccin de riesgos El hecho de llevar a cabo las funcionalidades de mayor

valor en primer lugar y de saber la velocidad a la que el equipo avanza en el
proyecto, permite despejar riesgos efectivamente de manera anticipada. 3

Documentos[editar]
Product backlog[editar]
El product backlog se trata como un documento de alto nivel para
todo el proyecto. Es el conjunto de todos los requisitos de proyecto, el
cual contiene descripciones genricas de funcionalidades deseables,
priorizadas segn su retorno sobre la inversin (ROI) . Representa
el qu va a ser construido en su totalidad. Es abierto y solo puede ser
modificado por el product owner. Contiene estimaciones realizadas a
grandes rasgos, tanto del valor para el negocio, como del esfuerzo de
desarrollo requerido. Esta estimacin ayuda al product owner a
ajustar la lnea temporal (KEV) y, de manera limitada, la prioridad de
las diferentes tareas. Por ejemplo, si dos caractersticas tienen el
mismo valor de negocio la que requiera menor tiempo de desarrollo
tendr probablemente ms prioridad, debido a que su ROI ser ms
alto.

Sprint backlog[editar]
El sprint backlog es el subconjunto de requisitos que sern
desarrollados durante el siguiente sprint. Al definir el sprint backlog,
se describe el cmo el equipo va a implementar los requisitos durante
el sprint. Por lo general los requisitos se subdividen en tareas, a las
cuales se asignan ciertas horas de trabajo pero ninguna tarea con
una duracin superior a 16 horas. Si una tarea es mayor de 16 horas,
deber ser dividida en otras menores. Las tareas en el sprint
backlog nunca son asignadas, son tomadas por los miembros del
equipo del modo que les parezca adecuado.

Burn down chart[editar]

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 (en casos en
que todo va bien en el sentido de que los requisitos estn bien
definidos desde el principio y no varan nunca) hasta llegar al eje
horizontal, momento en el cual el proyecto se ha terminado (no hay
ms requisitos pendientes de ser completados en el Backlog). Si
durante el proceso se aaden nuevos requisitos la recta tendr
pendiente ascendente en determinados segmentos, y si se modifican

algunos requisitos la pendiente variar o incluso valdr cero en

algunos tramos.