Scrum

Solapamiento de las diferentes fases del desarrollo,

en lugar de realizar una tras otra en un ciclo secuencial o de cascada.

1 Historia
Este modelo fue identicado y denido 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 Hewlett-Packard
(Nonaka & Takeuchi, The New New Product Development Game, 1986)

Ciclos de desarrollo.

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 exibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.
Ficha sinptica

En 1995 Ken Schwaber present Scrum Development

Process en OOPSLA 95 (Object-Oriented 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 Je Sutherland en su empresa Easel Corporation (compaa que en
los macrojuegos de compras y fusiones, se integrara en
VMARK, y luego en Informix y nalmente en Ascential
Software Corporation)

2 Caractersticas de Scrum

Marco de Trabajo SCRUM

Scrum es el nombre con el que se denomina a los marcos SCRUM es un modelo de referencia que dene un conjunto de prcticas y roles, y que puede tomarse como
de desarrollo giles caracterizados por:
punto de partida para denir el proceso de desarrollo que
Adoptar una estrategia de desarrollo incremental, en se ejecutar durante un proyecto. Los roles principales en
lugar de la planicacin y ejecucin completa del Scrum son el ScrumMaster, que procura facilitar la aplicacin de scrum y gestionar cambios, el ProductOwner,
producto.
que representa a los stakeholders (interesados externos o
Basar la calidad del resultado ms en el conocimien- internos), y el Team que ejecuta el desarrollo y dems eleto tcito de las personas en equipos autoorganizados, mentos relacionados con el. Durante cada sprint, un peque en la calidad de los procesos empleados.
riodo entre una y cuatro semanas (la magnitud es denida
1

4 REUNIONES EN SCRUM

por el equipo y debe ser lo mas corta posible), el equipo

El Product Owner escribe historias de usuario, las
crea un incremento de software potencialmente entregaprioriza, y las coloca en el Product Backlog.
ble (utilizable). El conjunto de caractersticas que forma
parte de cada sprint viene del Product Backlog, que es un ScrumMaster (o Facilitador) El Scrum es facilitado
conjunto de requisitos de alto nivel priorizados que depor un ScrumMaster, cuyo trabajo primario es elinen el trabajo a realizar (PBI, Product Backlog Item).
minar los obstculos que impiden que el equipo alLos elementos del Product Backlog que forman parte del
cance el objetivo del sprint. El ScrumMaster no es
sprint se determinan durante la reunin de Sprint Planel lder del equipo (porque ellos se auto-organizan),
ning. Durante esta reunin, el Product Owner identica
sino que acta como una proteccin entre el equilos elementos del Product Backlog que quiere ver complepo y cualquier inuencia que le distraiga. El Scrumtados y los hace del conocimiento del equipo. Entonces,
Master se asegura de que el proceso Scrum se utiliza
el equipo conversa con el Product Owner buscando claricomo es debido. El ScrumMaster es el que hace que
dad y magnitud adecuadas (Cumpliendo el INVEST) palas reglas se cumplan.
ra 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, Equipo de desarrollo El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 3
lo que signica que los requisitos estn congelados durana 9 personas con las habilidades transversales necete el sprint.
sarias para realizar el trabajo (anlisis, diseo, desaScrum permite la creacin de equipos autoorganizados
rrollo, pruebas, documentacin, etc).
impulsando la co-localizacin de todos los miembros del
equipo, y la comunicacin verbal entre todos los miembros y disciplinas involucrados en el proyecto.
3.2 Roles Auxiliares
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 llamado requirements churn), y que los desafos impredecibles no
pueden ser fcilmente enfrentados de una forma predictiva y planicada. Por lo tanto, Scrum adopta una aproximacin pragmtica, aceptando que el problema no puede
ser completamente entendido o denido, y centrndose
en maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos emergentes.

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 n de revisar y planear cada sprint.

Las caractersticas ms marcadas que se logran notar

en Scrum seran: gestin regular de las expectativas del Stakeholders (Clientes, Proveedores, Vendedores, etc)
Se reere a la gente que hace posible el proyecto
cliente, resultados anticipados, exibilidad y adaptacin,
y para quienes el proyecto producir el benecio
retorno de inversin, mitigacin de riesgos, productiviacordado que justica su produccin. Slo pardad y calidad, alineamiento entre cliente y equipo, por
ticipan directamente durante las revisiones del
ltimo equipo motivado. Cada uno de estos puntos mensprint.
cionados 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.
Administradores (Managers) Es la gente que establece el ambiente para el desarrollo del producto.
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 4 Reuniones en Scrum
aprender, y requiere muy poco esfuerzo para comenzarse
a utilizar.

4.1 Daily Scrum o Stand-up meeting

3
3.1

Roles en Scrum

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

Roles Principales

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.

La reunin comienza puntualmente a su hora.

Todos son bienvenidos, pero slo los involucrados
en el proyecto pueden hablar.

4.4

Reunin de Revisin del Sprint (Sprint Review Meeting)

La reunin tiene una duracin ja de 15 minutos, de 4.4

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?

Reunin de Revisin del Sprint (Sprint

Review Meeting)

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

Qu es lo que hars para maana?

Cuatro horas como lmite

Has tenido algn problema que te haya impedido
alcanzar tu objetivo? (Es el papel del ScrumMaster
recordar estos impedimentos).
4.5 Retrospectiva del Sprint (Sprint Re-

trospective)
4.2

Scrum de Scrum

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:

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 jo de cuatro
horas.

5 Sprint

El Sprint es el perodo en el cual se lleva a cabo el traba Qu ha hecho tu equipo desde nuestra ltima jo en s. Es recomendado que la duracin de los sprints
reunin?
sea constante y denida por el equipo con base en su propia experiencia. Se puede comenzar con una duracin de
Qu har tu equipo antes que nos volvamos a resprint en particular (2 o 3 semanas) e ir ajustndolo con
unir?
base en el ritmo del equipo, aunque sin relajarlo demasiado. Al nal de cada sprint, el equipo deber presentar
Hay algo que demora o estorba a tu equipo?
los avances logrados, y el resultado obtenido es un pro Ests a punto de poner algo en el camino del otro ducto potencialmente entregable al cliente. Asimismo, se
equipo?
recomienda no agregar objetivos al sprint o sprint backlog
a menos que la falta de estos objetivos amenace al xito
4.3 Reunin de Planicacin del Sprint del proyecto. La constancia permite la concentracin y
mejora la productividad del equipo de trabajo.

(Sprint Planning Meeting)

Al inicio de cada ciclo de Sprint (cada 15 o 30 das), se

lleva a cabo una reunin de planicacin 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.
Identicar y comunicar cunto del trabajo es probable que se realice durante el actual Sprint.
Realizarse esta planicacin en ocho horas como
tiempo lmite.
Al nal del ciclo Sprint se hacen dos reuniones ms: la
reunin de revisin del Sprint y la retrospectiva del Sprint.

6 Benecios de Scrum
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.

10 VASE TAMBIN
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

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.

7.3 Burn down chart

La burn down chart es una grca 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
denidos 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 modican algunos requisitos la pendiente variar o incluso valdr cero en algunos
tramos.

8 Notas
[1] Agile Project Management with Scrum, Ken Schwaber,
Microsoft Press, January 2004, 163pp, ISBN 0-73561993-X
[2] page 135

7.1

Product backlog

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

7.2

Sprint backlog

El sprint backlog es el subconjunto de requisitos que sern desarrollados durante el siguiente sprint. Al denir el
sprint backlog, se describe el cmo el equipo va a implementar los requisitos durante el sprint. Por lo general los

[3] http://www.proyectosagiles.org/beneficios-de-scrum

9 Referencias
(PDF) Rising, L., Jano, N.S. (2000). The Scrum
Software Development Process for Small Teams Retrieved March 15, 2007
(PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process Retrieved July
01, 2010
(video) Je Sutherland in Scrum Tuning: Lessons
learned from Scrum implementation at Google Retrieved 2007-12-15
(video) Ken Schwaber in Scrum et al. Retrieved
2008-01-19

10 Vase tambin
Agilmtica

5
Arquitectura orientada a servicios
Back oce
Ciclo de vida del producto
Desarrollo gil de software
Desarrollo de software
Kanban
Lean software development

11

Enlaces externos

Libro gratuito sobre Scrum

Traduccin de The Scrum Primer
Scrum y XP desde las trincheras, traduccin de
Scrum and XP from the trenches por Henrik Kniberg
Artculo de introduccin a Scrum
PPT reutilizable de introduccin a Scrum, original
de Mike Cohn, traduccin de Ernesto Grafeuille

12

12
12.1

TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

Text and image sources, contributors, and licenses

Text

Scrum Fuente: http://es.wikipedia.org/wiki/Scrum?oldid=81947871 Colaboradores: Julie, Rosarino, Ecelan, Dodo, Fritz11, Jgalgarra, Jdemarcos, Mescalier, RobotQuistnix, Alhen, Yrbot, Oscar ., FlaBot, BOTijo, Martingala, Maldoror, Jago84, Qwertyytrewqqwerty, CEM-bot,
Alexav8, Mansoft, Osepu, Juan.palacio, Ray iceman, Thijs!bot, Mpeinadopa, TXiKiBoT, Kijote, LKF, Jmbeas, VolkovBot, Technopat,
Penelopina, Galandil, Muro Bot, J.M.Domingo, Mushii, Loveless, Sindestino, Saulnoelm, Fanattiq, Poco a poco, Hernaldo, Susibel, Santiagobas, LucienBOT, MastiBot, Adelpine, Ginosbot, Diegusjaimes, Caskete, Saloca, Kamusclown, Mac1800, Ynnek, Billinghurst, Jmdmmx,
Xavier Albaladejo, C lamarque, Parlamento, Xqbot, Jkbw, Aquileaaquilea, Alex of Bcn, Dossier2, Raggha~eswiki, Fpablos, Jacorream, BokimBot, MondalorBot, Hprmedina, Moises003, RedBot, Solde, Leugim1972, PatruBOT, Tarawa1943, RNL89, GrouchoBot, EmausBot,
Savh, ZroBot, Hhiroshi, Fran.naranjo, EGA Futura, WikitanvirBot, Leoparra86, Diamondland, Hcquinteroz, Dieguen, Tokvo, Deibyod,
Edc.Edc, KLBot2, Obed.mx, Arturo.Van, N.garbezza, Allan Aguilar, Mega-buses, Takumi 1, YFdyh-bot, Rotlink, Maxie Ayala, Addbot,
Henaldog, Balles2601, Mhidalgolache, Treiscort, Miguel Visuete, Vegafernando, Jarould y Annimos: 169

12.2

Images

Archivo:Ciclos_de_desarrollo.png Fuente: http://upload.wikimedia.org/wikipedia/commons/8/82/Ciclos_de_desarrollo.png Licencia:

CC BY 2.5 Colaboradores: ? Artista original: ?
Archivo:Ficha_scrum.png Fuente: http://upload.wikimedia.org/wikipedia/commons/a/a5/Ficha_scrum.png Licencia: CC BY-SA 2.5 Colaboradores: ? Artista original: ?
Archivo:Scrumm.PNG Fuente: http://upload.wikimedia.org/wikipedia/commons/e/e5/Scrumm.PNG Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Maxie Ayala

12.3

Content license

Creative Commons Attribution-Share Alike 3.0