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.
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.
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:
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.
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.
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:
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 per imprimir aquí