La Sprint Planning és una reunió on l’Scrum Team té l’oportunitat d’organitzar de la forma més eficient possible la feina per al Sprint. Probablement, tothom és conscient que, al iniciar-se cada Sprint en el nostre projecte amb Scrum, és necessària la realització d’una reunió amb negoci, en la qual decidirem que farem en aquell petit període de temps.

És possible que alguns membres del teu equip no sàpiguen que aquesta acció de planificació es troba circumscrita únicament i exclusivament sobre “el com”. Pel que fa a les característiques de la necessitat, la seva composició, el seu impacte, la seva interrelació amb altres necessitats i, sobretot, la comprensió completa d’aquesta per part de l’equip tècnic, és una tasca a la qual ja arribem preparats al Sprint Planning.

Dit d’una altra manera: El Sprint Planning no serveix per agafar consciència i coneixement sobre les necessitats a construir. I ha de servir només perquè l’equip tècnic tingui un espai per debatre les complexitats de la construcció (debatre “el com” de les necessitats finalment escollides).

Per tant, ha d’haver-hi un altre període de temps per la comprensió i l’anàlisi de la necessitat. I això en Scrum es duu a terme en l’àmbit d’una altra reunió que expliquem en un altre article: El Refinement.

Aclarit aquest incís. Els tècnics arriben a la reunió amb plena comprensió d’allò més crític que, probablement, escollirem en aquesta reunió per la seva construcció. I dic probablement perque, quan treballes en agilitat, no tens una planificació fèrria i, per tant, tot està sotmès a certa negociació i consens. I el Sprint Planning és un exemple d’aquesta capacitat de negociació entre totes les parts interessades.

El Sprint Goal

La reunió comença amb una primera pregunta que cal respondre: Quin és l’objectiu d’aquest Sprint? Això es coneix com a la definició del Sprint Goal, El protagonista per donar resposta a aquesta pregunta, i alhora, assegurar-ne la comprensió de la finalitat per part de l’equip tècnic, és el Product Owner. Ell és el responsable de la priorització del Product Backlog i, per tant, ha d’haver rumiat quins ítems d’aquest són més prioritaris per al negoci en aquest moment.

Però aquí mai s’ha tractat que l’equip construeixi funcionalitats sense context. És precisament aquest interès per mantenir el context d’allò que es fa, el que fa tan recomanable que el Product Owner i els tècnics consensuïn un Sprint Goal. Mantenir el context proporciona una sèrie de beneficis que tots nosaltres hauríem sempre de tenir al nostre punt de mira:

• Motivació dels tècnics: El fet que els tècnics no només se centrin a adquirir el compromís per a fer una sèrie de tasques previstes; sinó que participin en la visió global del valor que proporciona a l’organització, té efectes directes sobre la motivació i la participació d’aquests en la consecució d’un objectiu comú. Una meta.
• El MVP: L’èxit d’un Sprint no rau en la consecució d’una sèrie de fites previstes; sinó en l’assoliment d’un increment de valor per a l’organització. Aquest valor s’explica, no per les característiques particulars de cada una de les peces individuals de l’increment, si no per la resolució d’una necessitat del negoci. Encara que aquesta sigui petita.
• La qualitat: El fet de “planificar” una millora que assoleix un objectiu preestablert, facilita la feina dels stakeholders a l’hora de verificar si aquest objectiu l’hem assolit o no. Ja que la validació, mitjançant els criteris d’acceptació, no s’ha d’enfocar com la validació de cert nombre de peces tecnològiques obtingudes, sinó com el test d’un o diversos escenaris de negoci que donen fe d’aquest objectiu.

Aquesta definició de la meta del Sprint (Sprint Goal) ha de ser una acció que no ocupi més d’uns pocs minuts en la reunió de Sprint Planning.

Recollir la funcionalitat

Un cop definit l’objectiu del Sprint, la tria de les necessitats a construir hauria de ser una qüestió més senzilla. Ja que la tria es farà en funció de què cada ítem dona o no resposta a la meta del Sprint. Si el Product Owner ha rumiat bé la seva priorització, generalment no hi ha dificultats en la selecció d’aquestes necessitats. Però tornem-ho a dir: Això és agilitat. L’agilitat ha de portar sempre la capacitat de debat i consens de forma no traumàtica. És perfectament possible que l’equip i el Product Owner acabin consensuant un conjunt de necessitats per aquell Sprint que no sigui al 100% el que el Product Owner podia imaginar-se un temps enrere. Hi ha tota classe de motius i beneficis per aquesta negociació:

• Ítems una mica menys prioritaris que acompleixen millor amb el Sprint Goal establert
• Conveniència tècnica o dependències que fan aconsellable la tria d’un ítem del Product Backlog en relació amb un altre
• Interessos del negoci en funció de la conversa i el debat al moment de definir el Sprint Goal, que han fet que el Product Owner veiés més factible la tria d’un ítem de prioritat menor.

Tot és possible. L’única premissa és que sigui el producte d’un diàleg en l’equip.

Assegurar els criteris d’acceptació

Els criteris d’acceptació són tot allò que ens permetrà demostrar a la Sprint Review, que hem assolit l’objectiu establert per aquest Sprint. Per tant, és una informació cabdal per a l’equip. L’equip s’ha de preocupar que aquesta informació sigui part de la definició de les necessitats que hem triat construir. Fins al punt que, si una necessitat no té la definició sobre els criteris d’acceptació, no es troba en un punt que permeti que l’equip la pugui construir i, per tant, no podrà formar part de la selecció compromesa per aquest Sprint. Això, que rep el nom de Definition of Ready (DoR) ho expliquem en un altre article.

Els criteris d’acceptació, en ser l’eina que permet als Stakeholders verificar i validar la correcta comprensió i utilitat d’allò que l’equip tècnic ha construït; és responsabilitat dels Stakeholders la definició (o redacció, o preparació) d’aquests criteris d’acceptació. Això és el que diferencia la cooperació dels usuaris en un projecte àgil respecte a un projecte tradicional. El negoci es responsabilitza no només de “dir el que vol” si no d’assegurar l’entesa de l’equip tècnic sobre com ho verificarà i validarà.

Al Sprint Planning, doncs, és el lloc on el Scrum Team comprova l’existència i coherència d’aquests criteris d’acceptació. Hem d’entendre els criteris d’acceptació des de diversos nivells d’actuació. Hi ha criteris d’acceptació a nivell necessitat. Però també han d’existir criteris d’acceptació a nivell lliurement. A més, és especialment important que tota aquesta tasca de verificació tingui sempre present l’existència i integració amb totes les porcions de producte lliurades amb anterioritat.

Organitzar la feina

Un cop establert el compromís sobre quin increment de valor durem a terme durant l’Sprint. I un cop assegurada i entesa la forma com aquest increment serà verificat i validat per part dels Stakeholders; l’equip tècnic agafa el protagonisme de la reunió. El Product Owner pot continuar o no, en funció dels dubtes que hi puguin haver, i si l’equip tècnic ho creu necessari.

Aquest espai de temps a la reunió permet a l’equip tècnic organitzar la feina que haurà d’executar durant el Sprint. Scrum no diu res sobre com s’ha de procedir en aquesta organització. I tot i que actualment és molt habitual que els equips desgranin la necessitat en tasques tècniques que caldrà executar; no té per què ser l’única estratègia possible.

Cal dir, però, que aquesta acció de definició de les tasques tècniques d’una història d’usuari donada, no és una tasca que l’equip duu a terme “en fred” al Sprint Planning. Ja que l’equip ja ha treballat anteriorment l’entesa d’aquella història d’usuari amb els Stakeholders. I ja ha treballat una estimació en esforç per tal d’arribar al Sprint Planning amb una entesa completa i, en aquesta estimació, de ben segur han aparegut tasques, accions o estratègies de construcció. Ara, al Sprint Planning, l’equip fa ferma una estratègia concreta de construcció amb la definició de les tasques tècniques necessàries.

El volum de feina. L’estimació de les històries en el Product Backlog. La Team Velocity

Aquesta és la qüestió que tant preocupa als Projects Managers tradicionals. Quanta feina es compromet a fer l’equip en un Sprint? Aquí penso que és important aclarir dos aspectes que són essencials en agilitat:

1. En agilitat no ens preocupa gens el volum en cru. Si no l’assoliment d’un increment de valor per a l’organització en un petit període de temps.
2. En agilitat tenim interès perquè l’equip tècnic tingui una consciència exacta sobre l’esforç que comporta fer realitat cada una de les necessitats incorporades al Product Backlog. I mai el timming. El timming és una obsessió en la gestió tradicional de projectes. En agilitat l’obsessió és el valor. Per tant, mai preguntarem a un tècnic ni a l’equip quant es triga a resoldre una necessitat concreta. Però si preguntarem quin esforç comporta fer-la realitat.

Un cop tenim clara la variable d’esforç sobre les necessitats. Podem preguntar als tècnics quin és el timming per a construir cada una de les tasques tècniques que hem planificat. Això té diversos beneficis, com són:

• Per conèixer la dimensió d’una tasca tècnica. I saber si aquesta és prou atòmica per poder ser construïda sense risc. Ha d’existir un equilibri pel que fa al timming d’una tasca tècnica. Tant negatiu és tenir tasques de minuts o poques hores de durada, com tasques de moltes jornades. L’ideal en projectes Scrum és que les tasques tinguin una durada equivalent a una o dues jornades de treball.
• En relació amb el punt anterior, quan un tècnic escull una tasca tècnica, gràcies a aquesta estimació té una idea clara sobre el volum de treball que caldrà abastir. I llavors podrà triar més tasques per cobrir la jornada de treball.
• També serveix per tenir consciència del que significa tenir una història d’usuari estimada en cert nombre d’story points (esforç); i les tasques tècniques que proporcionen un timming a nivell atòmic. S’ha de dir en aquest punt però, que creure que la suma de totes les tasques tècniques proporcionen el cost en timming d’una història d’usuari, en la meva opinió és una il·lusió.
• Valorar tasques tècniques en timming pot donar KPIs i informació volumètrica al Scrum Master per poder fer un seguiment de l’assoliment de l’equip tècnic.
• Per últim, estimar les tasques tècniques en timming dona perspectiva i experiència a l’equip tècnic per tal que, en següents Sprints, s’afini tant l’estimació en esforç de les històries d’usuari com l’estimació fina en hores de les tasques tècniques. Un equip que no adquireix l’hàbit de fer estimacions sempre cometrà errors a l’hora de comprometre’s amb volums de feina.

Amb això últim podem relacionar el concepte de Team Velocity. La Team Velocity és el volum en Story Points que l’equip és capaç de comprometre’s a fer realitat a cada Sprint. A això només s’arriba mitjançant la pràctica, el coneixement de les capacitats de l’equip, l’experiència dels Sprint anteriors, i la comprensió que l’equip arriba a assolir sobre els conceptes d’esforç en històries d’usuari, i timming en tasques tècniques.

La Team Velocity és l’eina que permet als equips àgils encertar amb volums de feina en els Sprint Plannings. Sense discusions i en base a valors històrics justificables.

El Scrum Master ha de tenir especial interès a disposar d’aquesta informació. Ja que la Team Velocity, les estimacions en Story Points i els timmings donen informació de valor per conèixer l’assoliment de l’equip tècnic. Però també donarà orientacions molt acurades sobre la complexitat del projecte i la seva durada global en funció del contingut del Product Backlog. Això dona respostes amb una base ferma a la qüestió que sempre preocupa als managers: Calendari i cost global del projecte. I podem conèixer això sense planificacions i sense pressionar a tècnics a donar timmings sobre necessitats. És a dir, sense traumes.

Alguns consells per organitzar una Sprint Planning

Alguns antipatrons típics a la Sprint Planning

Descarrega l’esquema de la reunió de Sprint Planning

Descarrega l’esquema per imprimir aquí