Metodologia àgil al BIT: Scrum@BIT
El programa oficial només dona el títol d'aquest tema, sense dir què hi entra: el que hi ha aquí ho hem triat nosaltres segons el que se sol preguntar
Enunciat oficial. Metodologia àgil a l'Institut Municipal Barcelona Innovació i Tecnologia (BIT): Scrum@BIT (marc, fases, rols, governança i artefactes).
Nomenclatura. L'IMI (Institut Municipal d'Informàtica) va passar a dir-se BIT (Barcelona Innovació i Tecnologia) el 28 de novembre de 2025. El document metodològic oficial encara es titula Scrum@IMI: tots dos noms poden aparèixer en un enunciat.
1. Scrum: el marc de referència
Definició de la Guia Scrum: Scrum és un marc de treball lleuger que ajuda persones, equips i organitzacions a generar valor a través de solucions adaptatives per a problemes complexos. No és una metodologia: és un marc intencionadament incomplet, que només defineix les parts necessàries per implementar la teoria Scrum.
Davant dels mètodes clàssics en cascada —abast tancat des del principi—, el que fa determinant Scrum és la necessitat de lliuraments parcials de funcionalitats desplegables a producció, que aportin valor a la persona usuària de manera progressiva, Sprint a Sprint.
Fonament: l'empirisme. El coneixement prové de l'experiència i les decisions es prenen sobre el que s'observa. Scrum és també lean: redueix el malbaratament i se centra en l'essencial.
1.1 Els tres pilars
Transparència — el procés i el treball emergent han de ser visibles tant per als qui executen com per als qui reben la feina. Inspecció — els artefactes i el progrés cap als objectius s'han d'inspeccionar amb freqüència i diligència per detectar variacions o problemes potencials. Adaptació — si algun aspecte del procés es desvia dels límits acceptables o el producte resultant és inacceptable, s'ha d'ajustar el procés o el material al més aviat possible.
1.2 Els cinc valors
Compromís, Focus, Obertura, Respecte i Coratge (Commitment, Focus, Openness, Respect, Courage). L'ús exitós de Scrum depèn de la capacitat de les persones de viure aquests cinc valors.
1.3 L'equip Scrum
Característiques que cauen literalment: l'Scrum Team és:
- petit, típicament de 10 persones o menys;
- multifuncional (cross-functional): els seus membres tenen totes les habilitats necessàries per crear valor a cada Sprint;
- autogestionat (self-managing): decideixen internament qui fa què, quan i com;
- una sola unitat enfocada a un objectiu, el Product Goal;
- responsable de totes les activitats relacionades amb el producte: col·laboració amb els interessats, verificació, manteniment, operació, experimentació, recerca i desenvolupament.
Tres responsabilitats (a la Guia Scrum 2020 ja no s'anomenen «rols»): el Product Owner respon del valor del producte; l'Scrum Master, d'establir Scrum tal com el defineix la Guia i de l'eficàcia de l'equip —facilita, entrena i elimina impediments—, i els Developers, de crear un Increment utilitzable a cada Sprint. La taula ho detalla:
| Product Owner | Scrum Master | Developers | |
|---|---|---|---|
| Responsabilitat | maximitzar el valor del producte resultant del treball de l'equip | establir Scrum tal com es defineix a la Guia i l'eficàcia de l'equip; proposar, promoure i potenciar millores sobre la forma de treball i sobre l'equip | crear un Increment utilitzable a cada Sprint |
| Sobre el backlog | és responsable de la gestió eficaç del Product Backlog (la pila de producte): desenvolupar i comunicar explícitament l'Objectiu de Producte, crear i comunicar clarament els elements, ordenar-los i assegurar que el backlog és transparent, visible i comprès | facilita, entrena i elimina impediments; tasques de coordinació de l'inici de l'Sprint: crear la pàgina d'informació de l'Sprint, avisar l'equip que comença i actualitzar les estadístiques de velocitat i capacitat | fan el Sprint Backlog, hi apliquen la Definició d'Acabat, ajusten el pla diàriament i es responsabilitzen mútuament com a professionals |
| Persona | una sola persona, no un comitè. Pot delegar la feina, però la responsabilitat continua sent seva | una persona; líder servidor | típicament 3–9 persones |
| Decisió | perquè els seus criteris tinguin èxit, tota l'organització els ha de respectar; ningú no pot obligar l'equip a treballar en un requisit diferent | — | ningú els diu com convertir el backlog en increments |
El que NO és funció del Product Owner: gestionar el pressupost del projecte, assignar tasques als desenvolupadors, dirigir tècnicament l'equip o fer d'interlocutor únic amb el proveïdor. La seva funció és el valor i el backlog.
1.4 Els cinc esdeveniments
| Esdeveniment | Durada màxima (Sprint d'1 mes) | Propòsit |
|---|---|---|
| Sprint | un mes o menys; és el contenidor de la resta | crear consistència; no es fan canvis que posin en perill l'Objectiu de l'Sprint, la qualitat no baixa, el Product Backlog es refina segons calgui i l'abast es pot clarificar i renegociar amb el Product Owner |
| Sprint Planning | màxim 8 hores | tres temes: per què és valuós aquest Sprint (Objectiu de l'Sprint), què es pot fer (selecció d'elements del backlog), com es farà (pla) |
| Daily Scrum | 15 minuts, cada dia, mateix lloc i hora | inspeccionar el progrés cap a l'Objectiu de l'Sprint i adaptar el Sprint Backlog. És per als Developers; si el Product Owner o l'Scrum Master hi treballen activament hi participen com a Developers, però no és una reunió oberta a qualsevol interessat |
| Sprint Review | màxim 4 hores | inspeccionar el resultat amb els interessats i determinar futures adaptacions; és una sessió de treball, no una presentació. Hi assisteixen el Product Owner, l'Scrum Master, els Developers i les persones interessades clau que el Product Owner convida — no és una reunió tancada a l'Scrum Team |
| Sprint Retrospective | màxim 3 hores | planificar maneres d'augmentar la qualitat i l'eficàcia: inspeccionar com ha anat pel que fa a individus, interaccions, processos, eines i Definició d'Acabat, identificar què ha anat bé, quins problemes hi ha hagut i com s'han resolt (o no) |
Un Sprint nou comença immediatament després de la finalització de l'anterior. Els Sprints més curts es poden fer servir per generar més cicles d'aprenentatge i limitar el risc. La durada del Sprint, un cop triada, es manté constant durant tot el projecte: si canvien les prioritats o s'incorpora feina no prevista, el que es replanifica és l'abast, mai el calendari.
Els quatre esdeveniments giren dins de l'Sprint, que els conté: de la retrospectiva es torna directament a la planificació següent.
Cancel·lació de l'Sprint: només el Product Owner té l'autoritat per cancel·lar un Sprint, i només si l'Objectiu de l'Sprint esdevé obsolet. Passa poques vegades.
Si el Product Owner vol incorporar feina no prevista en ple Sprint, l'Scrum Master facilita que sigui l'equip qui valori la capacitat i la disposició per assumir-la — no ho decideix unilateralment ni ho imposa; l'alternativa és esperar-se al Sprint següent o replanificar l'Sprint actual amb el Product Owner.
1.5 Els tres artefactes i els seus compromisos
| Artefacte | Què és | Compromís |
|---|---|---|
| Product Backlog | llista emergent i ordenada del que cal per millorar el producte; única font de treball de l'equip | Objectiu de Producte (Product Goal) |
| Sprint Backlog | l'Objectiu de l'Sprint (per què), el conjunt d'elements seleccionats (què) i el pla per lliurar l'Increment (com); és un pla fet pels Developers i per als Developers | Objectiu de l'Sprint (Sprint Goal) |
| Increment | pas concret cap a l'Objectiu de Producte; cada Increment és additiu i verificat; ha de ser utilitzable. Poden crear-se diversos Increments dins d'un Sprint | Definició d'Acabat (Definition of Done) |
- Refinament del Product Backlog (refinement): activitat contínua —no és un esdeveniment— de descompondre i definir els elements en ítems més precisos i petits, afegint detall, ordre i estimació.
- Definició d'Acabat: descripció formal de l'estat de l'Increment quan compleix les mesures de qualitat requerides per al producte. Si un element no compleix la Definició d'Acabat, no es pot lliurar ni presentar a la Sprint Review i torna al Product Backlog.
- Definició de Preparat (Definition of Ready): no forma part de la Guia Scrum, però és pràctica habitual: criteris perquè un element pugui entrar a un Sprint.
1.6 Estimació i seguiment
- Punts d'història (story points): unitat relativa que combina esforç, complexitat i incertesa. No són hores. Tècnica habitual: planning poker amb la seqüència de Fibonacci modificada (1, 2, 3, 5, 8, 13, 20, 40, 100).
- Velocitat (velocity): punts completats per Sprint. Serveix per previsió —per exemple, per estimar la capacitat d'un Sprint quan canvia el nombre de persones de l'equip—, no per comparar equips ni per avaluar persones.
- Gràfic burn-down: eix horitzontal = dies de l'Sprint; eix vertical = treball restant, en punts d'història de l'Sprint (no del projecte sencer). La línia ideal baixa fins a zero de manera constant; una baixada menys pronunciada que la prevista vol dir que s'avança més a poc a poc (no que s'ha fet més feina), i una pujada indica que ha entrat treball nou o que s'ha reestimat a l'alça. Burn-up: mostra el treball completat contra l'abast total, i fa visibles els canvis d'abast.
- Capacitat: si un equip de 3 persones preveia executar 20 punts i n'executa menys, la conversa correcta és revisar la capacitat i les causes a la retrospectiva i ajustar la previsió del Sprint següent, no augmentar el compromís ni allargar l'Sprint.
2. Altres marcs àgils
- Kanban: sistema pull de flux continu, centrat a limitar el WIP (Work In Progress, el treball en curs) per detectar colls d'ampolla. No té sprints ni rols prescrits, a diferència de Scrum. Scrumban en combina els dos.
- XP (eXtreme Programming): afegeix pràctiques d'enginyeria a l'agilitat —programació en parella, TDD (Test-Driven Development), integració contínua— que Scrum no prescriu.
- Lean: eliminar el malbaratament i centrar-se en l'essencial.
- Escalat: SAFe, LeSS, Nexus, Spotify model i Disciplined Agile apliquen Scrum a diversos equips alhora; cap no és a l'enunciat d'aquest tema i no s'hi entra en detall.
Un tauler Kanban fa visible el límit de WIP: la columna que el supera és el coll d'ampolla, i ningú no n'hi estira més feina fins que no es buida.
3. Scrum@BIT: l'adaptació municipal
El Scrum@IMI és l'adaptació de Scrum al context de l'Institut. L'objectiu declarat és aprofitar els avantatges d'aquest conjunt de pràctiques i eines àgils en un entorn amb tres condicionants que Scrum «pur» no contempla:
- La feina la fan proveïdors externs adjudicataris de contractes públics, no una plantilla interna: quan la insuficiència de recursos humans propis coincideix amb un abast puntual i limitat, l'Ajuntament hi recorre per contractació pública en lloc d'ampliar plantilla.
- Hi ha procediment administratiu: expedients, fites contractuals, facturació i justificació.
- Hi ha múltiples àrees de negoci municipals com a demandants, i una cartera de projectes que s'ha de governar.
3.1 Aportacions del marc
- Focus en la persona usuària final: el marc posa l'èmfasi a millorar l'experiència d'usuari i no només a lliurar funcionalitat.
- Millor mesura i priorització dels projectes.
- Més flexibilitat en el lliurament i reducció dels terminis.
- Treball dels requisits conjuntament amb els equips tècnics des del principi.
3.2 Fases
El marc estructura el treball en fases que enllacen la vessant administrativa amb la iterativa:
- Iniciació / Descobriment: identificació de la necessitat, definició de la visió del producte, identificació dels usuaris, primera versió del backlog i estimació de gruix. És on es prepara la licitació o l'encàrrec.
- Planificació: constitució de l'equip, definició de la Definició d'Acabat, planificació de releases i de la primera onada de Sprints.
- Execució iterativa: Sprints amb els cinc esdeveniments, integració contínua i lliuraments incrementals.
- Lliurament i desplegament (release): pas a producció, formació, comunicació i traspàs a operació.
- Tancament: tancament administratiu i contractual, lliçons apreses i mesura del valor obtingut.
Frontera amb PMBOK: la fase d'Iniciació és quan, seguint la terminologia PMBOK (Project Management Body of Knowledge) del PMI (Project Management Institute), s'ha de disposar de l'acta de constitució del projecte (project charter). L'acta inclou, entre altres coses, el cas de negoci del projecte —per què val la pena fer-lo—; no hi porten encara ni una estratègia detallada de gestió de riscos, ni estimacions dels paquets de treball, ni estimacions detallades de recursos: aquest detall arriba després, a la planificació, quan ja hi ha acta i s'ha autoritzat el projecte.
3.3 Rols
Als tres de Scrum, el marc municipal hi afegeix o precisa:
- Product Owner: ha de ser una persona de l'Ajuntament o del BIT, no del proveïdor: qui decideix el valor és l'Administració. Sovint es distingeix entre el PO (Product Owner) de negoci (l'àrea municipal demandant) i un PO tècnic o proxy al BIT.
- Scrum Master: pot ser del BIT o del proveïdor segons el contracte; facilita i elimina impediments.
- Equip de desenvolupament: normalment del proveïdor.
- Cap de projecte del BIT / gestor de la demanda: responsable de la relació contractual, del pressupost i de la coordinació amb altres sistemes.
- Òrgans de governança: comitè de seguiment del contracte i comitè de direcció o comitè de producte, on es prioritza la cartera i es resolen escalats.
3.4 Governança i contractació
- El contracte defineix una capacitat d'equip (perfils i dedicació) i un marc de lliurament per Sprints, en lloc d'un abast tancat.
- Els lliurables contractuals s'associen a Sprints acceptats o a fites de valor; l'acceptació formal segueix el procediment administratiu.
- La Definició d'Acabat incorpora els requisits municipals no negociables: accessibilitat —WCAG (Web Content Accessibility Guidelines) 2.1, nivell
AA—, seguretat i compliment de l'ENS, protecció de dades, documentació, codi obert i reversibilitat, segons la Mesura de digitalització oberta. - El codi es lliura a l'Ajuntament i, quan escau, es publica amb llicència lliure.
3.5 Adopció obligatòria del marc
Un equip sense experiència prèvia al BIT ha d'adoptar el marc Scrum@IMI/BIT publicat per l'Institut, que és d'aplicació obligatòria per als proveïdors — no pot proposar la seva pròpia metodologia ni aplicar Scrum «de manual» ignorant el marc municipal.
Claus d'examen
- Els eixos del burn-down i el sentit del pendent. Horitzontal = dies de l'Sprint; vertical = treball restant en punts d'història de l'Sprint, no del projecte. El tribunal sol oferir una opció que inverteix els eixos o que parla del projecte sencer (TM-TIC 2021-OP, específic, p. 13; TS-TIC 2025, pràctica s1, p. 23).
- Qui pot cancel·lar un Sprint: sempre el Product Owner, mai l'Scrum Master ni l'equip, i només si l'Objectiu de l'Sprint queda obsolet (TS-TIC 2023, pràctica s1, p. 19).
- La durada del Sprint no canvia mai a mig projecte, encara que es reprioritzi el backlog o s'incorpori feina nova: el que es replanifica és l'abast, no el calendari (TM-TIC 2021-OP, pràctica s3, p. 20).
- La Sprint Review no és tancada a l'Scrum Team: hi assisteixen també les persones interessades clau que convida el Product Owner (TM-TIC 2021-OP, pràctica s3, p. 22).
- Product Owner i Scrum Master es confonen sovint: el PO decideix el valor i gestiona el backlog; l'Scrum Master no decideix res del contingut, només facilita el procés i elimina impediments (TS-TIC 2018, pràctica s1, p. 23-24).
- L'acta de constitució d'un projecte porta el cas de negoci, no estimacions detallades: aquestes arriben després, a la planificació (TS-TIC 2021, pràctica s1, p. 11).
Per recordar
- Scrum és un marc lleuger i intencionadament incomplet, fonamentat en l'empirisme.
- Pilars: transparència, inspecció, adaptació. Valors: compromís, focus, obertura, respecte, coratge.
- L'equip és petit (≤10), multifuncional i autogestionat; no hi ha subequips ni jerarquies.
- El Product Owner és una sola persona, responsable de maximitzar el valor i de la gestió del Product Backlog; ningú no pot obligar l'equip a treballar en un requisit diferent del que ell ha ordenat.
- Només el Product Owner pot cancel·lar un Sprint, i només si l'Objectiu de l'Sprint queda obsolet.
- Daily 15 min · Planning 8 h · Review 4 h · Retrospectiva 3 h (per a Sprints d'un mes).
- Tres artefactes i tres compromisos: Product Backlog → Objectiu de Producte; Sprint Backlog → Objectiu de l'Sprint; Increment → Definició d'Acabat.
- El refinament no és un esdeveniment: és activitat contínua.
- Punts d'història ≠ hores; la velocitat no serveix per comparar equips.
- A Scrum@BIT el Product Owner és de l'Administració, i el marc és d'aplicació obligatòria per als proveïdors.
Fonts d'aquest tema
- Marc de treball Scrum@IMI per a proveïdors — https://ajuntament.barcelona.cat/institut-innovacio-tecnologia/sites/default/files/2023-11/marc_de_treball_scrumimi_per_proveidors.pdf
- RD 311/2022, pel qual es regula l'Esquema Nacional de Seguretat — https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
- Mesura de govern per a la digitalització oberta: programari lliure i desenvolupament àgil de serveis — https://ajuntament.barcelona.cat/digital/sites/default/files/2023-10/le_mesuradegovern_v2.pdf