La guia de Scrum

La guia definitiva de Scrum: Les regles del joc

Juliol 2013

Desenvolupat i suportat per Ken Schwaber i Jeff Sutherland

Taula de continguts
Propsit de la guia de Scrum..................... ..........................................................................................3 Definici de Scrum...............................................................................................................................3 Teoria de Scrum...................................................................................................................................3 Equip Scrum (Scrum Team) ..............................................................................................................4 Propietari Producte (Product Owner)..............................................................................................5 Equip de Desenvolupament (Development Team).........................................................................5 Scrum Mster ..................................................................................................................................6 Events de Scrum ..................................................................................................................................7 Sprint...............................................................................................................................................8 Reuni de Planificaci del Sprint (Sprint Planning Meeting)...........................................................9 Objectiu del Sprint (Sprint Goal)...................................................................................................11 Scrum Diari (Daily Scrum).................................................................................................................11 Revisi del Sprint (Sprint Review) .................................................................................................12 Retrospectiva del Sprint (Sprint Retrospective)............................................................................13 Artefactes de Scrum (Artifats) .........................................................................................................14 Llista del Producte (Product Backlog) ..........................................................................................14
.

Llista del Sprint (Sprint Backlog) ..................................................................................................16 Increment .....................................................................................................................................17 Transparncia dels Artefactes..........................................................................................................17 Definici de Finalitzat (Deinition of Done) ...................................................................................17 Nota Final..........................................................................................................................................18 Agraments.......................................................................................................................................18 Persones .......................................................................................................................................18 Historia..........................................................................................................................................18 Traducci.......................................................................................................................................18 Canvis entre les guies de Scrum del 2011 i 2013............................................................................. 19

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina |2

Propsit de la guia de Scrum

Scrum s un marc de treball, (Framework) per el desenvolupament i manteniment de productes complexos. Aquesta guia cont tota la definici del que s Scrum. Aquesta definici es compon bsicament dels segents elements; els Rols (Roles) dins de Scrum, els Events (Events), els Artefactes (Artifacts) i el conjunt de normes que els vinculen a tots ells (Rules) . Ken Schwaber i Jeff Sutherland varen desenvolupar Scrum; la guia de Scrum est r edactada i proporcionada ntegrament per tots dos. Ells estan darrere i donen suport a la guia de Scrum.

Definici de Scrum
Scrum (n): s un marc de treball (Framework) dins del qual la gent pot abordar problemes adaptatius complexos, mentre es lliuren productes de forma productiva i creativa amb el valor ms alt possible. Scrum s: Lleuger. Fcil dentendre. Extremadament difcil darribar a dominar.

Scrum s un marc de treball (Framework) de processos que s'ha utilitzat per gestionar el desenvolupament de productes complexos des de la dcada dels 90. Scrum no s un procs o una tcnica per construir productes; ms aviat, es tracta d'un marc de treball (Framework) en el que es pot emprar diversos processos i tcniques. El paper de Scrum s de fer aflorar la leficcia relativa de la gesti de productes i prctiques de desenvolupament utilitzades, per a poder millorar-les. El marc de treball (Framework) de Scrum es compon dels Scrum Teams y els seus roles associats, events, artefactes i regles. Cada component dins del marc de treball (Framework) de Scrum serveix per a un especific objectiu i s essencial pel seu xit i utilitzaci. Les regles de Scrum connecten de forma conjunta els events, roles, regles i artefactes, governant les relacions e iteracions entre ells. Les regles de Scrum estan descrites al llarg daquest document. Les tctiques especfiques per utilitzar el framewrok de Scrum varien i sn descrites ms endavant.

La Teoria de Scrum
Scrum es basa en la teoria del control empric de processos o empirisme. Lempirisme afirma que el coneixement ve de lexperincia i de la presa de decisions basades en el que es coneix. Scrum utilitza un enfocament iteratiu e incremental per a poder optimitzar la predictibilitat i el control de risc. Fonamentalment, hi ha tres pilars que suporten tota implementaci del control de processos empric: la transparncia, la inspecci i l'adaptaci.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 3

Transparncia
Importants aspectes del procs han de ser visibles a tots aquells qui sn els responsables dels resultats. La transparncia requereix que aquests aspectes han de ser definits per una norma comuna, de manera que tots ells comparteixin una comprensi comuna del que estan veient. Per exemple: Tots els participants han de compartir un llenguatge com per referir-se al processos; i, Una definici comuna de Finalitzat (Done) ha de ser compartida per tots aquells que van a realitzar el treball i pels qui acceptaran el producte.

Inspecci
Els usuaris de Scrum han dinspeccionar freqentment els artefactes (Artifacts) de Scrum i el progrs c ap a un objectiu (Goal) per a poder detectar varinces indesitjables. Les seves inspeccions no haurien de ser tan freqents, que interfereixin en el treball. Les inspeccions sn ms beneficioses quan aquestes es realitzin diligentment per inspectors qualificats en el mateix lloc de treball.

Adaptaci
Si un inspector determina que un o ms aspectes d'un procs es desvia fora dels lmits acceptables, i que el producte resultant ser inacceptable, llavors el procs o el material que s'est processant sha dajustar. Una adaptaci s'ha fet tan aviat com sigui possible per minimitzar encara ms la desviaci. Scrum prescriu quatre Events (Events) que son oportunitats formals per a la inspecci i l'adaptaci, com s desccriu en la secci de , Events en Scrum d'aquest document, aquestes sn les segents: Reuni de planificaci del Sprint (Sprint Planning Meeting) Scrum diari (Daily Scrum) Revisi del Sprint (Sprint Review) Retrospectiva del Sprint (Sprint Retrospective)

Lequip Scrum (Scrum Team)

LEquip Scrum (Scrum Team) est compost d un Propietari del Producte (Product Owner), lEquip de Desenvolupament (Development Team), i un Scrum Mster. Els Equips Scrum (Scrum Teams) son autoorganitzats i multifuncionals. Els equips autoorganitzats trien per ells mateixos la forma ms ptima de realitzar el treball, en lloc, de ser dirigits per altres persones fora de lequip. Els equips multifuncionals tenen totes les competncies necessries per realitzar tot el treball sense dependre d'altres persones que no formin part de lequip. El model de lEquip Scrum (Scrum Team) est dissenyat per optimitzar la flexibilitat, la creativitat i la productivitat. Els Equips Scrum (Scrum Team) entreguen productes de forma iterativa i incremental, maximitzant les oportunitats per a la retroalimentaci. Els lliuraments incrementals de Finalitzat (Done) del producte garanteixen que una entrega potencialment til i funcional del producte sempre estar sempre disponible.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 4

El Propietari del Producte (Product Owner)

El Propietari del Producte (Product Owner) s el responsable de maximitzar el valor del producte i del treball de lEquip de Desenvolupament (Development Team). Com es realitza aix pot variar mpliament entre organitzacions, Equips Scrum (Scrum Teams), i individus. El Propietari del Producte (Product Owner) s la nica persona responsable de gestionar la Llista de Producte (Product Backlog) Expressar clarament els elements de la Llista del Producte (Product Backlog); Ordenar els elements de la Llista del Producte (Product Backlog) per aconseguir els millors objectius i missions; Optimitzar el valor del treball que porta a terme lEquip de Desenvolupament (Development Team); Assegurar-se que la Llista de Producte (Product Backlog) s visible, transparent i clar per a tothom, i mostrar en el que lEquip Scrum (Scrum Team) treballar prximament, i, Vetllar que lEquip de Desenvolupament (Development Team) comprn els elements del Llista del Producte (Product Backlog) en el nivell necessari.

El Propietari del Producte (Product Owner) pot fer la feina anterior, o delegar-la en lEquip de Desenvolupament (Development Team). No obstant aix, el Propietari del Producte (Product Owner) segueix sent el mxim responsable. El Propietari del Producte (Product Owner) s una persona, no un comit. El Propietari del Producte (Product Owner) pot representar els desitjos d'un comit en la Llista de Producte (Product Backlog), per aquells que vulguin canviar la prioritat dels elements en la Llista de Producte (Product Backlog) han de convncer sempre en el Propietari del Producte (Product Owner). Per a qu un Propietari del Producte (Product Owner) sigui exits, lorganitzaci ha de respectar les seves decisions. Les decisions del Propietari del Producte (Product Owner) sn visibles en el contingut i en l'ordre de la Llista de Producte (Product Backlog). No se li permet a ning dir-li en l Equip de Desenvolupament (Development Team) que treballi en un conjunt diferent de requeriments , ni que, lEquip de Desenvolupament (Development Team) pugui actuar en base en el que qualsevol altre digui.

LEquip de Desenvolupament (Development Team)

LEquip de Desenvolupament (Development Team) es compon bsicament de professionals que fan el treball dentregar potencialment un increment entregable de Finalitzat (Done) al final de cada Sprint, que potencialment es pot pujar a producci. Noms els membres lEquip de Desenvolupament (Development Team) participen en l'increment.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 5

Els Equips de Desenvolupament (Development Teams) sn estructurats i estan autoritzats per l'organitzaci per poder organitzar i gestionar els seus propis treballs. La sinergia resultant optimitza leficincia i leficcia global de lEquip de Desenvolupament (Development Team). Els Equips de Desenvolupament (Development Team) tenen les s egents caracterstiques:

Sn autoorganitzats. Ning (ni tan sols el Scrum Mster) lhi diu en lEquip de Desenvolupament (Development Team) com convertir la Llista de Producte (Product Backlog) en increments entregables de funcionalitats; Els Equips de Desenvolupament (Development Team)t sn multifuncionals, amb totes les habilitats i coneixements necessaris com a equip, per a poder crear un increment. Scrum no reconeix cap ttol, crrec, o estatus per cap membre de lEquip de Desenvolupament (Development Team) diferent de desenvolupador, independentment de la tasca que realitza la persona; no hi ha cap excepci a aquesta norma; Els membres de lEquip de Desenvolupament (Development Team) poden tenir especialitats, coneixements, habilitats i rees de treball ms focalitzades, per finalmen t la rendici de comptes pertany a tot lEquip de Desenvolupament (Development Team) en el seu conjunt; i, Els Equips de Desenvolupament (Development Team) no contenen sub-equips dedicats a particulars dominis de treball o coneixements, com sn les proves o l'anlisi de negoci.

El tamany de lEquip de Desenvolupament (Development Team)

La mida ptima de lEquip de Desenvolupament (Development Team) s prou petita per romandre gils i s prou gran per a poder completar tot el treball de forma significativa. Menys de tres membres en lEquip de Desenvolupament (Development Team) decrementa les iteracions i els resultats lligats a la productivitat sn menors. En Equips de Desenvolupament (Development Teams) ms petits es poden trobar restriccions en les habilitats i coneixements durant el Sprint, provocant que lEquip de Desenvolupament (Development Team) no pugui realitzar una entrega duna release en lincrement. Si hi ha ms de nou membres, requereix massa coordinaci. Grans Equips de Desenvolupament (Development Teams) generen massa complexitat per a gestionar un procs empric. El Propietari del Producte Propietari del Producte (Product Owner) i el Scrum Mster no estan inclosos en aquest compte a menys que ells tamb estiguin executant part del treball en el Sprint Backlog.

El Scrum Mster
El Scrum Mster s el responsable de garantir que Scrum s ents i adoptat. El Scrum Mster fa aix garantint que lEquip Scrum (Scrum Team) s'adhereix i segueix la teoria de Scrum , les prctiques i les normes. El Scrum Mster s un lder que est al servei de lEquip Scrum (Scrum Team). El Scrum Mster ajuda a qui estan fora lEquip Scrum (Scrum Team) a entendre quina de les seves interaccions amb el Scrum Team (Scrum Team) sn tils i quines no ho sn. El Scrum Mster ajuda a tots a canviar aquestes interaccions per maximitzar el valor creat per a lEquip Scrum (Scrum Team).

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 6

Els serveis del Scrum Mster al Propietari del Producte (Product Owner)
El Scrum Mster serveix al Propietari del Producte (Product Owner) de diferents formes i maneres, incloent-hi: Investiga tcniques per a poder gestionar de forma efectiva la Llista de Producte (Product Backlog); Comunicar de forma clara la visi, els objectius, i els elements que componen la Llista de Producte (Product Backlog)a tot lEquip de Desenvolupament (Development Team); Ensenyar a lEquip Scrum (Scrum Team) com crear de forma clara i concisa els elements en la Llista de Producte(Product Backlog); Entendre a llarg termini la planificaci del producte en un entorn empric; Entendre i practicar agilitat; i, Facilitar els Events (Events) en Scrum per petici o necessitat.

Els serveis del Scrum Mster en lEquip de Desenvolupament (Development Team)

El Scrum Mster serveix en lEquip de Desenvolupament (Development Team) de diferents formes i maneres, incloent-hi: Guiar lEquip de Desenvolupament (Development Team) en ser autoorganitzat i multifuncional; Ensenyar i liderar lEquip de Desenvolupament (Development Team) en crear productes dalt valor; Treure obstacles durant tot el progrs per lEquip de Desenvolupament (Development Team); Facilitar els Events (Events) en Scrum segons petici o necessitat; i, Guiar lEquip de Desenvolupament (Development Team) en un entorn organitzacional en el qual Scrum encara no s totalment adoptat i ni ents.

Els serveis del Scrum Mster a lorganitzaci

El Scrum Mster serveix a lorganitzaci de diferents formes i maneres, incloent-hi: Liderant i entrenant a lorganitzaci en ladopci de Scrum; Planificant la implementaci de Scrum en lorganitzaci; Ajudant a empleats i a les parts interessades a entendre i promulgar Scrum, i a ms, en el desenvolupament empric del producte; Provocant els canvis que facin augmentar la productivitat de lEquip Scrum (Scrum Team); i, Treballar amb altres Scrum Msters per augmentar leficincia de l'aplicaci de Scrum en l'organitzaci.

Els Events de Scrum

Els Events establerts i acordats en Scrum, s'utilitzen per a poder crear regularitat i minimitzar la necessitat de reunions no definides en Scrum. Scrum utilitza Events de durada establerta (TimeBox) i definida en el temps, tal que cada Event t una durada mxima. Una vegada un Sprint comena la seva durada es fixe i no s pot ni allargar ni escurar. Els altres Events poden acabar sempre que sarribi en lobjectiu del Sprint, assegurant que sutilitza una quantitat de temps apropiada sense permetre desperdici de temps.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 7

El Sprint en si mateix, s un contenidor per a tots els altres Events, cada Event en Scrum s una oportunitat formal per inspeccionar i adaptar en algun aspecte. Aquests Events estan especficament dissenyats per permetre la transparncia i la inspecci. La falta d'incloure algun d'aquests Events resulta en una reducci en la transparncia i constitueix en una oportunitat perduda per a poder inspeccionar i adaptar-se.

El Sprint
El cor de Scrum s el Sprint, s de temps fixat (Time-Box) i limitat en el temps, dun ms o menys de durada, durant el qual es crea un increment de producte entregable i Finalitzat "Done", potencialment lliurable i desplegable. Els Sprints tenen una durada determinada establerta i han de ser consistents amb esfor de desenvolupament. Un Sprint nou comena immediatament desprs de la finalitzaci del Sprint anterior. Els Sprints contenen i es componen dels segents elements; la Reuni de Planificaci del Sprint, (Sprint Planning Meeting), els Scrums Diaris (Daily Scrums), el treball de desenvolupament, la Revisi del Sprint (Sprint Review), i la Retrospectiva del Sprint (Sprint Retrospective). Durant del Sprint: No hi ha canvis a realitzar que puguin afectar lobjectiu del Sprint (Sprint Goal); Els objectius de qualitat no disminueixen; i, Labast i els objectius shan de clarificar i renegociar, entre el Propietari del Producte (Product Owner) i lEquip de Desenvolupament (Development Team) a la vegada que es va aprenent.

Tot Sprint sha de considerar com un projecte que no t ms durada dun mes dhoritz. Com els projectes, els Sprints sutilitzen per a conseguir quelcom. Cada Sprint t una definici del que sha de construir o desenvolupar, un disseny i un pla flexible que han de guiar a la construcci, el entregable i el producte resultant. Els Sprints es limiten a un mes de calendari. Quant lhoritz dun Sprint s massa llarg la definici del que s'est construint pot canviar, pot augmentar la complexitat i el risc. Els Sprints permeten la predictibilitat, garantint la inspecci i l'adaptaci dels avenos cap a una meta (Goal), com a mnim, cada mes del calendari. Els Sprints tamb limiten el risc a un mes de cost.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 8

Cancellant un Sprint
Es pot cancellar un Sprint sempre i que el temps fixat i estipulat no shagi esgotat. Noms el Propietari del Producte (Product Owner) t l'autoritat de cancellar el Sprint, s dona la possibilitat, que el Propietari del Producte (Product Owner) ho pugui realitzar sota la influncia de les parts interessades, lEquip de Desenvolupament (Development Team) o el Scrum Mster. Tamb, es pot cancellar un Sprint si l'objectiu del Sprint es converteix en obsolet. Aix podria succeir si l'empresa canvia de direcci de negoci, estratgica, etc ... o si canvien de condicions del mercat o de tecnologia. En general, un Sprint shauria de cancellar si ja no t sentit donades les circumstncies. Per, a causa de la curta durada dels Sprints, la cancellaci rarament t sentit. Quan es cancella un Sprint, tots els elements de la Llista de Producte (Product Backlog) ja completats i donats per Finalitzats (Done) sn revisats. Si una part del treball s potencialment entregable, el Propietari del Producte (Product Owner) tpicament ho accepta. Tots els elements incomplets de la Llista de Producte (Product Backlog) sn re-estimats i safegeixen de nou a la Llista de Producte (Product Backlog). El treball realitzat en ells es deprecia i pert valor rpidament i ha de ser re-estimat amb freqncia. Cancellacions dels Sprint consumeixen molts recursos, ja que tothom sha de reagrupar en un altre Reuni de Planificaci del Sprint (Sprint Planning Meeting) per comenar un altre Sprint. Les cancellacions del Sprint sn sovint traumtiques per lEquip de Scrum (Scrum Team) i sn molt poc freqents.

Reuni de Planificaci del Sprint (Sprint Planning Meeting)

El treball a realitzar en un Sprint est planificat en la Reuni de Planificaci del Sprint (Sprint Planning Meeting). Aquest pla s creat de forma collaborativa per tots els components de lEquip Scrum (Scrum Team). La Reuni de Planificaci del Sprint (Sprint Planning Meeting) est limitat en el temps, a vuit hores per un Sprint d'un mes, per Sprints ms curts, els Events sn proporcionalment ms curts. El Scrum Master assegura que levent succeix i que els membres que hi son, entenen lobjectiu. El Scrum Master ensenya en lEquip Scrum (Scrum Team) a romandre dins del TimeBox. La Reuni de Planificaci (Sprint Planning Meeting) es contesta a les segents preguntes: Que ser lliurat en lincrement resultant en el prxim Sprint? Quin i com ser el treball necessari per entregar l'increment desitjat?

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 9

Primer Tema: Que es dur a terme en aquest Sprint? :

En aquesta part, lEquip de Desenvolupament (Development Team) treballa per poder pronosticar les funcionalitats que es desenvoluparan durant el Sprint. El Propietari del Producte (Product Owner) discuteix lobjectiu que el Sprint hi hauria de conseguir i els elements de la Llista de Producte (Product Backlog) que si es completen, saconseguir lobjectiu del Sprint, i tot lEquip de Scrum (Scrum Team) collabora en la comprensi del treball a realitzar en el Sprint. La informaci dentrada d'aquesta reuni s la Llista de Producte (Product Backlog), l'ltim Increment del producte, la projectada capacitat de lEquip de Desenvolupament (Development Team) durant el Sprint i lltim rendiment de lEquip de Desenvolupament (Development Team). El nombre d'elements seleccionats de la Llista de Producte (Product Backlog) per el Sprint s decisi exclusiva de lEquip de Desenvolupament (Development Team). Noms lEquip de Desenvolupament (Development Team) pot avaluar del que s capa daconseguir en el prxim Sprint. Desprs lEquip de Desenvolupament (Development Team) decideix quins elements en la Llista de Producte (Product Backlog) es lliuraran en el Sprint, lEquip Scrum (Scrum Team) estableix un objectiu (Goal) en el Sprint. L'objectiu (Goal) del Sprint, s un objectiu que saconseguir mitjanant la implementaci dels elements de la Llista del Producte (Product Backlog), i proporciona lorientaci i una guia en lEquip de Desenvolupament (Development Team) en el perqu s'est construint l'Increment.

Segon Tema: Com s realitzar el treball seleccionat?

Una vegada sha seleccionat el treball a realitzar en el Sprint, lEquip de Desenvolupament (Development Team) decideix com es construir aquestes funcionalitats en un increment del producte Finalitzat (Done) durant el Sprint. Els elements de la Llista del Producte (Product Backlog) seleccionats per aquest Sprint ms el pla per la seva entrega s lanomenat Llista del Sprint (Sprint Backlog). LEquip de Desenvolupament (Development Team) en general comena dissenyant el sistema i el treball que es necessari per convertir la Llista del Producte (Product Backlog ) en un increment de producte. El treball pot ser de valor i esfor estimat. Variable. No obstant aix, en la Reuni de Planificaci del Sprint (Sprint Planning Meeting) es planifica per a qu lEquip de Desenvolupament (Development Team) pugui preveure i pronosticar el que creu que s realitzable en el Sprint que comena. El treball planificat per els primers dies del Sprint per lEquip de Desenvolupament (Development Team) s descomposa per unitats d'un dia o menys en el final o finalitzaci d'aquesta reuni. LEquip de Desenvolupament (Development Team) sauto-organitza per a dur a terme el treball de la Llista del Sprint (Sprint Backlog), durant el Sprint de Planificaci del Sprint (Sprint Planning Meeting) i segons les necessitats en el Sprint.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 10

El Propietari el Producte (Product Owner) por ajudar a clarificar lelements en la Llista de Producte (Product Backlog) i fer concesions. Si lEquip de Desenvolupament (Development Team) determina que t massa treball ,o per contra, massa poc, pot renegociar els elements de la Llista de Producte (Product Backlog) amb el Propietari del Producte (Product Owner). LEquip de Desenvolupament (Development Team) tamb pot convidar altres persones per proporcionar assessorament tcnic, o dins de lmbit que cregui necessari. Al final de la Reuni de Planificaci del Sprint (Sprint Planning Meeting), lEquip de Desenvolupament (Development Team) ha de ser capa d'explicar en el Propietari del Producte (Product Owner) i en el Scrum Mster com es proposa treballar com a equip autoorganitzat per aconseguir l'objectiu (Goal) establert en el Sprint i proporcionar l'increment previst.

Objectiu del Sprint (Sprint Goal)

L'objectiu del Sprint (Sprint Goal) s una fita establerta per el Sprint que pot ser aconseguida mitjanant la implementaci de la Llista de Producte (Product Backlog). Proporciona una gua a lEquip de Desenvolupament (Development Team) del perque sest construint lincrement. s creat duran la Reuni de Planificaci del Sprint (Sprint Planning Meeting). L'objectiu del Sprint (Sprint Goal) proporciona en lEquip de Desenvolupament (Development Team) una mica de flexibilitat pel que fa a la funcionalitat a implementar en el Sprint. Els elements de la Llista del Producte (Product Backlog) seleccionats ofereixen una funci coherent, que pot ser l objectiu (Goal) del Sprint. Lobjectiu (Goal) del Sprint pot representar un altre nexe duni que faci que lEquip de Desenvolupament (Development Team) treballi en conjunt i no en iniciatives separades. Mentre lEquip de Desenvolupament (Development Team) treballa, mant aquest objectiu (Goal) en ment. Per poder satisfer l'objectiu (Goal) del Sprint, implementa i desenvolupa les funcionalitats i la tecnologia necessria. Si el treball a realitzar resulta ser diferent de lesperat per lEquip de Desenvolupament (Development Team), llavors collaboren amb el Propietari del Producte (Product Owner) per re-negociar l'abast de la Llista del Sprint (Sprint Backlog .

Scrum Diari (Daily Scrum)

El Scrum Diari (Daily Scrum) s un esdeveniment fixat en el temps (Time-box) a 15 minuts, per a que lEquip de Desenvolupament (Development Team) pugui sincronitzar les seves activititats i pugui crear un pla per les prximes 24 hores. s basa, en una inspecci i revisi del treball realitzat des de lltim Scrum Diari (Daily Scrum) i poder pronosticar el treball que es podr dur a terme fins al prxim Scrum Diari (Daily Scrum).

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 11

El Scrum Diari (Daily Scrum) es porta a terme diriament a la mateixa hora i ubicaci per reduir la complexitat. Durant la reuni, cada membre del lEquip de Desenvolupament (Development Team) explica: Qu vaig fer ahir que ajuda a lEquip de Desenvolupament (Development Team) a aconseguir la fita (Goal) del Sprint? Qu far avu que ajudar a lEquip de Desenvolupament (Development Team) a aconseguir la fita (Goal) del Sprint? Veig algn impediment que eviti que lEquip de Desenvolupament (Development Team) o jo a aconseguir la fita (Goal) del Sprint?

LEquip de Desenvolupament (Development Team) utilitza el Scrum Diari (Daily Scrum) per poder avaluar el progrs cap a l'objectiu (Goal) del Sprint i per poder avaluar quin s el progrs que est tendint cap a la finalitzaci del treball en la Llista del Sprint (Sprint Backlog). El Scrum Diari (Daily Scrum) optimitza la probabilitat que lEquip de Desenvolupament (Development Team) arribar a lobjectiu (Goal) del Sprint. Cada da lEquip de Desenvolupament (Development Team) , hauria dentendre com treballa en conjunt com un equip autoorganitzat, per a poder aconseguir lobjectiu (Goal) del Sprint i crear lincrement esperat en el final del Sprint. LEquip de Desenvolupament (Development Team) sovint es reuneix immediatament desprs del Daily Scrum per tenir discussion detallades, o per adeptar, o replanificar, el reste del treball del Sprint. El Scrum Mster s'assegura que lEquip de Desenvolupament (Development Team) realitzar la reuni, per lEquip de Desenvolupament (Development Team) s l'encarregat de realitzar el Scrum Diari (Daily Scrum). El Scrum Mster ensenya en lEquip de Desenvolupament (Development Team ) a mantenir el Scrum Diari (Daily Scrum) dins dels 15 minuts fixats. El Scrum Mster refora la regla de qu noms lEquip de Desenvolupament (Development Team ) participa en el Scrum Diari (Daily Scrum). El Scrum Diari (Daily Scrum) millora la comunicaci, elimina la necessitat de tenir altres reunions, identifica i elimina impediments en el desenvolupament, destaca, facilita i promou la presa de decisions rpida i millora el nivell de coneixement de lEquip de Desenvolupament (Development Team ). El Scrum Diari (Daily Scrum) s clau en el procs dinspecci i adaptaci.

La revisi del Sprint (Sprint Review)

La revisi del Sprint (Sprint Review) es porta a terme al final del Sprint per a poder inspeccionar l'increment, i si s necessari, per poder adaptar la Llista de Producte (Product Backlog). Durant la revisi del Sprint (Sprint Review), lequip Scrum (Scrum Team) i les parts interessades collaboren sobre el que sha realitzat en el Sprint. Amb base a lanterior, i alguns canvis en la Llista de Producte (Product Backlog) durant el Sprint, els assistents col. laboren en poder concloure les segents coses que es podran fer per optimitzar el valor. Aquesta s una reuni informal, i la presentaci de l'Increment est pensat per obtenir retroalimentaci i collaboraci. Aquesta s una reuni de temps fixada en el temps (time-box), quatre hores per a un Sprint dun mes. Proporcionalment menys temps s'assigna a Sprints ms curts. Per exemple, Sprints de dues setmanes tenen un Sprint de Revisi (Sprint Review) de dues hores.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 12

La Revisi del Sprint (Sprint Review) inclou els segents elements: Els asistents sn lEquip Scrum (Scrum Team) i els interessats clua invitats per el Propietari del Producte (Product Owner) El Propietari del Producte (Product Owner) explica quins elements de la Llista de Producte (Product Backlog) han estat Fianlitzat (Done) i quins no LEquip de Desenvolupament (Development Team) parla i analitza el que va sortir b durant el Sprint, quins problemes han sorgit, i com es varen solucionar els problemes; LEquip de Desenvolupament (Development Team) demostra el treball que sha Finalitzat "Done" i respon a les preguntes sobre l'increment; El Propietari del Producte (Product Owner) parla i expon la Llista de Producte (Product Backlog) tal com est. Ell o ella projecta o pronostica les dades de finalitzaci probables basades en el procs (si s necessari) ; Tot el grup collabora en qu fer a continuaci, per tal que la Revisi del Sprint (Sprint Review) proporciona valuosa informaci dentrada en els posteriors Reunions de Planificaci dels Sprints (Sprint Planning Meetings). Revisi de com el mercat o ls potencial del producte podria haver canviat el que s de ms valor per fer a continuaci; i, Revisi de la lena de temps, pressupost, capacitats potencials i mercat per la prxima entrega prevista del producte. El resultat de la Revisi del Sprint (Sprint Review) s una revisi de la Llista de Producte (Product Backlog) que defineix probablement els elements de la prxima Llista de Producte (Product Backlog) del prxim Sprint. La Llista de Producte (Product Backlog) s possible que hi hagi o rebi un reajustament per conixer noves oportunitats.

La Retrospectiva del Sprint (Sprint Retrospective)

La Retrospectiva del Sprint (Sprint Retrospective) s una oportunitat per lEquip Scrum (Scrum Team) dinspeccionar-se i per poder crear un pla de millores per ser abordades durant el prxim Sprint. La Retrospectiva del Sprint (Sprint Retrospective) es produeix desprs de la Revisi de Producte (Sprint Review) i abans de la reuni de Planificaci del Sprint (Sprint Planning Meeting). s una reuni fixada (Time-Boxed) a tres hores de duraci en Sprints dun mes. Proporcionalment menys hores s'assignen a Sprints ms curts. El Scrum Master sassegura que la reuni s porti a terme i que els assistents entenguin el seu propsit. El Scrum Master ensenya a tots a mantenir el event dins del temps fixat. El Scrum Master participa en la reuni com un membre de lequip ja que la responsabilitat del procs Scrum, recau sobre ell. Els objectius de la Retrospectiva del Sprint (Sprint Retrospective) son els segents: Inspeccionar com ha anat lltim Sprint pel que fa a lequip, les relacions, processos, i les eines. Per identificar i ordenar els elements o coses que van anar b i el que s potencialment millorable. Crear un pla d implementaci per a les millores mentre lEquip Scrum (Scrum Team) realitza la seves tasques. 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Pgina | 13

El Scrum Mster encoratja lEquip Scrum (Scrum Team) per millorar de forma continua dins del marc de treball (Framework) de Scrum en el tot el seu procs de desenvolupament i en possibles prctiques per fer-ho ms efica i eficient en el prxim Sprint. Durant cada La Retrospectiva del Sprint (Sprint Retrospective) , lEquip Scrum (Scrum Team) planeja maneres d'augmentar la qualitat del producte mitjanant l'adaptaci de la Definici de Finalitzat (Definition of Done), i segons s'escaigui. Al final del la Retrospectiva del Sprint (Sprint Retrospective), lEquip Scrum (Scrum Team) ha identificat millores que implementar en el prxim Sprint. L'aplicaci d'aquestes millores en el prxim Sprint s ladaptaci a la inspecci de lEquip Scrum (Scrum Team ) en si mateix. Encara que les millores es poden implementar en qualsevol moment, la Retrospectiva del Sprint (Sprint Retrospective) proporciona una oportunitat, un event formal, per centrar-se en la inspecci i ladaptaci.

Els Artefactes de Scrum (Scrum Artifacts)

Els Artefactes de Scrum (Scrum Artifacts) representen el treball o el valor til de diferents maneres per poder proporcionar transparncia i o portunitats per a la inspecci i l'adaptaci. Els Artefactes de Scrum (Scrum Artifacts) definits per Scrum estan especficament dissenyats per maximitzar la transparncia d'informaci clau necessria per assegurar-se de que lEquip Scrum (Scrum Team) t lxit en el lliurament d'un Increment de Finalitzat (Done).

Llista de Producte (Product Backlog)

La Llista de Producte (Product Backlog) s una llista ordenada de tot el que es necessari en el producte i s l'nica font de requisits per a qualsevol canvi que es faci en el producte. El Propietari del Producte (Product Owner) s el responsable de la Llista de Producte (Product Backlog), incloent-hi el contingut, la disponibilitat i lordre. La Llista de Producte (Product Backlog) mai s dona per finalitzada o completa. El desenvolupament inicial parteix dels requisits inicialment coneguts i del que millor shagi pogut entendre. La Llista de Producte (Product Backlog) evolucionaa la mateixa manera que el producte i lentorn en el qual ser utilitzat, van a la par evolucionant. La Llista de Producte (Product Backlog) s dinmica; canvia constantment per a poder identificar lo que el producte necessita, per ser adequat, competitiu i til. Mentre un producte existeix, la Llista de Producte (Product Backlog) tamb existeix. La Llista de Producte (Product Backlog) llista totes les caracterstiques, les funcionalitats, els requisits, les millores i correccions que constitueixen els canvis que shauran de fer en el producte en les futures entregues. Els elements de la Llista de Producte (Product Backlog) tenen com atributs la descripci, un ordre, lestimaci i el valor.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 14

A mesura que un producte s'utilitza i guanya en valor, i a la vegada, el mercat proporciona feedback, la Llista de Producte (Product Backlog) es converteix en una llista cada cop ms gran i ms exhaustiva. Els requisits mai deixen de canviar, daquesta manera Llista de Producte (Product Backlog) s un artefacte viu. Els canvis en els requisits de negoci, les condicions del mercat o tecnologia poden provocar canvis en la Llista de Producte (Product Backlog). Mltiples Equips Scrum (Scrum Teams) sovint treballen junts en el mateix producte. Per descriure el treball a realitzar sobre el producte, sutilitza una nica Llista de Producte (Product Backlog). En aquest cas es podria utilitzar un atribut de la Llista de Producte (Product Backlog) per agrupar els elements. El Refinament (Refinement) s l'acte d'afegir detall, estimacions i l'ordre en els elements en la Llista de Producte (Product Backlog). Aquest s un procs de manteniment en qu el Propietari del Producte (Product Owner) i lEquip de Desenvolupament (Development Team) collaboren en els detalls dels elements de la Llista del Producte (Product Backlog). Durant el refinament (Refinement) de la llista del Producte (Product Backlog), els elements es revisen i sactualitzen. LEquip Scrum (Scrum Team) decideix com i quant se fa el refinament (Refinement). Normalment aix no consumeix ms del 10% del temps de lequip de Desenvolupament (Development Team) .No obstant aix, el moment Propietari del Producte (Product Owner) pot actualitzar en qualsevol moment la Llista de Producte (Product Backlog) o a criteri seu. Els elements en la part superior de la Llista del Producte (Product Backlog) estan ms ben definits i amb ms claredat que els elements en la part inferior. Les estimacions ms precises es fan segons a la claredat i a un major detall; com ms inferiors siguin els elements, menys s el detall i la precisi. Els elements de la Llista de Producte (Product Backlog) en els que lEquip de Desenvolupament (Development Team) socupar en el prxim Sprint estan ms desgranats, aquests han estat descompostos de manera que cada un dells pot estar Finalitzats "Done" dins del Sprint fixat. Els elements de la Llista de Producte (Product Backlog) que poden estar Finalitzats "Done" per lEquip de Desenvolupament (Development Team) dins d'un Sprint es consideren "preparats" o "llestos" (Accionable) per a ser seleccionats dins duna Reuni de Planificaci del Sprint (Sprint Planning Meeting). Els elements de la Llista de Producte (Product Backlog) normalment adquireixen aquest grau de transparncia mitjanant les activitats de refinament descrites anteriorment. LEquip de Desenvolupament (Development Team) s el responsable de totes les estimacions. El Propietari del Producte (Product Owner) pot influenciar en Equip de Desenvolupament (Development Team) ajudant a entendre i seleccionar solucions de comproms, per les persones que realitzaran el treball sn les que fan l ltima estimaci.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 15

Monitoritzant el progrs cap a lobjectiu

En qualsevol moment, el treball total restant per assolir un objectiu s pot sumar. El Propietari del Producte (Product Owner) revisa el treball total que queda ,com a mnim des de lltima Revisi del Sprint (Sprint Review). El Propietari del Producte (Product Owner) compara aquesta quantitat amb el treball restant des de lltima Revisi del Sprint (Sprint de Review), per poder avaluar el progrs que queda per poder completar el treball projectat fins al desitjat objectiu (Goal). Aquesta informaci es fa transparent a totes les parts interessades. Diverses tcniques per a poder projectar com sn el burndown, burnup i altres prctiques s'han Utilitzat a preveure el progrs. Totes aquestes shan demostrat ser tils. No obstant aix, aqueste tcniques no substitueixen la importncia de lempirisme. En entorns complexos, on el qu passar s molt incert. Noms el que ha passat pot ser utilitzat per a la presa de decisions amb visi de futur.

La Llista del Sprint (Sprint Backlog)

La Llista del Sprint (Sprint Backlog) s el conjunt delements dins de la Llista de Producte (Product Backlog) que han estat seleccionats per el Sprint, a ms sinclou, un pla per a poder entregar un Increment del producte i poder realitzar lobjectiu (Goal),del Sprint. La Llista del Sprint (Sprint Backlog)es una previsi per lEquip de Desenvolupament (Development Team) sobre quina funcionalitatestar finalitzada en el nou increment i el quin s treball necessari per a poder entregar la funcionalitat. La Llista del Sprint (Sprint Backlog) defineix el treball que lEquip de Desenvolupament (Development Team) realitzar per convertir elements de la Llista de Producte (Product Backlog) en un Increment de producte Finalitzat (Done) ". La llista del Sprint (Sprint Backlog) fa visible tot el treball en el que lEquip de Desenvolupament (Development Team) identifica com a necessari per assolir l'objectiu. La llista del Sprint (Sprint Backlog) s un pla amb suficient detall on els canvis engegats poden ser entesos en el Scrum Diari (Daily Scrum). LEquip de Desenvolupament (Development Team) modifica la Llista del Sprint (Sprint Backlog) al llarg del Sprint, i la Llista del Sprint (Sprint Backlog) sorgeix durant el Sprint. Aquesta emergncia es produeix mentre lEquip de Desenvolupament (Development Team) treballa mitjanant el pla i aprn ms sobre el treball necessari per assolir l'objectiu (Goal) del Sprint. Mentre es va demanant nou treball, lEquip de Desenvolupament (Development Team) el va afegint en la Llista del Sprint (Sprint Backlog). Mentre el treball s va realitzant o s completat, s'actualitza lestimaci del treball restant. Quant alguns elements del pla es considerin innecessaris, aquests es retiren. Noms lEquip de Desenvolupament (Development Team) pot canviar el seva Llista del Sprint (Sprint Backlog), nicament durant un Sprint. La Llista del Sprint (Sprint Backlog) s una fotografia molt visible en temps real, sobre el treball planificat a realitzar durant el Sprint, i pertany nicament al lEquip de Desenvolupament (Development Team).

Monitoritzant el progrs del Sprint

En qualsevol moment dins dun Sprint, el treball total que falta per realitzar i completar en el Sprint Backlog pot ser monitoritzat. lEquip de Desenvolupament (Development Team) revisa tot el treball que resta des de lltim Scrum Diari (Daily Scrum). LEquip de Desenvolupament (Development Team) revisa lestat diari i projecta la probabilitat darribar a lobjectiu dins del Sprint. Revisant el treball que resta durant el Sprint, lEquip de Desenvolupament (Development Team) pot gestionar el seu progrs. 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Pgina | 16

Scrum no t en compte el temps que sha utilitzat treballant amb els elements en el Sprint Backlog. El treball que resta per acabar i les dates noms son les variables de inters.

Increment
LIncrement s la suma de tots els elements en la Llista del Producte (Product Backlog) completats en el Sprint i el valor de tots els increments en els Sprints anteriors. Al finalitzar el Sprint, el nou increment ha destar Finalitzat (Done), el que significa que ha destar en condiciones de ser utilitzat i estar dins de la Definici de Finalitzat (Definition of Done). El sincrement han destar en un estat de ser utilitzat, independentment de si Propietari del Producte (Product Owner) decideix realment lliberar lentrega.

Transparncia dels Artefactes (Artifacts)

Scrum es basa en la transparncia. Les decisions per optimitzar el valor i controlar els riscs s prenen basant-se en lestat percebut dels artefactes (Artifacts). En la mesura que la transparncia sigui completa, aquestes decisions tenen unes bases slides. En la mesura en qu els Artefactes (Artifacts ) no sn completament transparents, aquestes decisions poden ser erronis, el valor pot disminuir i el risc pot augmentar. El Scrum Master ha de treballar amb el Propietari de Producte (Product Backlog), lEquip de Desenvolupament (Development Team) i altres parts involucrades per entendre si els artefactes sn completament transparents. Hi ha prctiques per fer front a la falta de transparncia; el Scrum Master ha dajudar a tots a aplicar les prctiques ms apropiades si no hi ha una transparncia completa. Un Scrum Master pot detectar la falta de transparncia inspeccionant els artefactes, reconeixent patrons, escoltant atentament el que s diu i detectant diferencies entre els resultats esperats i reals. La funci del Scrum Master s treballar amb lEquip Scrum (Scrum Team), i lorganitzaci per millorar la transparncia dels artefactes (Artifacts). Aquest treball, usualment inclou aprenentatge, convicci i canvi. La transparncia no apareix de la nit al dia, sin que es un cam.

Definici de Finalitzat (Definition of Done)

Quant un element de la Llista de Producte (Product Backlog) o un increment s descrit com a Finalitzat (Done), tothom ha d entendre el que significa el terme de Finalitzat (Done). Encara que aix pot variar de forma significativa per Equips Scrum (Scrum Teams), tots els membres han de tenir un idea comuna i compartida del que significa que el treball sha completat, per a poder assegurar la transparncia. Aquesta es la Definici de Fet (Definition of Done) per lEquip Scrum (Scrum Team) s utilitzada per assegurar quant el treball es completat en el Increment del producte. La mateixa definici guia en lEquip de Desenvolupament (Development Team) per a poder saber quant els elements de la Llista de Producte (Product Backlog) poden ser seleccionats en el Reuni de Planificaci del Sprint (Sprint Planning Meeting). Lobjectiu (Goal) de cada Sprint es entregar increments de funcionalitats potencialment entregables que sescauen dins de la definici de Finalitzat (Definition of Done) de lEquip Scrum (Scrum Team).

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 17

lEquip de Desenvolupament (Development Team) entrega un increment en la funcionalitat del producte en cada Sprint. Aquest increment ha de ser utilitzable, daquesta manera el Propietari del Producte (Product Owner) pot decidir de forma immediata entregar-ho. Cada increment es sumable a tots els increments anteriors i testejats de forma minuciosa, de manera que tots els increments els actuals i els passats, funcionen correctament de forma conjunta. A mesura que lEquip Scrum (Scrum Team) madura, sespera que la definici de Finalitzat (Definition of Done) sexpandir per anar incloent-hi criteris ms restringits per proporcionar una ms alta qualitat.

Nota Final
Scrum s gratut, ofert i explicat en aquesta guia. Els rols (Roles) dins de Scrum, els Artefactes (Artifacts) , els Events i les Regles (Rules) sn immutables i encara que es possible implementar nicament parts de Scrum, el resultat final no es Scrum. Scrum existeix nicament en la seva totalitat i funciona correctament com a contenidor per altres tcniques, metodologies o prctiques.

Agraments
Persones
Dels milers de persones que han contribut en Scrum, volem destacar aquells qui varen contribuir en els primers deu anys. Primer va ser Jeff Sutherland, treballant amb Jeff McKenna i Ken Schwaben, i Mike Smith amb Chris Martin. Molts altres varen contribuir en els subseqents anys i sense la seva ajuda Scrum no estaria tan refinat com ho s avui.

Historia
Ken Schwaben i Jeff Sutherland varen representar per primera vegada Scrum en la conferncia d'OOPSLA el 1995. En aquesta presentaci essencialment es va documentar l'aprenentatge que Ken i Jeff havien realitzat en els anys anteriors en l'aplicaci de Scrum. La histria de Scrum es pot considerar llarga. L'honor en els primers llocs en el que va ser provat i Refinat i perfeccionat, mencionem a Individual Inc.,Fidelity Investments i IDX (ara GE Medial). La guia de Scrum ha estat desenvolupada i sostinguda per ms de vint anys per Jeff Sutherland i Ken Schwaben. Altres fonts ofereixen patrons, processos i idees sobre com les prctiques, facilitats i que complementen el marc de treball (Framework) de Scrum. Aquestes optimitzen la productivitat, el valor, la creativitat i lorgull.

Traducci
Aquesta guia ha estat traduda de la release original en angls, proporcionada per Ken Schwaber i Jeff Sutherland. Ha realitzat la traducci en catal el Sr.David Mart Lleida.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 18

Canvis entres les Guies del 2011 i 2013

Els artefactes han de ser transparents per a qu els mecanismes d inspecci i dadaptaci de Scrum siguin efectius. Una discussi addicional daquest requisit ha estat afegida. El Scrum Diari (Daily Scrum) s un event de planificaci just-in-time en Scrum. L entrada hauria de ser com lequip ho est fent cap a la consecuci de lObjectiu (Goal) del Sprint, la sortida hauria de ser un pla nou revisat que optimitzi els esforos, de lequip per arribar lObjectiu (Goal) del Sprint. Totes les conversacions sorienten en la forma Nosaltres lequip en contra de Jo, el desenvolupador. La Reuni de Planificaci del Sprint (Sprint Planning Meeting) s ara un event, ja no s un doble event de que/com. Desenvolupar un Objectiu (Goal) del Sprint inicia el Event, desprs es compara, el que es necessita, per aconseguir lObjectiu (Goal) del Sprint amb el que be i la capacitat del possible, i finalment es desenvolupa un pla per obtenir lObjectiu (Goal) del Sprint durant el Sprint. La llista del Producte (Product Backlog) es refina (Refinement) i no es prepara (Grooming). Els elements de la Llista del Producte Refinats sn transparents, el suficientment ben entesos com per a servir dentrada a la Reuni de Planificaci del Sprint (Sprint Planning Meeting) i per la seva selecci en el Sprint. Els elements de la Llista de Producte (Product Backlog) amb aquesta transparencia es diuen Llestos (Ready). Tots el events estan definits per succeir en un bloc de temps (time-boxed). La quantitat de temps descrita s la mxima quantitat disponible. Els Sprints de menys dun mes de duraci normalment no requereixen daquest temps mxim. La sortida de la Revisi del Sprint (Sprint Review) es una llista de Producte (Product Backlog) potencialment reorganitzada, on els elements de la Llista de Producte (Product Backlog) de ms valor sn els principals candidats a ser seleccionats en la Reuni de Planificaci (Sprint Planning Meeting) del Sprint segent. La Reuni de Planificaci del Sprint (Sprint Planning Meeting) defineix la funcionalitat en lincrement plantejat i palneja com lequip de Desenvolupament (Development Team) crear aquest increment. s definexi un Objectiu (Goal) del Sprint per resumir la sortida daquest treball.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Pgina | 19