Ventuno punti e una data contrattuale

Narratore: Le voci di questo episodio sono sintetiche. È martedì mattina, refinement di sprint. Il Product Owner porta una nuova feature richiesta da un cliente importante. La richiesta è di stimarla in story points, come da processo. Per ora, il processo è rispettato.

Product Owner: Il cliente la considera importante e vorrebbe capire quando sarà disponibile. Prima però facciamo la stima: solo la feature, senza trasformare il refinement in una discussione sulla data. Ci serve un numero in punti, così poi possiamo pianificare.

Junior Developer: Prima di dare il numero, possiamo capire che cosa include? Se l’integrazione col legacy ha parti che non conosciamo, forse il punto non è solo quanto è grande, ma quanto resta da scoprire.

Product Owner: Sì, ma se allarghiamo la discussione dobbiamo comunque uscire con una stima. Annotiamo l’incertezza, almeno; così non sembra che il numero dica più di quello che sappiamo.

Junior Developer: Io direi venticinque punti. Non è mai stato fatto prima e c’è l’integrazione col legacy. Non so ancora quale parte ci farà perdere più tempo, ma proprio per questo non mi sembra prudente trattarla come una modifica piccola.

Senior Developer: Ventiquattro, venticinque. Con il legacy vero sono il doppio. Ma i punti non sono ore. Sono punti. Se li usiamo per misurare l’incertezza, almeno non fingiamo che descrivano già il calendario.

Junior Developer: Quindi venticinque punti descrivono quanto è grande o incerta la feature, non quante settimane servono. È questo che dovremmo comunicare? Perché se è così, finora ho capito la regola.

Product Owner: Sì, i punti non sono una data. Però il Commerciale mi ha appena scritto: il cliente vuole una data, non un numero astratto. Ho una call con lui e devo dargli qualcosa di utile. Possiamo convertire i punti in settimane, almeno per questa volta?

Narratore: Entra il Commerciale. Non è entrato nel tecnico. La data, però, è già entrata nella conversazione.

Commerciale: Esatto, non sono entrato nel tecnico. Ho trovato una tabella di conversione su internet: ventuno punti corrispondono a sei settimane. Ho detto al cliente cinque, per non partire già con un margine che sembrasse eccessivo. Possiamo verificare se la tabella è compatibile con la vostra stima?

Junior Developer: Quella tabella tiene conto anche del lavoro col legacy? Perché è proprio lì che abbiamo detto che la stima può raddoppiare.

Senior Developer: La tabella dà settimane per punti. Non dice quali informazioni servono per passare dagli uni alle altre. Il legacy non ha letto la tabella.

Product Owner: Aspetta: il cliente ha già sentito cinque settimane. Noi abbiamo appena detto venticinque punti. Quindi la domanda non è più soltanto quanto è grande la feature: devo capire se quella data è sostenibile e cosa sto portando alla call.

Senior Developer: La stima era venticinque, non ventuno. Qualcuno ha arrotondato per farla entrare nella tabella. È un modo curioso di stimare: prima si decide quanto deve venire, poi si cerca il numero giusto.

Junior Developer: Chi ha autorizzato l’arrotondamento? E dove risulta? Perché se la stima è venticinque, cambiare il numero per usarne un altro non mi sembra una conversione. Sembra una stima diversa, fatta senza il team.

Commerciale: Non so chi abbia fatto l’arrotondamento. La tabella è quella ufficiale, perché è nella cartella condivisa. Io ho preso il numero che c’era. Non volevo cambiare la stima del team, volevo rispondere alla domanda del cliente.

Junior Developer: Quindi è ufficiale perché è condivisa, non perché il team l’ha verificata? Dove si vede che quei numeri valgono per questa feature?

Commerciale: Non ho una verifica per questa feature. Avevo un numero da portare alla call e una tabella che sembrava utilizzabile. Pensavo che fosse un punto di partenza, non una decisione definitiva.

Senior Developer: Capisco. La tabella risponde in modo molto preciso a una domanda che non ha le informazioni necessarie per rispondere. E ora abbiamo una data contrattuale costruita su ventuno punti, mentre la stima del team è venticinque.

Junior Developer: Quindi i punti non sono ore, non sono settimane e non sono una data. Però possono diventare settimane se qualcuno li mette nella tabella, e una data se il cliente l’ha già sentita. Ho capito bene il passaggio?

Narratore: Tre settimane dopo, la feature è a metà. La data contrattuale è scaduta. Il team è convocato in una riunione per capire perché le stime in punti non corrispondano al tempo.

Senior Developer: Per capire dov’è il lavoro, guardiamo cosa manca. Per capire perché la data è scaduta, bisogna guardare anche a come è stata fissata.

Product Owner: Sono due domande diverse, ma nella convocazione sono finite sotto lo stesso titolo. Provo a separarle prima che la risposta diventi un’altra tabella.

Junior Developer: La feature è a metà e la data è passata. Ma avevamo detto che i punti non erano tempo. Stiamo cercando di capire perché la stima in punti non corrisponda al tempo: forse il problema è che abbiamo usato i punti proprio per promettere una data.

Senior Developer: La stima non era una promessa. Poi è diventata ventuno punti, poi sei settimane sulla tabella, poi cinque al cliente. Il legacy è ancora lì. Anche la tabella. Il problema è che ognuno ha fatto un passaggio ragionevole, preso da solo.

Product Owner: E adesso dobbiamo spiegare la differenza tra stima e promessa, mentre rispondiamo della data. Per la prossima volta dovremo chiarire cosa possiamo dire al cliente e cosa invece resta una misura utile al team.

Junior Developer: Va bene. Solo una domanda: nella prossima riunione per capire perché la data non corrisponde alla stima, useremo i punti o le settimane? Così almeno sappiamo quale numero non dobbiamo convertire.