calaix[À]gil


CAT | ESP | EN



La reunió de Refinement. Detalls que cal conèixer

CAT, ESP

calaix[À]gil | Articles (CAT) | Activitats i bones pràctiques àgils
Data publicació: 08/11/2022
Última modificació: 19/04/2023
La reunió de Refinement és una de les més desconegudes per a tot aquell que comença en Scrum. En aquest article intentarem explicar perquè necessitem aquest tipus de reunions

La reunió de Refinement sovint és incompresa pels equips Scrum. Això pot ser degut al fet que falta una mica de context a l’hora d’entendre com funcionen les reunions i, especialment, com funciona el Sprint en un projecte en Scrum.



Per explicar-ho d’una forma entenedora: La reunió de Refinement serveix per a tot allò que és necessari per a l’èxit del projecte; i que no està cobert per a les reunions estàndards de Scrum (Sprint Planning, Sprint Review, Sprint Retrospective i Daily).

Llavors podem (o hauríem de) preguntar-nos: Què cal fer en el projecte que no pugui tractar-se en una planning, review o retro?

A continuació, tractem les més crítiques.


Tractar problemes

Sovint, en el curs d’un sprint, apareix quelcom no previst. Una barrera tecnològica, un problema organitzatiu en l’equip, un problema de comunicació amb algun dels interessats o, molt sovint, dubtes sobre allò que es creia entès.


Hi ha una màxima en la gestió de projectes per tots coneguda: Els problemes s’han de tractar tan bon punt hi apareixen. No és bona pràctica esperar a una Review per tractar un problema. De fet, podria considerar-se fins i tot una falta de respecte cap al Product Owner (recordem els valors àgils: compromís, enfocament, receptivitat als canvis, respecte i coratge). La Review és el lloc per a mostrar l’increment i verificar el valor que hi produeix a l’organització. No és el lloc per a resoldre problemes que estan afectant el Sprint.

Quan hi ha un problema, les parts afectades i les parts que poden proporcionar alguna solució o mitigació, s’hi reuneixen de la forma més àgil i ràpida possible. Aquesta reunió és un Refinement dins del marc de treball Scrum.



Avançar feina

Un aspecte que de vegades resulta una mica complicat d’entendre per part de l’equip, és que el Sprint no serveix únicament per a construir allò compromés en un Sprint Planning. Aquest temps d’Sprint també ha de servir per a algunes accions necessàries que afecten la qualitat i l’estabilitat del Product Backlog:

  1. Preparar feina que s’haurà de construir en un futur imminent (al següent Sprint o d’aquí dos sprints)
  2. Recollir noves necessitats que transmet l’usuari, o bé tractar canvis que impacten sobre el negoci mentre estem construint el producte i, de retruc, afecten sobre els objectius del mateix producte, i la nostra feina.

Aquestes accions es duen a terme de forma natural en el mateix temps i espai (el Sprint) en què estem construint l’increment compromès. Pel que fa al 1r punt, acostumen a ser reunions planificades en agenda. L’equip tècnic es reuneix de forma periòdica per entendre completament històries d’usuari que haurà de construir en un futur imminent, amb l’ajuda del Product Owner i dels Stakeholders.

Aquest “entendre” comporta, necessàriament, baixar el detall de la necessitat plantejada pel negoci, i complementar-la amb tota la informació que sigui necessària perquè l’equip pugui assolir un coneixement complet d’aquesta. Això comporta, forçosament, la definició dels criteris d’acceptació. Aquests criteris són responsabilitat del negoci, i tracten d’explicar quines premisses, condicions i comprovacions es duran a terme per poder donar per vàlida una història d’usuari concreta o un increment en el seu conjunt.

Pel que fa al 2n punt, recollir noves necessitats o tractar canvis que es produeixen en el negoci, són un exemple d’adaptació contínua amb agilitat. El canvi és benvingut en el projecte, i es transforma en més feina al backlog. El canvi no pot ser un element distorsionador de la feina dels tècnics i, per tant, el canvi no pot afectar els objectius a curt en què l’equip s’ha compromès, ni afectar la seva autoorganització.

Tot això té impactes sobre el Product Backlog*. I és responsabilitat de tothom, inclosos els membres de l’equip tècnic, mantenir actualitzats els ítems del product backlog amb tota aquesta informació nova o canvis que es negocien en aquestes reunions de Refinement.



Fer estimació

Una història d’usuari qualsevol no pot construir-se si, entre altres informacions, no tenim un coneixement sobre l’esforç que comporta fer-la realitat. Per això és imprescindible que l’equip tècnic les treballi en el que es coneix com a Refinements d’estimació. Quan l’equip té un coneixement complet de la necessitat a construir, producte de reunions de Refinement per avançar feina que hem vist al punt anterior, està llest per a fer una valoració o estimació de l’esforç que comporta fer-la realitat.


Usualment, l’equip es reuneix de forma periòdica per fer estimacions de diverses històries d’usuari. Existeixen diverses dinàmiques per poder fer aquesta acció de la forma més eficient possible, i les expliquem en un altre article. Aquí només farem èmfasi sobre la necessitat de fer aquest exercici de forma constant durant els Sprints, per tal que, en arribar el Sprint següent, l’equip disposi de tota la informació necessària per poder construir les històries més interessants a cada moment.



La durada dels Refinements

A diferència de la resta de reunions del marc de treball Scrum, no existeix un TimeBox clarament establert per a les reunions de Refinement. En ser reunions que es duen a terme de forma variable durant els Sprints, no hi ha una recomanació estàndard sobre quantes s’haurien de fer. Únicament tenim les recomanacions següents:

  • Una reunió de Refinement, si és possible, no hauria d’excedir una hora de durada. Existeixen estudis que demostren que, passada la 1a hora de reunió, l’atenció pot disminuir de forma notòria. Si vols mantenir l’atenció es millor fer reunions curtes, o bé descansos per a poder recuperar l’atenció.
  • En un Sprint no haurien d’haver-hi reunions per un temps global superior a un 5% o 10% de la durada del Sprint. Això vol dir que, en Sprints de 15 dies i 8 hores de jornada, no hauríem de tenir reunions de Refinement per més de 8 hores. El motiu d’això és que, si superem aquest límit, podríem estar afectant el normal funcionament del sprint i la capacitat de l’equip per poder assolir les fites compromeses.

Alguns consells per organitzar una reunió de Refinement



Alguns antipatrons típics en la Refinement

Tot completament detallat i estimat INVEST Ítems basats en components
Tots els ítems del product backlog estan detallats i estimats. L’equip ha de treballar únicament sobre allò que es durà a terme en terminis de temps raonables Els ítems del product backlog han de ser INVEST (Independent, Negotiable, Valuable, Estimable, Sized appropriately & Testeable) Un ítem del product backlog ha de descriure una necessitat “end-to-end”. I no una solució assignable a una vertical tecnològica

Sense criteris d’acceptació No es fan refinements Dedicació del Product Owner
Un ítem del product backlog no només ha de descriure una necessitat. També ha de donar orientacions sobre com aquesta serà validada La comprensió del product backlog s’obté només gràcies als refinements. L’equip dialoga amb el PO sobre el ítems més prioritaris Un product backlog amb baixa dedicació del PO comporta una mala comprensió de la necessitat, errors d’estimació i baixa qualitat en els resultats



Descarrega l’esquema de la reunió de Refinement



Descarrega l’esquema per imprimir aquí