Marco de Trabajo SCRUM

�ndice
1 SCRUM
2 Historia
3 Caracter�sticas de Scrum
3.1 Principales caracter�sticas de Scrum
4 Roles en Scrum
4.1 Roles Principales
4.2 Roles Auxiliares
5 Flujo de trabajo
5.1 Sprint
5.2 Planificaci�n de sprint
5.3 Scrum diario
5.4 Revisi�n de sprint
5.5 Retrospectiva del sprint
6 Beneficios de Scrum
7 Documentos
7.1 Product backlog
7.2 Sprint backlog
7.3 Burn down chart
8 Notas
9 Referencias
10 V�ase tambi�n
11 Enlaces externos
SCRUM
Scrum es un marco de trabajo para desarrollo �gil de software.

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

pr�cticas para trabajar colaborativamente, en equipo y obtener el mejor resultado
posible de proyectos, caracterizado por:1?

Adoptar una estrategia de desarrollo incremental, en lugar de la planificaci�n y

ejecuci�n completa del producto.
Basar la calidad del resultado m�s en el conocimiento t�cito de las personas en
equipos auto organizados, que en la calidad de los procesos empleados.
Solapar las diferentes fases del desarrollo, en lugar de realizar una tras otra en
un ciclo secuencial o en cascada.
Historia
Este modelo fue identificado y definido por Ikujiro Nonaka y Takeuchi a principios
de los 80, al analizar c�mo desarrollaban los nuevos productos las principales
empresas de manufactura tecnol�gica: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother,
3M y Hewlett-Packard (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 formaci�n de mel� (scrum en ingl�s) de los jugadores de Rugby, a
ra�z de lo cual qued� acu�ado el t�rmino �scrum� para referirse a ella.

Aunque esta forma de trabajo surgi� en empresas de productos tecnol�gicos, es

apropiada para cualquier tipo de proyecto 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 (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 hab�a empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa
Easel Corporation (compa��a que en los macrojuegos de compras y fusiones, se
integrar�a en VMARK, y luego en Informix y finalmente en Ascential Software
Corporation).

Caracter�sticas de Scrum
Scrum es un marco de trabajo que define un conjunto de pr�cticas 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 'Scrum Master, que procura facilitar la
aplicaci�n de scrum y gestionar cambios, el Product Owner, que representa a los
stakeholders (interesados externos o internos), y el Team (equipo) que ejecuta el
desarrollo y dem�s elementos relacionados con �l.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida
por el equipo y debe ser lo m�s corta posible), el equipo crea un incremento de
software potencialmente entregable (utilizable). El conjunto de caracter�sticas 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 reuni�n de Sprint Planning. Durante esta reuni�n,
el Product Owner identifica los elementos del Product Backlog que quiere ver
completados y los da a conocer al equipo. Entonces, el equipo conversa con el
Product Owner buscando la claridad y magnitud adecuadas (Cumpliendo el INVEST) para
luego determinar la cantidad de ese trabajo que puede comprometerse a completar
durante el siguiente sprint.2? Durante el sprint, nadie puede cambiar el Sprint
Backlog, lo que significa que los requisitos est�n congelados durante el sprint.3?

Scrum permite la creaci�n de equipos auto organizados impulsando la co-localizaci�n

de todos los miembros del equipo, y la comunicaci�n verbal entre todos los miembros
y disciplinas involucrados en el proyecto.

Principales caracter�sticas de Scrum

Gesti�n regular de las expectativas del cliente, resultados anticipados,
flexibilidad y adaptaci�n, retorno de inversi�n, mitigaci�n de riesgos,
productividad y calidad, alineamiento entre cliente y equipo, por �ltimo, equipo
motivado.
Se hace uso de equipos auto-dirigidos y auto-organizados.
Se realiza a diario una reuni�n de Scrum, que es una reuni�n de avance diaria que
no dura m�s de 15 minutos con el objetivo de obtener realimentaci�n sobre las
tareas del equipo y los obst�culos que se presentan.
Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera
regular en un conjunto de buenas pr�cticas 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; requiere
muy poco esfuerzo para comenzarse a utilizar. As�, si se utiliza una pizarra con
notas autoadhesivas cualquier miembro del equipo podr� ver tres columnas: trabajo
pendiente ("backlog"), tareas en proceso ("in progress") y hecho ("done"). De un
solo vistazo, una persona puede ver en qu� est�n trabajando los dem�s en un momento
determinado.4?

Roles en Scrum
Roles Principales
Product Owner
El Product Owner se asegura de que el equipo Scrum trabaje de forma adecuada desde
la perspectiva del negocio. El Product Owner ayuda al usuario a escribir las
historias 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
obst�culos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster
no es el l�der del equipo (porque ellos se auto-organizan), sino que act�a como una
protecci�n 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. Es recomendable un
peque�o equipo de 3 a 9 personas con las habilidades transversales necesarias para
realizar el trabajo (an�lisis, dise�o, desarrollo, pruebas, documentaci�n, etc).
Roles Auxiliares
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 aproximaci�n �gil es la
pr�ctica de involucrar en el proceso a los usuarios, expertos del negocio y otros
interesados ("stakeholders"). Es importante que esa gente participe y entregue
retroalimentaci�n con respecto a la salida del proceso a fin de revisar y planear
cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Son las personas que hacen posible el proyecto y para quienes el proyecto producir�
el beneficio acordado que justifica su desarrollo. S�lo participan directamente
durante las revisiones del "sprint".
Administradores (Managers)
Son los responsables de establecer el entorno para el desarrollo del proyecto.
Flujo de trabajo
Sprint
El Sprint es el per�odo en el cual se lleva a cabo el trabajo en s�. Es recomendado
que la duraci�n de los sprints sea constante y definida por el equipo con base en
su propia experiencia. Se puede comenzar con una duraci�n de sprint en particular
(2 o 3 semanas) e ir ajust�ndolo 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 que, potencialmente, se
puede entregar al cliente2?.

As� mismo, se recomienda no agregar objetivos al sprint o sprint backlog a menos

que su falta amenace al �xito del proyecto. La constancia permite la concentraci�n
y mejora la productividad del equipo de trabajo.

El tiempo m�nimo de un Sprint es de dos (2) semanas y el m�ximo es de cuatro (4)

semanas.

Planificaci�n de sprint
Al comienzo de un sprint, el equipo de scrum tiene un evento de planificaci�n de
sprint.2?

Uno de los objetivos de la reuni�n es identificar y comunicar cu�nto del trabajo es

probable que se realice durante el actual Sprint.
Scrum diario
Tambi�n llamado Daily Standup. Cada d�a durante la iteraci�n, tiene lugar una
reuni�n de estado del proyecto. Su objetivo es que los miembros del equipo se
mantengan actualizados unos a otros sobre el trabajo de cada uno desde el ultimo
standup, qu� problemas han encontrado o preveen encontrar, y qu� planean hacer.2?

La reuni�n tiene una duraci�n fija de entre 5 y 15 minutos.

Se recomienda hacerla de pie para recordar que debe ser una reuni�n breve y
centrada en su objetivo, sin divagaciones. Es obligatorio parar todo lo que se est�
haciendo para concentrarse en la reuni�n.
Si se requiere ampliar un tema, se har� tras el Daily Standup, pero no se
interrumpe la din�mica del Standup para elaborar una discusi�n.
Se hace siempre a la misma hora y en el mismo lugar. Si falta alguien, no se
pospone la reuni�n.
Revisi�n de sprint
Al final de un sprint, el equipo realiza dos eventos: la revisi�n del sprint y la
retrospectiva del sprint.2?

En la reuni�n de revisi�n de sprint se presentan los trabajos completados y su

duraci�n no deber�a ser superior a 4 horas para un Sprint de 1 mes.

Retrospectiva del sprint

Despu�s 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 reci�n
superado. El prop�sito de la retrospectiva es realizar una mejora continua del
proceso. Esta reuni�n tiene un tiempo fijo de cuatro horas.

Beneficios de Scrum
Flexibilidad a cambios. Gran capacidad de reacci�n ante los cambiantes
requerimientos generados por las necesidades del cliente o la evoluci�n del
mercado. El marco de trabajo est� dise�ado para adecuarse a las nuevas exigencias
que implican proyectos complejos.
Reducci�n del Time to Market. El cliente puede empezar a utilizar las
caracter�sticas m�s importantes del proyecto antes de que est� completamente
terminado.
Mayor calidad del software. El trabajo met�dico y la necesidad de obtener una
versi�n de trabajo funcional despu�s de cada iteraci�n, ayuda a la obtenci�n de un
software de alta calidad.
Mayor productividad. Se logra, entre otras razones, debido a la eliminaci�n de la
burocracia y la motivaci�n del equipo proporcionado por el hecho de que pueden
estructurarse de manera aut�noma.
Maximiza el retorno de la inversi�n (ROI). Creaci�n de software solamente con las
prestaciones que contribuyen a un mayor valor de negocio gracias a la priorizaci�n
por retorno de inversi�n.
Predicciones de tiempos. A trav�s de este marco de trabajo se conoce la velocidad
media del equipo por sprint, con lo que es posible estimar de manera f�cil cuando
se podr� hacer uso de una determinada funcionalidad que todav�a est� en el Backlog.
Reducci�n de riesgos El hecho de desarrollar, en primer lugar, las funcionalidades
de mayor valor y de saber la velocidad a la que el equipo avanza en el proyecto,
permite despejar riesgos efectivamente de manera anticipada.5?
Documentos
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
gen�ricas de funcionalidades deseables, priorizadas seg�n su retorno sobre la
inversi�n (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 estimaci�n ayuda al product owner a ajustar la l�nea temporal (KEV)
y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos
caracter�sticas tienen el mismo valor de negocio la que requiera menor tiempo de
desarrollo tendr� probablemente m�s prioridad, debido a que su ROI ser� m�s alto.

Sprint backlog
El sprint backlog es el subconjunto de requisitos que ser�n desarrollados durante
el siguiente sprint. Al definir el sprint backlog, se describe el c�mo 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 duraci�n 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

La burn down chart es una gr�fica mostrada p�blicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.
Dibujando una l�nea que conecte los puntos de todos los Sprints completados,
podremos ver el progreso del proyecto. Lo normal es que esta l�nea sea descendente
(en casos en que todo va bien en el sentido de que los requisitos est�n bien
definidos desde el principio y no var�an nunca) hasta llegar al eje horizontal,
momento en el cual el proyecto se ha terminado (no hay m�s requisitos pendientes de
ser completados en el Backlog). Si durante el proceso se a�aden 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.

Notas
�Qu� es SCRUM�. Proyectos �giles. 4 de agosto de 2008. Consultado el 8 de abril de
2019.
Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004,
163pp, ISBN 0-7356-1993-X
M�todos �giles. Scrum, Kanban, Lean, Carmen Lasa, Rafael de las Heras, Alonso
�lvarez, Anaya, 2017, 400pp, ISBN 978-8441538887
Leader Summaries (ed.). �Resumen del libro Scrum, de Jeff Sutherland�. Consultado
el 25 de enero de 2016.
�Beneficios de Scrum�. Proyectos �giles. 4 de agosto de 2008. Consultado el 17 de
abril de 2017.
Referencias
(PDF) Rising, L., Janoff, 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) Jeff 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
V�ase tambi�n
Agilm�tica
Arquitectura orientada a servicios
Back office
Ciclo de vida del producto
Desarrollo �gil de software
Desarrollo de software
Kanban
Lean software development
Enlaces externos
Curso SCRUM para Product Owners
Video Estimaci�n en SCRUM
Libro gratuito sobre Scrum
"Scrum y XP desde las trincheras", traducci�n de "Scrum and XP from the trenches"
por Henrik Kniberg
Art�culo de introducci�n a Scrum
Art�culo explicativo de la metodolog�a Scrum
Varios articulos sobre muchos marcos de trabajo y metodo agile
Introducci�n de Scrum de la mano de un trainer oficial de scrum.org Jer�nimo
Palacios
Simulador para pasar los ex�menes de las certificaciones de Scrum
Scrum Master: Las metodolog�as �giles que llevan tu proyecto al �xito