Sovint el nombre de necessitats que impacten en un producte és molt elevat. Sabem que el Product Owner per un producte donat ha de ser una única persona, per tal d’evitar conflictes i confusions sobre el procés d’ideació del mateix producte i sobre els equips que treballen per a fer-lo realitat.
Però que el Product Owner hagi de ser una única persona clarament identificable no significa que aquesta persona estigui sola davant de la complexitat del producte. Totes les persones impactades o interessades en el producte (els Stakeholders) col·laboren en la identificació, justificació i priorització de les característiques del producte.
En aquest sentit, presentem aquí una activitat molt interessant que ajuda al Product Owner a dur a terme una primera priorització d’un gran nombre de necessitats. La matriu Eisenhower.
La priorització de necessitats aplica en reunions específiques que serveixen per a aquest objectiu. Poden estar dins o fora del procés d’execució del producte. Poden dur-se a terme abans d’iniciar els projectes de construcció del producte; o un cop aquests s’han posat en marxa. Per tant, podem englobar-ho en la categoria de les reunions de Refinement contemplades pel marc de treball Scrum.
L’eina que utilitzarem en aquesta activitat és la Matriu Eisenhower. Consisteix en un tauler que es divideix en quatre àrees. Cada una d’aquestes àrees dona una indicació sobre la importància i la urgència de dur a terme una característica o necessitat concreta del producte. Així, tenim el tauler següent:
De forma general, poden establir-se, sense por d’equivocar-nos que una tasca amb poca urgència i poca importància tindrà una prioritat baixa en el Product Backlog del nostre producte. Així mateix, una necessitat catalogada com a important i urgent tindrà una priorització alta.
La resta d’opcions però (importància alta però poc urgent, o urgència alta però poc important) poden ser objecte de debat entre els participants de l’activitat, que hauran de considerar quina agrupació és més prioritària.
Com sempre, la recomanació que faig per aquestes activitats és de no superar 1 hora de durada. Explicar les necessitats individualment per assegurar-nos que els participants l’entenen d’una forma alineada requereix molt de temps. Hem d’assegurar-nos de triar un nombre d’activitats que no superi el temps de la reunió. Probablement, és preferible fer diverses reunions d’una durada acceptable, que garanteixi la correcta atenció de tothom, que una única reunió maratoniana que ens deixi amb el dubte si la classificació obtinguda és realment la correcta.
A la sessió hem d’arribar preparats. El Product Owner ja disposa de les targetes amb la descripció de cada una de les característiques o necessitats que vol prioritzar. A banda, és recomanable tenir accés al Product Backlog per si cal aclarir algun dubte referent a alguna altra necessitat present en aquest registre.
Alhora, els assistents han tingut accés prèviament a la sessió a aquesta informació, de forma que puguem centrar-nos el màxim possible en l’explicació d’una necessitat sense haver de perdre massa temps en posar en context als participants.
A l’inici de la sessió, el Product Owner explica les regles de treball i presenta la matriu. Si és necessari, pot establir un debat amb els participants sobre la priorització que han de tenir les necessitats que se situïn a les àrees de poca importància i molta urgència, i molta importància i poca urgència.
A partir d’aquí, l’organització de la reunió és força lliure, i depèn molt de la complexitat de les necessitats a explicar i de l’habilitat dels participants per a prendre decisions. Una aproximació conservadora seria que el Product Owner (o la persona amb més coneixement sobre una de les necessitats) explica una necessitat als assistents i demana una decisió al grup per tal d’ubicar-la a l’àrea adequada del quadrant. Un cop fet això, passaria a la següent necessitat fins a enllestir totes les necessitats previstes a la sessió.
Una altra aproximació més dinàmica és situar les targetes de les necessitats sobre la taula i demanar als assistents que ells mateixos triïn alguna d’aquestes targetes i la situïn en la matriu. Posteriorment, cal que justifiquin a la resta d’assistents els motius principals perquè l’han situat en aquella àrea de la matriu, podent establir un debat per arribar a un consens, i canviant de posició les targetes si és necessari. Si el nombre d’assistents és prou elevat, podem demanar la creació de grups de treball que es responsabilitzin de cert nombre de targetes.
El Product Owner, que és qui modera la sessió, ha d’estar disponible per resoldre dubtes sobre l’abast o les característiques de les necessitats objecte de priorització. I vigila que el grup s’enfoca a arribar a un consens sincer sobre cada una de les necessitats.
És molt convenient explicar a l’inici de la sessió que l’objectiu no és arribar a un consens sobre “l’esforç” necessari per a fer realitat les necessitats (això ho farà l’equip tècnic més endavant). La finalitat d’aquesta sessió és únicament la prioritat. No confonguem “fàcil/difícil” amb “important/urgent”
Cómo usar la matriz de Eisenhower para priorizar tareas? (video tutorial) Trello.com (https://blog.trello.com/es/matriz-eisenhower)
Introducing the Eisenhower Matrix Eisenhower.me (https://www.eisenhower.me/eisenhower-matrix/)
Descarrega el document (cat)