Un dels pilars de la teoria de control de processos empírics (empirisme) en què Scrum basa el seu secret de l’èxit, és la Inspecció. La Sprint Review dona espai i eines a l’equip i als interessats per a fer inspecció de forma contínua; i avançar en el projecte de la forma més constructiva i eficient possible.
Podríem entendre la Review com l’oportunitat de l’equip per a comprovar el nord. Al final de cada Sprint l’equip proporciona l’increment assolit i el mostra a la reunió de Sprint Retrospective. El Product Owner i els Stakeholders són protagonistes en aquesta reunió. Ja que el 1r lidera la reunió. I els segons lideren la inspecció i acceptació.
Aquest increment que se sotmet a inspecció ha d’estar en situació de poder ser inspeccionat pels stakeholders. Això significa diverses coses importants:
La Meta del Sprint (Sprint Goal) és un enunciat consensuat amb l’equip, i definit com la 1a acció en el Sprint Planning, que explica de forma comprensible quin objectiu de valor cerca assolir l’increment que ara lliurem. La Sprint Review ha de servir per a comprovar que, efectivament, l’increment dona compliment a aquella intenció descrita al Sprint Goal.
Els Stakeholders més rellevants i impactats per l’increment que lliurem han d’estar presents a la Review. Fer lliuraments únicament al Product Owner no és una bona pràctica. Els Stakeholders, a la reunió de Review, generaran una sinergia de feedback que té molt valor per a l’equip.
El producte ha d’acomplir el Definition of Done (DoD). Es a dir, estar acabat tal com ho entén l’organització. El DoD ho expliquem en un altre article, però el més important és entendre que, acabat, no significa simplement construït. Ha d’acomplir tot allò que sigui necessari per a poder explotar aquest increment de forma immediata. I això inclou aspectes molt rellevants com la documentació, el testing, la integració, la informació per al manteniment, etc.
L’increment de producte a mostrar no pot bassar-se en una activitat de DEMO. Els Stakeholders han de poder tocar l’increment i practicar-lo en un entorn realista. Només així es pot crear un escenari d’acceptació en què veritablement es posa a prova el producte.
La forma de posar a prova l’increment és mitjançant els criteris d’acceptació. Els criteris d’acceptació per aquest lliurament, van ser definits a l’inici del Sprint, al Sprint Planning. Els Stakeholders i el Product Owner són els responsables, tant de la definició inicial dels criteris d’acceptació, com després posar en pràctica aquests criteris per tal de sotmetre a prova l’increment que lliurem a la Review.
Una execució satisfactòria d’aquests criteris d’acceptació són un argument de molt de pes, per poder tenir la confiança que l’equip necessita en què els stakeholders validen l’increment amb fonaments ferms.
La pràctica ens diu que, tan important com que els Stakeholders ens acceptin (o no) l’increment, és que aquests ens donin informacions de primera mà que ens empoderin de cara a la cerca constant de la millora. Especialment important és el feedback quan l’increment no pot ser acceptat pels Stakeholders. Però encara que ens ho acceptin, el feedback segueix sent una finalitat primària. De vegades una acceptació no sempre és sinònim d’una conformitat al 100%.
Hem de demanar aquest feedback i crear l’ambient idoni a la reunió per a què aquest feedback sorgeixi de forma natural.
Podem veure la Sprint Review com dues reunions en una. Una 1a part, de molt curta durada, on l’equip empodera el Product Owner per a què aquest sigui capaç de liderar la 2a part de la reunió. En aquesta 1a part expliquem al Product Owner la situació final del Sprint, i els petits detalls que puguin ser interessants per al Product Owner.
Aquesta part mai ha de tenir l’objectiu d’explicar al Product Owner un gran problema en el Sprint. En general, els problemes que apareixen durant el Sprint es tracten de forma immediata, amb les persones que han d’estar informades i les que ens han d’ajudar a resoldre el problema en qüestió. No podem esperar a una Review per explicar un problema al Product Owner. Si estem en aquesta situació hem d’encetar una dinàmica de Retrospectiva per trobar millores pel que fa a la comunicació.
La Transparència, un altre dels pilars de la teoria de control de processos empírics, seria l’aspecte que també té cabuda en la Sprint Review.
| El PO egoista | El PO es l’únic acceptador | Mort per PowerPoint |
|---|---|---|
| El PO presenta els èxits i el valor com a seu. Els èxits i els fracassos són sempre de l’equip | El PO accepta en nom dels stakeholders. No s’afavoreix el contacte amb els stakeholders ni el seu feedback. L’acceptació del PO no es produeix sempre pel valor obtingut i l’acompliment del DoD | A la Sprint Review es fan servir presentacions, i no el producte |
| Sempre les mateixes cares | No s’informa al PO | Què és el DoD? |
|---|---|---|
| No hi ha varietat entre els interessats del producte. Sempre es presenten a la Review els mateixos, tot i que no sempre els impacta a ells el valor obtingut | Els developers realitzen accions no previstes i/o no obtenen els resultats previstos. I li comuniquen al PO a la Review | Els tècnics no coneixen o no acaten el DoD establert, i presenten com a Done resultats que no ho estan |
| Sprint Review Planning | Sprint Review de tasques | |
|---|---|---|
| Es fa servir la Sprint Review més per a planificar treball que per a presentar resultats i obtenir feedback i acceptació | Es fa servir la Sprint Review per a un repàs de l’exercici al detall de cada tasca tècnica, oblidant que allò rellevant és el valor obtingut i la seva utilitat per al negoci |
Descarrega l’esquema per imprimir aquí
