Artefactes de Scrum

Scrum defineix tres artefactes: el Product Backlog, el Sprint Backlog i l'Increment. Cadascun té un compromís associat que garanteix que l'artefacte aporta valor i transparència.

Artefacte	Compromís associat	Respon a
Product Backlog	Product Goal	Que volem construir en total?
Sprint Backlog	Sprint Goal	Que construirem aquest sprint?
Increment	Definition of Done	Que significa "acabat"?

---

Product Backlog

El Product Backlog és la llista ordenada de tot el treball que podria fer-se al producte o projecte. És la font única de veritat sobre que queda per fer.

Característiques

• Ordenat per valor: els items amb més valor (o prioritat) estan a dalt. L'equip sempre treballarà els items superiors primer.
• Viu i canviant: el PO pot afegir, eliminar, reordenar o refinar items en qualsevol moment (excepte durant el sprint en curs).
• Emergent: el backlog no cal que estigui complet al principi del projecte. Creix i s'affina a mesura que l'equip aprèn.

Histories d'usuari (User Stories)

La forma més habitual d'expressar items del backlog és la història d'usuari, un requisit descrit des del punt de vista de l'usuari:

Com a [tipus d'usuari],
vull [fer alguna cosa],
per tal de [obtenir algun benefici].

Exemple per a un projecte de sistemes:

Com a administrador de sistemes,
vull rebre una alerta per correu quan el disc d'un servidor superi el 85% d'us,
per tal de poder actuar abans que el servidor quedi sense espai.

Criteris d'acceptació

Cada historia d'usuari ha de tenir criteris d'acceptació clars: condicions objectives i verificables que determinen si la historia esta completada.

Historia: Alerta per disc ple

Criteris d'acceptació:
- [ ] El sistema monitoritza tots els servidors de produccio cada 5 minuts.
- [ ] S'envia un correu a sysadmin@empresa.cat quan l'us supera el 85%.
- [ ] L'alerta inclou: nom del servidor, particio afectada, percentatge d'us actual.
- [ ] Si l'us supera el 95%, s'envia a sysadmin@empresa.cat i a cap.sistemes@empresa.cat.
- [ ] Es poden configurar els llindar d'alerta sense modificar el codi.

Estimació: Story Points

Els items del backlog s'estimen en Story Points (punts d'historia), una unitat relativa que mesura la complexitat i l'esforç percebut per l'equip — no les hores.

S'utilitza la sèrie de Fibonacci: 1, 2, 3, 5, 8, 13, 21... La raó és que com més gran és la tasca, menys precisa és l'estimació, i la sèrie reflecteix aquesta incertesa.

Planning Poker: cada membre de l'equip vota simultàniament la seva estimació. Si hi ha divergències grans, es discuteix i es torna a votar. Aixo garanteix que tothom entén la tasca i evita l'efecte d'ancoratge (seguir el primer que parla).

---

Sprint Backlog

El Sprint Backlog és el conjunt d'items del Product Backlog seleccionats per al sprint actual, més el pla detallat per completar-los.

Estructura

flowchart LR
    subgraph PB["Product Backlog"]
        I1["Item 1 — 8pts"]
        I2["Item 2 — 5pts"]
        I3["Item 3 — 3pts"]
        I4["..."]
    end

    subgraph SB["Sprint Backlog (Sprint 3)"]
        direction TB
        SI1["Item 1\n· Tasca A\n· Tasca B\n· Tasca C"]
        SI2["Item 2\n· Tasca D\n· Tasca E"]
        SI3["Item 3\n· Tasca F"]
    end

    I1 --> SI1
    I2 --> SI2
    I3 --> SI3

    style I1 fill:#1565c0,stroke:#0d47a1,color:#fff
    style I2 fill:#1565c0,stroke:#0d47a1,color:#fff
    style I3 fill:#1565c0,stroke:#0d47a1,color:#fff

El tauler del Sprint

Visualment, el Sprint Backlog es representa en un tauler Kanban simplificat:

Per fer	En curs	Fet
Tasca D	Tasca B	Tasca A
Tasca E	Tasca C
Tasca F

El Sprint Backlog es propietat de l'equip

Ninguú de fora de l'equip (ni el PO, ni el SM, ni el cap) pot afegir tasques al Sprint Backlog durant el sprint. Si sorgeix una urgència real, el PO i el SM decideixen conjuntament si cal cancel·lar el sprint o si pot esperar al proper.

---

Increment

L'Increment és la suma de tots els items completats durant el sprint, mes tots els increments de sprints anteriors. Es el producte acumulat fins al moment.

Per ser considerat un Increment real, el treball ha de passar la Definition of Done.

Definition of Done (DoD)

La Definition of Done és una llista de criteris que qualsevol item ha de complir per considerar-se completat. Es l'acord de qualitat de l'equip.

Exemple de DoD per a un equip de sistemes:

Definition of Done — Equip de Sistemes ASIX

Un item es considera DONE quan:
[ ] La configuració esta implementada a l'entorn de produccio (o staging si no hi ha prod).
[ ] La configuració esta documentada al wiki intern (URL i data).
[ ] S'han executat les proves de funcionament descrites als criteris d'acceptació.
[ ] El codi de configuracio (scripts, playbooks Ansible, etc.) esta al repositori Git.
[ ] Una altra persona de l'equip ha revisat la configuració (peer review).
[ ] No hi ha alertes crítiques actives relacionades amb el canvi.

La DoD es per a tot l'equip, no per a cada item

La DoD s'aplica igual a tots els items del backlog. Si un item no pot complir algun criteri de la DoD, cal revisar el criteri o fer l'item en un futur sprint quan sigui possible complir-lo.

La DoD és evolutiva: a cada retrospectiva, l'equip pot decidir afegir-hi nous criteris per millorar la qualitat.

Activitat AC-RA2-03

Per al vostre projecte de pràctiques:

1. Escriviu almenys 5 histories d'usuari en format "Com a... vull... per tal de...".
2. Per a cada historia, escriviu 3-5 criteris d'acceptació específics i verificables.
3. Estimeu les histories amb Planning Poker (cada membre del grup vota simultàniament).
4. Definiu la vostra Definition of Done (minim 5 criteris).
5. Ordeneu el backlog per prioritat i justifiqueu l'ordre.