El Manual de Scrum

Xavier Quesada Allue

v1.3ES - 30/Oct/2011

Acerca de este manual

Este manual est intencionado como material de lectura previa al tomado de un curso de Scrum. El o !etivo es "aranti#ar $ue el cursista se %amiliarice con la terminolo"&a ' el marco sico. (or este motivo) es puntual ' conciso) ' no cu re detalles de implementaci*n. +o se recomienda su lectura en %orma aislada.

Reconocimientos (artes de este manual son derivadas directamente de material ori"inalmente pu licado en in"l,s en./0e Scrum (rimer1 v1.2 por 2eemer) 3ene%ield) 4arman and 5odde. ./0e Scrum 6uide1) por Sc07a er and Sut0erland) versi*n Scrum Alliance 8retirada9.

Scrum es un marco gil para el desarrollo de productos. El desarrollo de productos "eneralmente se estructura alrededor de pro'ectos) por eso podemos tam i,n pensar a Scrum como un marco para la "esti*n "il de pro'ectos. En ve# de ser una metodolo"&a completa) Scrum es un es$ueleto simple asado en principios) prcticas ' valores "iles. Esto si"ni%ica $ue en ve# de proveer descripciones completas ' detalladas acerca de c*mo todo proceso de e ser reali#ado en un pro'ecto) Scrum es liviano ' casi todos los detalles de implementaci*n se de!an li rados al e$uipo $ue est 0aciendo el tra a!o.

Manifesto por el desarrollo de software gil

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A travs de este trabajo hemos aprendido a valorar:

:ndividuos e interacciones so re procesos ' 0erramientas So%t7are %uncionando so re documentaci*n e;tensiva <ola oraci*n con el cliente so re ne"ociaci*n contractual =espuesta ante el cam io so re se"uir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos ms los de la izquierda. 777.a"ilemani%esto.or" Sno7 ird) >ta0) >SA ? @e ruar' 2001

Pricipios detrs del Manifesto gil

Seguimos estos principios: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. Aceptamos que los requisitos cambien, incluso en etapas tardas del desarrollo. Los procesos giles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo ms corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecucin del trabajo. El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo y entre sus miembros es la conversacin cara a cara. El software funcionando es la medida principal de progreso. Los procesos giles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. La atencin continua a la excelencia tcnica y al buen diseo mejora la Agilidad. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requisitos y diseos emergen de equipos auto-organizados. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a continuacin ajustar y perfeccionar su comportamiento en consecuencia.

El marco Scrum Scrum es el m,todo A"il ms popular) con un .marBet s0are1 estimado de un CDE en 2010 contando sus variantes ' derivados1. En el cora#*n de Scrum encontramos al Sprint 8in"l,s para Fcarrera cortaF9. >n sprint es una iteraci*n de tiempo %i!o) "eneralmente de una a cuatro semanas. >n pro'ecto Scrum se estructura como una se"uidilla de Sprints) uno atrs del otro. <ada sprint comien#a con un o !etivo) ' -si es e;itoso- termina con un incremento de producto $ue es potencialmente entre"a le. El sprint si"uiente comien#a inmediatamente al %inali#ar el anterior. 4os sprints tienen tiempo fijo ? terminan en una %ec0a %i!a) se 0a'a completado o no el tra a!o. 4os sprints) por de%inicion) no pueden ser e;tendidos nunca. Al comien#o de cada sprint) un e$uipo Scrum eli"e una serie de re$uerimientos de usuario %inal 8"eneralmente llamados historias de usuario o para a reviar) simplemente historias9 de una lista priori#ada ' ordenada llamada el Product Backlog 8Pila de Producto en castellano9. El e$uipo se compromete a 0acer todo lo posi le por completar esas 0istorias de usuario para el %inal del sprint. 2urante el sprint) las 0istorias ele"idas no pueden ser modi%icadas. <ada d&a el e$uipo se !unta revemente para inspeccionar el pro"reso) ' a!ustar los pr*;imos pasos necesarios para completar el tra a!o %altante. Al %inal del Sprint) el e$uipo repasa el tra a!o reali#ado con las di%erentes partes interesadas en el pro'ecto) ' demuestra las 0istorias de usuario $ue 0a completado e;itosamente. Roles en Scrum En Scrum) e;isten tres roles- el 2ueGo del (roducto) el E$uipo) ' el ScrumMaster. El Product Owner (Dueo de Producto en castellano) es responsi le de "aranti#ar el m;imo retorno de inversi*n del pro'ecto. (ara reali#ar esto) identi%ica %uncionalidades $ue desea incorporar al producto) volcndolas a una lista ordenada ' priori#adaH decidiendo cules de en estar en la parte superior de la lista para el si"uiente Sprint) ' continuamente actuali#ando) re%inando ' re-priori#ando la lista a medida $ue el pro'ecto evoluciona. 4a priori#aci*n puede verse in%luenciada por dependencias t,cnicas) la necesidad de satis%acer clientes claves) el alinearse detrs de o !etivos estrat,"icos) miti"aci*n de ries"os) ' otros %actores de este estilo. En al"unos casos el (roduct O7ner ' el cliente %inal son la misma personaH esto es t&pico de desarrollos internos. En otros) el cliente o el usuario %inal puede ser e;terno a la or"ani#aci*n) en este caso el rol de (roduct O7ner puede ser similar a un 6erente de (roducto tradicional. En otras situaciones 8menos desea les9) el (roduct O7ner es un proxy $ue representa al verdadero (roduct O7ner.
1

VersionOne State of Agile survey 2010, www.versionone.com

El (roduct O7ner en Scrum es una sola persona. >n solo responsi le es %undamental para evitar con%lictos en las prioridades) cosa de $ue el e$uipo siempre sepa $u, es lo si"uiente $ue de e 0acer. El equipo constru'e el producto $ue el (roduct O7ner indica. El e$uipo en Scrum es multifuncional ? inclu'e todos los roles ' conocimientos necesarios para reali#ar un incremento completo de producto- ' es autogestionado) con un alto "rado de autonom&a ' responsa ilidad. El e$uipo decide a $u, comprometerse) ' cul es la me!or %orma de reali#ar el o !etivo $ue %ue comprometido. El e$uipo diseGa) desarrolla ' prue a el producto ' a'uda al (roduct O7ner con ideas so re c*mo construir un producto so resaliente. El e$uipo tam i,n es responsa le de velar por la calidad interna del producto) $ue el (roduct O7ner $ui#s no pueda evaluar. El tamaGo recomendado para un e$uipo en Scrum es entre D ' I personas) sentadas !untas) ' dedicadas tiempo completo al pro'ecto. Otras con%i"uraciones son posi les) pero no *ptimas. El ScrumMaster a'uda al e$uipo ' al (roduct O7ner a ser e;itosos) entre"ar m;imo valir de ne"ocios ' o tener todos los ene%icios de Scrum. El ScrumMaster sirve al e$uipo ' al (roduct O7ner al remover impedimentos $ue los lo$uean de reali#ar su tra a!oH los prote!e de inter%erencias del mundo e;teriorH ase"ura $ue todo el mundo entienda ' si"a las prcticas de ScrumH actJa como %acilitador ' "uardin del proceso de ScrumH ' a'uda a la or"ani#aci*n a vadear los cam ios $ue son necesarios para poder reali#ar Scrum e;itosamente. 4os uenos ScrumMasters tienen 0a ilidades de coac0in" ' %acilitaci*n) una mentalidad de .l&der servil1) ' son uenos solucionando pro lemas ' des lo$ueando a las personas. (ueden venir de cual$uier disciplina- :n"enier&a) 6esti*n de productos o pro'ectos) 6erencia) etc. El ScrumMaster en Scrum es una persona) ' para pro'ectos medianos a "randes es un tra a!o de tiempo completo.

Comen ando con Scrum (rimero) el (roduct O7ner de e articular su visi*n para el mismo. 4a visi*n es lue"o trans%ormada en una lista priori#ada) ordenada ' estimada de %uncionalidades llamada el Product Backlog. El product acBlo" constitu'e los alcances del pro'ecto) ' la plani%icaci*n del mismo. /odo esto ocurre antes de comen#ar el primer Sprint) durante un per&odo $ue colo$uialmente llamamos Sprint ero. <uanto menos dure este per&odo) me!or. >n uen product acBlo" es una lista priori#ada de re$uerimientos 8 historias de usuario9) e;presadas lo m;imo posi le como %uncionalidades del usuario %inal) en t,rminos simples $ue cual$uiera podr&a comprender. S*lo e;iste un (roduct 3acBlo") ' cada 0istoria tiene una prioridad Jnica. Esto si"ni%ica $ue el (roduct O7ner se ve o li"ado a tomar decisiones de priori#aci*n so re todo el espectro de demandas del pro'ecto) con lo cual de e representar los intereses de mJltiples personas ' de e escuc0ar al e$uipo. El product acBlo" puede ser actuali#ado en cual$uier momento por el (roduct O7ner para re%le!ar cam ios en las necesidades del cliente) nuevas ideas) movidas de la competencia) pro lemas t,cnicos $ue sur"en) etc. (ara poder planear el pro'ecto) el product acBlo" de e ser estimado. El E$uipo es responsa le de las estimaciones de las 0istorias de usuario. /eniendo en cuenta %actores como tamaGo) valor de ne"ocios) ' otras varia les importantes como ries"o ' dependencias) el (roduct O7ner priori#a el acBlo" con la a'uda ' conse!o del e$uipo. Planificaci!n de Release 4os productos ' pro'ectos "eneralmente se or"ani#an alrededor de FreleasesF. >n release t&picamente es el momento en $ue una aplicaci*n es puesta en producci*n) o es lan#ada al mercado. 4os e$uipos de Scrum en%ocan su plani%icaci*n alrededor del pr*;imo release. El o !etivo es tener una plani%icaci*n realistaH planear demasiado 0acia el %uturo es ine%iciente e;cepto a mu' alto nivel. 4a plani%icaci*n de release en Scrum consiste en identi%icar la %uncionalidad $ue $ueremos incluir en el pr*;imo release) dividirla en peda#os su%icientemente pe$ueGos estimados ' priori#ados) ' de%inir la %ec0a de lan#amiento deseada. >n grfico de "urndown es un arte%acto simple $ue nos muestra en %orma visual cunto alcance 0a' $ue entre"ar sprint por sprint para alcan#ar el o !etivo. Se crea durante la plani%icaci*n del release ' es actuali#ado sprint tras sprint por el (roduct O7ner.

Planifcaci n !el S"rint

Al comien#o de cada Sprint) tiene lu"ar la reunion de planificaci!n del sprint. 2urante la primera parte) el (roduct O7ner ' el e$uipo 8con %acilitaci*n del ScrumMaster9 reveen la %uncionalidad de alta prioridad $ue el (roduct O7ner est interesado en ver implementada durante el Sprint $ue comien#a. El e$uipo lue"o selecciona tantos &tems de la parte superior del (roduct 3acBlo" como creen es %acti le implementar durante el pr*;imo Sprint. Es el e$uipo $uien decide cunto tra a!o ser reali#ado) no el (roduct O7ner. Esto es as& por$ue uscamos un compromiso del e$uipo para con el tra a!o a reali#ar. Si la cantidad de tra a!o no alcan#a las e;pectativas del (roduct O7ner) esto es discutido como un pro lema de plani%icaci*no o de capacidad ? pero en cual$uier caso el (roduct O7ner nunca puede imponer re$uerimientos al e$uipo) solo decidir la prioridad de los mismos. 2urante la se"unda parte de la reuni*n de plani%icaci*n) el e$uipo se dedica a estudiar las 0istorias seleccionadas en detalle) "eneralmente reali#ando el anlisis ' diseGo de las mismas. A medida $ue esto sucede) se descompone a las 0istorias de usuario en tareas) todos los pasos $ue son necesarios para completar una 0istoria de usuario. /&picamente las tareas son de naturale#a t,cnica) ' no necesariamente son comprendidas por el (roduct O7ner. 4as tareas de en ser relativamente pe$ueGas) nunca superando un d&a de tra a!o. A medida $ue el e$uipo descompone las 0istorias en tareas) aprende ms acerca de las mismas. (uede lle"ar a suceder $ue en esta etapa se descu ra $ue se 0a tomado demasiado tra a!oH en este caso todav&a estamos a tiempo de eliminar alcances del Sprint. (ero una ve# $ue se 0an con%irmado) las 0istorias de usuario seleccionadas ' decompuestas en tareas $uedan comprometidas para el Sprint) constitu'en la Pila del Sprint (sprint !ac"log). <ual$uier nueva %uncionalidad o cam io de alcances de e esperar 0asta el si"uiente Sprint) para $ue el e$uipo pueda en%ocarse.

Scrum #iario El Scrum diario es una reunion reve 81D minutos m;imo9 de sincroni#aci*n ' %eed acB $ue sucede todos los d&as a una 0ora ' lu"ar pre%i!ados. 2e en atender todos los $ue est,n tra a!ando activamente en el pro'ecto. (ara mantenerla reve) se recomienda reali#arla de parado. Es la oportunidad para $ue el E$uipo sincronice sus actividades ' se ase"ure de estar alineado. /am ien sirve para identi%icar o stculos ' pro lemas. En el Scrum diario) uno por uno cada miem ro del e$uipo 0a la de tres cosas- 819 Que 0icieron desde la Jltima reunionH 829 Qu, planean 0acer 0asta la pr*;ima reuni*n ' 839 si 0a' al"o $ue los est lo$ueando. El Scrum diario no es un reporte de esttus a un "erente) al (roduct O7ner) al ScrumMaster o al l&der de e$uipo. El o !etivo es coordinar ' sincroni#ar tra a!o entre los miem ros del e$uipo. 4ue"o de un Scrum diario e;itoso) todo el mundo de er&a sa er $uien est 0aciendo $u,) ' tener la con%ian#a de $ue todo el mundo est ocupado con la tarea ms valiosa $ue pueden 0acer para a'udar al e$uipo a lo"rar su o !etivo de entre"ar el tra a!o comprometido. +o de e 0a er discusiones o de ates en el Scrum diario. 2e otra %orma) nunca aca ar a tiempo. 4as discusiones so re temas $ue sur"en de en ser pospuestas a una reunion aparte) lue"o de %inali#ado el Scrum. $ask"oard %&tablero / tabln de tareas en castellano' El tasB oard es usado por el e$uipo para auto"estionarse) visuali#ar ' plani%icar su tra a!o del d&a a d&a. El tasB oard contiene todo el tra a!o $ue de e ser reali#ado por el e$uipo en el Sprint) "eneralmente representado por 0istorias ' tareas. 4as tareas t&picamente se escri en en (ost-its $ue son colocados en columnas $ue indican el esttus de la tarea 8por e!emplo .no comen#ado1) .comen#ado1 ' .terminado19. El tasB oard se pue la al comien#o del Sprint) durante la plani%icaci*n del Sprint) ' se actuali#a continuamente durante el Sprint a medida $ue pro"resa el tra a!o. >n uen tasB oard siempre est actuali#ado ' re%le!a %ielmente $ui,n est 0aciendo $u,. Es un complemento al Scrum diario) el cual "eneralmente sucede alrededor del mismo.

(inali ando el Sprint 4a duraci*n de un Sprint nunca puede ser e;tendida ? termina en el d&a desi"nado) se 0a'a conclu&do el tra a!o o no. 4as 0istorias $ue no %ueron %inali#adas permanecen .comen#adas1 ' se pasan al si"uiente sprint 8o se cancelan si 'a no son vlidas9. El e$uipo no suma nin"Jn cr,dito por tra a!o parcialmente completado. Re)isi!n del Sprint /odo Sprint termina con una Re)isi!n del Sprint. En ella) el e$uipo ' el (roduct O7ner repasan el tra a!o $ue 0a sido completado durante la iteraci*n. >na idea clave en Scrum es la me!ora continua) ' ,sta es la instancia donde los interesados pueden contri uir a la me!ora del producto rindando %eed acB. (resentes en esta reuni*n encontramos al (roduct O7ner) los miem ros del e$uipo) el ScrumMaster) ms cual$uier otro interesado en se"uir el pro"reso del pro'ecto. 4a revisi*n del Sprint de e ser a ierta ' transparente. (uede incluir a clientes) usuarios %inales) la "erencia) e;pertos en el tema) representantes de otras unidades de ne"ocio... esencialmente cual$uiera $ue se considere una parte interesada 8un sta"eholder9. >na revisi*n de Sprint t&pica inclu'e una reve demostraci*n de las nuevas %uncionalidades del producto. Se captura el %eed acB de todos los presentes) el cual de e ser procesado por el (roduct O7ner) resultando 8potencialmente9 en nuevas 0istorias de usuario) cam ios a los criterios de aceptaci*n de las mismas) o cam ios de prioridades. Retrospecti)a 4a retrospectiva) $ue si"ue a la revisi*n) es la oportunidad de me!orar el proceso) o sea la %orma en la $ue tra a!amos para construir el producto. Es el momento para $ue el e$uipo discuta $u, est %uncionando ien ' $u, de e me!orar. /odo lo $ue sur!a de e ser capturado ' discutidoH ' al"unas acciones concretas de me!ora de en ser comprometidas para el pr*;imo Sprint. El ScrumMaster %acilita la retrospectiva ' es responsa le de mantener la Pila de Me*oras) una lista de cosas a me!orar. /odo Sprint termina con una retrospectiva. <uando un e$uipo de!a de 0acer retrospectivas) de!a de me!orarH cuando un e$uipo de!a de me!orar) 'a no est 0aciendo Scrum. Comentarios de Cierre Scrum es sencillo) pero 0acer Scrum correctamente es di%&cil. <omo el a!edre#) las re"las se aprenden %cil pero dominar el !ue"o es sumamente comple!o.