Leccin 4: Scrum

Scrum es una metodologa gil que proporciona un marco para la gestin de proyectos.
Podramos decir que hoy en da es la metodologa gil ms popular, y, de hecho, se ha
utilizado para desarrollar productos software desde principios de la dcada de los 90.
El conjunto de buenas prcticas de Scrum se aplica esencialmente a la gestin de
proyectos.
Por otro lado, aunque normalmente hablamos de la metodologa Scrum, lo correcto
sera decir el framework Scrum, porque realmente es un conjunto de buenas prcticas
que necesita su adaptacin en cada organizacin, o, incluso, a cada equipo. [1].

Como se indica en la Scrum Guide [1] , existen tres pilares en los que se basa:
Transparencia: todos los aspectos del proceso que afectan al resultado son visibles
para todos aquellos que administran dicho resultado. Por ejemplo, se utilizan pizarras
y otros mecanismos o tcnicas colaborativas para mejorar la comunicacin.
Inspeccin: se debe controlar con la frecuencia suficiente los diversos aspectos del
proceso para que puedan detectarse variaciones inaceptables en el mismo.
Revisin: el producto debe estar dentro de los lmites aceptables. En caso de
desviacin se proceder a una adaptacin del proceso y el material procesado.

El equipo en Scrum
Uno de los aspectos ms importantes en cualquier proyecto, y tambin en los proyectos
giles, es el establecimiento del equipo. Los roles y responsabilidades deben ser claros
y conocidos por todos los integrantes del mismo.
Cada equipo Scrum tiene tres roles:
Scrum Master: es el responsable de asegurar que el equipo Scrum siga las prcticas de
Scrum. Sus principales funciones son:
o Ayuda a que el equipo Scrum y la organizacin adopten Scrum.
o Liderar el equipo Scrum, buscando la mejora en la productividad y calidad de los
entregables.
o Ayudar a la autogestin del equipo.
o Gestiona e intenta resolver los impedimentos con los que el equipo se encuentra
para cumplir con las tareas del proyecto.
Propietario del Producto (ProductOwner): es la persona responsable de gestionar las
necesidades que sern satisfechas por el proyecto y asegurar el valor del trabajo que el
equipo lleva a cabo. Su aportacin al equipo se basa en:
o Recolectar las necesidades o historias de usuario.
o Gestionar y ordenar las necesidades (representadas por las historias de
usuario,descritas en la leccin 2 ).
o Aceptar el producto software al finalizar cada iteracin.
o Maximizar el retorno de inversin del proyecto.
Equipo de desarrollo: El equipo est formado por los desarrolladores, que convertirn las
necesidades del ProductOwner en un conjunto de nuevas funcionalidades, modificaciones o
incrementos del producto software final. El equipo de desarrollo tiene caractersticas
especiales:

o Auto-gestionado: el mismo equipo supervisa su trabajo. En Scrum se potenciarn

las reuniones del equipo (aqu tienes un post sobre ese tema), aumentando la
comunicacin. No existe el rol clsico de jefe de proyecto. El Scrum Master tiene otras
responsabilidades vistas en el apartado anterior.
o Multifuncional: no existen compartimientos estancos o especialistas, cada
integrante del equipo puede encargarse de tareas de programacin, pruebas,
despliegue, etc. Asimismo las personas pueden tener capacidades diferentes o
conocimientos ms profundos en diferentes reas. Lo importante es que cualquier
integrante del equipo sea capaz de realizar cualquier funcin.
o No distribuidos: es conveniente que el equipo se encuentre en el mismo lugar
fsico. Esto facilita la comunicacin y la autogestin que nace del mismo equipo.No
obstante se ha conseguido realizar proyectos Scrum con equipos distribuidos gracias a
herramientas de trabajo colaborativo (Hossain et al., 2009) [1].
o Tamao ptimo: un equipo de desarrollo Scrum (sin tener en cuenta al Product
Owner y al Scrum Master) estara compuesto por al menos tres personas. Con menos
de tres personas al interaccin decae y con ella la productividad del equipo. Como lmite
superior, con ms de nueve personas la interaccin hace que la autogestin sea muy
difcil de alcanzar.

El Product Backlog
La pila de producto o Product Backlog (utilizaremos las palabras en ingls al ser la forma
ms utilizada en los proyectos) en Scrum es uno de los elementos fundamentales. A partir
delProduct Backlog se logra tener una nica visin durante todo el proyecto. Y, por lo
tanto, los fallos en el Product Backlog repercutirn profundamente en el proyecto.
El Product Backlog consiste en un listado de historias del usuario que se incorporarn
al producto software a partir de incrementos sucesivos. Es decir, sera similar a un listado
de requisitos de usuario y representa lo que el cliente espera. Una de las principales
diferencias respecto de un proceso tradicional es la evolucin continua del Product
Backlog, buscando aumentar el valor del producto software desde el punto de vista del
negocio.
Para ello, este listado estar ordenado. Aunque no existe un criterio preestablecido en
Scrum para ordenar las historias de usuario, el ms aceptado es partir del valor que
aporta al negocio la implementacin de la historia de usuario. El responsable de
ordenar el Product Backlog es el Product Owner, aunque tambin puede ser ayudado o
recibir asesoramiento de otros roles como, por ejemplo, el Scrum Master y el equipo de
desarrollo.
Tal y como se describe en (Pichler, 2010) [1] un Product Backlog cuenta, esencialmente,
concuatro cualidades: debe estar detallado de manera adecuada, estimado, emergente y
priorizado:
Detallado adecuadamente: el grado de detalle depender de la prioridad. Las
historias de usuario que tengan una mayor prioridad se describen con ms detalle. De
esta manera las siguientes funcionalidades a ser implementadas se encuentran
descritas correctamente y son viables. Como consecuencia de esto, las necesidades
se descubren, se descomponen, y perfeccionan a lo largo de todo el proyecto.
Estimado: las estimaciones a menudo se expresan en das ideales o en trminos
abstractos. Saber el tamao de los elementos del Product Backlog ayuda a darle
prioridad y a planificar los siguientes pasos. Una de las tcnicas que se pueden
emplear para estimar las historias de usuario es el Planning Poker, que veremos en la
Leccin 4.
Emergente: las necesidades se van desarrollando y sus contenidos cambian con
frecuencia. Los nuevos elementos se descubren y se agregan a la lista teniendo en
cuenta los comentarios de los clientes y usuarios. As mismo, otros elementos podrn
ser modificados o eliminados.
Priorizado: los elementos del Product Backlog se priorizan. Los elementos ms
importantes y de mayor prioridad aparecen en la parte superior de la lista. Puede no
ser necesario priorizar todos los elementos en un primer momento, sin embargo s es
conveniente identificar los 15-20 elementos ms prioritarios.

El Sprint
Como hemos visto anteriormente, una de las bases de los proyectos giles es el desarrollo
mediante las iteraciones incrementales. En Scrum a cada iteracin se le denomina Sprint.
Scrum recomienda iteraciones cortas, por lo que cada Sprint durar entre 1 y 4 semanas. Y
como resultado se crear un producto software potencialmente entregable, un prototipo
operativo. Las caractersticas que van a implementarse en el Sprint provienen del Product
Backlog.

El equipo de desarrollo selecciona las historias de usuario que se van a desarrollar en el Sprint
conformando la pila de Sprint (Sprint Backlog). La definicin de cmo descomponer,
analizar o desarrollar este Sprint Backlog queda a criterio del equipo de desarrollo.

Importante: Aunque todos los Sprints dan como resultado un incremento del producto
software, no todos implican un paso a produccin. Es responsabilidad del
ProductOwner y los clientes decidir el momento en el que los incrementos son puestos
en produccin.
Una posibilidad para realizar la puesta en produccin es con los denominados "Sprints
de Release". Estos Sprints contendrn, en general, tareas solamente relacionadas con
el despliegue, instalacin y puesta en produccin del sistema. Es decir, no existen
tareas donde se agreguen nueva funcionalidad.

Adems, el equipo de desarrollo deber estimar el esfuerzo que nos llevarn las tareas del
Sprint Backlog (un mtodo de estimacin muy usado en Scrum y que veremos ms adelante
es el Planning Poker, descrito en la leccin 4 ).
Importante: En Scrum el Sprint Backlog indica solamente lo que el equipo realizar
durante la iteracin. El ProductBacklog, por el contrario, es una lista de caractersticas
que el ProductOwner quiere que se realicen en futuros Sprints.
El Product Owner puede visualizar, pero no puede modificar el Sprint Backlog. En
cambio, puede modificar el ProductBacklog cuantas veces quiera con la nica
restriccin de que los cambios tendrn efecto una vez finalizado el Sprint.
Para mejorar la gestin de las historias de usuario y las tareas de cada Sprint usualmente se
utilizan pizarras u otros mecanismos que brinden informacin inmediata al equipo. En el
siguiente video puedes ver un ejemplo de lo que podra ser un tablero Scrum en un proyecto
real.

Reuniones
Las reuniones son un pilar importante dentro de Scrum. Se realizan a lo largo de todo el Sprint
como muestra la Figura 4, representadas en los cuadros con color gris. Se definen diversos
tipos de reuniones:
Reunin de planificacin del Sprint (Sprint Planning Meeting): se lleva a cabo al
principio de cada Sprint, definiendo en ella que se va a realizar en ese Sprint. Esta
reunin da lugar al Sprint Backlog. En esta reunin participan todos los roles. El
Product Owner presenta el conjunto de historias de usuario en el ProductBacklog y el
equipo de desarrollo selecciona las historias de usuario sobre las que se trabajar. La
duracin de la reunin no debe ser mayor de 8 horas y como resultado de la misma el
equipo de desarrollo hace una previsin del trabajo que ser completada durante el
Sprint.
Reunin diaria (Daily Scrum): es una reunin diaria de no ms de 15 minutos en
la que participan el equipo de desarrollo y el Scrum Master. En esta reunin cada
miembro del equipo presenta lo qu hizo el da anterior, lo qu va a hacer hoy y los
impedimentos que se ha encontrado.
Reunin de revisin del Sprint (Sprint Review Meeting): se realiza al final del
Sprint. Participan el equipo de desarrollo, el Scrum Master y el Product Owner.
Durante la misma se indica qu ha podido completarse y qu no, presentando el

trabajo realizado al Product Owner. Por su parte el Product Owner (y dems

interesados) verifican el incremento del producto y obtienen informacin necesaria
para actualizar el Product Backlog con nuevas historias de usuario. No debe durar ms
de 4 horas.
Retrospectiva del Sprint (Sprint Retrospective): tambin al final del Sprint
(aunque puede que no se realice al final de todos los Sprints), sirve para que los
integrantes del equipo Scrum y el Scrum Master den sus impresiones sobre el Sprint
que acaba de terminar. Se utiliza para la mejora del proceso y normalmente se trabaja
con dos columnas, con los aspectos positivos y negativos del Sprint. Esta reunin no
debera durar ms de 4 horas.

Medir el progreso del proyecto

En el caso de las prcticas giles y en particular de Scrum uno de los mecanismos ms
utilizados es el grfico BurnDown [1].
Este grfico representa el trabajo que queda por hacer en un Sprint en funcin del tiempo
y compara el progreso real del Sprint con su planificacin inicial, facilitando las labores
de seguimiento del mismo.

Acordar una buena definicin de "done"

Por lo general, la gente que empieza a implantar agilidad, o los que lo han intentado pero no
con mucho xito, suelen tener en comn el pasar por alto un grupo de aspectos que son de
los ms importantes: los que definen las relaciones y compromisos entre los diferentes roles
que participan en el desarrollo software.
Todo el mundo es consciente y se preocupa por establecer iteraciones, Sprint, prototipos,
historias de usuario, etc. Pero hay otros aspectos en un proyecto gil igualmente importantes,
como son los de compromiso, por ejemplo, que todo el mundo tenga claros los roles y
responsabilidades de todo el mundo, que al comenzar un Sprint el product owner deje clara la
visin y el objetivo, etc.
O, como es el caso que aqu aplica, que tanto equipo como product owner estn de acuerdo y
definan qu significa que algo est terminado. Por dejarlo ms claro, haciendo referencia a un
tablero Scrum qu significa que algo est en la columna done (terminado).
Lo de qu significa done, terminado, se obvia muchas veces y no es algo trivial. No aclarar
este punto suele dar lugar a problemas.

Beneficios de Scrum
Para ayudarte a la hora de implantar Scrum y la agilidad en tu empresa, te dejo un mapa
de ideas clave que debes tener en cuenta.
Mapa mental de buenas prcticas y claves a la hora de implantar Scrum y agilidad

La implantacin de las metodologas giles, y, por lo tanto, de los principios giles, aporta una
serie de beneficios como el aumento de la transparencia a lo largo de la gestin del proyecto,
la mejora de la comunicacin y la autogestin del equipo de desarrollo. As mismo, existen
otras ventajas que se obtienen al utilizar Scrum.
Entrega peridica de resultados. El Product Owner establece sus expectativas
indicando el valor que le aporta cada historia de usuario y cuando espera que est
completado. Por otra parte, comprueba de manera regular si se van cumpliendo sus
expectativas.
Entregas parciales (time to market). El cliente puede utilizar las primeras
funcionalidades de la aplicacin software que se est construyendo antes de que est
finalizada por completo. Por tanto, el cliente puede empezar antes a recuperar su
inversin. Por ejemplo, puede utilizar un producto al que slo le faltan caractersticas
poco relevantes, puede introducir en el mercado un producto antes que su
competidor, puede hacer frente a nuevas peticiones de clientes, etc.
Flexibilidad y adaptacin respecto a las necesidades del cliente. De manera
regular el Product Owner redirige el proyecto en funcin de sus nuevas prioridades,
de los cambios en el mercado, de los requisitos completados que le permiten
entender mejor el producto, de la velocidad real de desarrollo, etc. Al final de cada
iteracin el Product Owner puede aprovechar la parte de producto completada hasta
ese momento para hacer pruebas de concepto con usuarios o consumidores y tomar
decisiones en funcin del resultado obtenido.

 Mejores estimaciones. La estimacin del esfuerzo y la optimizacin de tareas es

mejor si la realizan las personas que van a desarrollar la historia de usuario,
dadas sus diferentes especializaciones, experiencias y puntos de vista. De la misma
manera, con iteraciones cortas la precisin de las estimaciones aumenta. En el
captulo siguiente veremos las tcnicas de estimacin en proyectos giles.
Adems te recomiendo el siguiente video. En l, Joe Justice, un desarrollador de software
aficionado a tunear coches, cuenta como aplic la agilidad para, de manera colaborativa, crear
un nuevo prototipo de coche. Y cmo lo logr, con el apoyo de un montn de gente de muchos
sitios, con un modelo de crowdfunding, que bajo el proyecto Wikispeed cre de manera gil un
coche real, rpida y econmicamente.

Entrevista a Jeff Sutherland (Cocreador de Scrum)

(Enlace a la entrevista en ingls)

Jeff Sutherland es uno de los creadores del Manifiesto gil, de Scrum y la gua de Scrum y autor de Software
in 30 Days entre otras muchas cosas. Qu ms podemos decir sobre l!
Tuve la suerte de conocer a Jeff en Estocolmo. Aprend muchsimo de l.
Es un gran honor haber entrevistado a Jeff.
Jeff, muchas gracias por la entrevista.
1. Mucha gente conoce tu trabajo relacionado con el mundo de la agilidad y Scrum, pero Quin es
Jeff Sutherland? De dnde eres? Dnde trabajas? Creo que incluso fuiste piloto de las Fuerzas
Areas de EEUU, es eso cierto?
Cuando me gradu en la Academia Militar de EEUU tuve la oportunidad de aprender a ser piloto y unirme a
las Fuerzas Areas. Acab en 100 misiones sobrevolando Vietnam del Norte en un Phantom RF-4C.

Ms de la mitad de nosotros recibimos disparos, por lo que ide una estrategia de prevencin de riesgos que
est incluida en Scrum. El diagrama burndown est basado en lo que necesitas mirar para aterrizar un avin
de alto rendimiento al final de la pista de aterrizaje. Ver http://www.youtube.com/watch?v=4VTFKy133Sg
2. Cuando pas algunos das contigo en Estocolmo, recuerdo que dijiste que uno de los principales
problemas actuales relacionados con la agilidad es la mala agilidad. A qu te refieres con eso?
Qu podemos hacer?
El Standish Group, tiene datos de ms de 100.000 proyectos de todo el mundo. Para hacer el libro que
escribimos Ken Schwaber y yo el ao pasado, Jim Johnson dividi los proyectos en dos grupos cascada y
gil. l estaba sorprendido de que la tasa de xito para cascada era de un 14%, cosa que se triplicaba para
los equipos giles (43%). Yo me horroric de que el 57% de los proyectos giles terminaran con retraso,
costaran ms de lo planificado o fracasaran completamente. Parece ser que hay mucha mala agilidad por ah
fuera!
3. En mis proyectos giles y en los cursos que imparto, muy a menudo veo que es muy difcil para
grandes organizaciones, adaptar su forma de trabajo a la de los equipos giles. Cul es tu
experiencia y qu consejo puedes darnos?
Las organizaciones grandes requieren que el trabajo en equipo se extienda entre distintos equipos, liderazgo
visionario, metas desafiantes, lo que conlleva un gran cambio en los estilos de gestin tradicionales. La
gestin necesita cambiar su comportamiento desde la pequea gestin a ser lderes giles y coaches. Muy
pocos equipos de gestin tienen el valor y la visin necesaria para hacer esto. Por ello, las empresas que no
son giles se vern abrumadas por sus competidores giles.
Estamos trabajando con muchas empresas grandes donde los managers realmente entienden que necesitan
eliminar la visin de mando y control, reducir radicalmente la jerarqua, cambiar la forma en la que usan el
espacio, eliminar los bonus individuales, prohibir las hojas de tiempo, eliminar las evaluaciones de rendimiento
y deshacerse de gente que quiere decirle a otras personas lo que tiene que hacer en vez de dejar que el
Backlog del Product Owner gue al equipo. Los lderes necesitan inspirar a la gente a tener un alto rendimiento
y no llevarlos hacia la mediocridad.
4. Han pasado ms de 10 aos desde el nacimiento del Manifiesto gil. Y t eres uno de los firmantes.
Cmo ves el futuro de Scrum y la Agilidad?
Aquellas empresas que implementan bien lo gil, sobrevivirn y las otras se irn del negocio. La gente tiene
problemas para comprender que la competencia global est aumentando a una velocidad exponencial.
Empresas como Microsoft y SAP ya han cambiado radicalmente sus estructuras de gestin. Google tiene
15000 desarrolladores trabajando en una base de cdigo con ms de 20 cambios por minuto, y 75.000.000
test automatizados que llevan a mltiples despliegues diarios. Incluso pequeas empresas como
Ancestry.com sacan 220 releases cada sprint de dos semanas. Tenemos una empresa cerca de mi oficina en
Cambridge que da 170 actualizaciones en tiempo real a su producto cada da en los das ms lentos. El futuro
de la agilidad es ser lo suficientemente gil como para no ser aplastados por empresas que pueden entregar
una nueva release del software cada minuto.
5. Cules son tus tres libros favoritos que cualquier ingeniero del software debera leer?

El Mtico Hombre Mes (The Mythical Man Month) de Fred Brooks. Lo que dice es tan cierto hoy como lo era
hace 30 aos y me sorprende que no todos los managers relacionados con la ingeniera lo hayan ledo y
reledo.
El Libro de los Cinco Anillos (The Book of Five Rings) de Miyamoto Musashi, uno de los mejores
espadachines del mundo. As es como hay que pensar cortar el cdigo, trocear los impedimentos, y
siempre estar ejecutando simultneamente una estrategia tanto a corto como largo plazo. Un buen cdigo
requiere una buena arquitectura. Una buena arquitectura necesita un buen diseo. Un buen diseo require ver
todo de una vez y ver todos los efectos secundarios que implicar cambiar tu cdigo en el futuro.
Una Visin Muy Noble: John Boyd, el Bucle OODA, y la Guerra de Amrica contra el Terrorismo (A
Vision So Noble: John Boyd, the OODA Loop, and Americas War on Terror) de Daniel Ford. Este es el mejor
libro del mundo escrito por uno de los mejores pilotos de combate del mundo. Si implementas esta estrategia
tendrs la certeza de ganar si codificas o lideras equipos.
Todos estos libros hablan de la forma de pensar. En estos das habitualmente estoy quedando con ex pilotos
de combate que usan Scrum, tienen el cinturn negro de Aikido y son expertos en Karate y Kung Fu.
Debatimos sobre cmo transmitir la forma de pesar gil a todo el equipo. La agilidad implica una
concentracin intensa, disciplina y accin agresiva y espontnea.
6. Alguna recomendacin para los ingenieros de software jvenes?
Intenta trabajar con los mejores ingenieros que puedas encontrar. Trabaja solo en entornos giles. Si ests en
el medio de la agilidad mala arrglala o sal de all. Encuentra un equipo mejor. Cada da que no ests en un
buen equipo es un da de tu vida que malgastas.
7. Alguna vez has ido a Espaa?
Cuando era CTO de lo que ahora es GE Healthcare, ramos dueos de una empresa en Barcelona. Era
genial trabajar con ellos. Aos atrs sola llevar F4 Phantoms por el Atlntico. Esos vuelos salan de la Base
Area de Morn. All pas muchas horas quedando en el bar con pilotos de combate. Tiempos divertidos!
Gracias Jeff.