Utilizzo di fogli di calcolo agili per la stima della scoperta

Questo articolo include un foglio di calcolo preformattato per aiutarti a sviluppare stime di scoperta Agile. Include anche informazioni per aiutarti a seguire l'esempio in primo piano. Puoi fare una copia modificabile (File>Crea una copia o File>Scarica) dal modello qui.

I clienti spesso mi chiedono di fornire stime Agile prima di avere un team in loco o conoscere i requisiti MVP. In questa fase iniziale, non ho accesso alle metriche tradizionali come velocità, numero di sprint o costo del team per calcolare tali stime. Ma i clienti vogliono risposte. Possono lanciare un prodotto ipotetico in due mesi o sei? Sarà fattibile per il loro budget (solitamente basso)?

Accedi al foglio di calcolo Agile.

I fogli di calcolo sono una scelta adatta, ma spesso trascurata, per una mentalità agile. Sono strumenti a bassa tecnologia e high-touch che incoraggiano la collaborazione. Detto questo, al tuo cliente probabilmente non importa se i tuoi strumenti sono "approvati Agile" purché il costo e la qualità del prodotto soddisfino i loro requisiti. Il vero valore dei fogli di calcolo risiede nella loro accessibilità ai project manager e agli stakeholder di tutti i livelli di esperienza.

Molti strumenti specializzati di gestione dei progetti hanno curve di apprendimento troppo ripide per utenti inesperti su progetti in rapido movimento. Quindi, più è facile per clienti, proprietari di prodotti e sviluppatori aggiornare i requisiti e i costi di manodopera, prima arriverai a una stima realistica. Con un foglio di calcolo preformattato, i project manager possono regolare valori e parametri per dimostrare gli effetti di ciascuna risorsa fluttuante o della sequenza temporale mutevole.

I fogli di calcolo sono anche un ottimo modo per condividere le conoscenze con i tuoi colleghi. Il foglio di calcolo che uso è nato con un collega di Toptal e da allora ne ho fatto una copia e l'ho modificato in base alle mie esigenze. Ti incoraggio a farlo anche tu.

In questo articolo, mostro come fornire stime di scoperta di successo che consentano ai clienti e alle parti interessate di allinearsi agli obiettivi del progetto e procedere con lo sviluppo. Ecco come riempire gli spazi vuoti e fornire un preventivo in fase iniziale che puoi sostenere.

Affronta prima la visione del prodotto e la tabella di marcia

Supponiamo che il tuo cliente voglia sviluppare un sito di incontri con un budget fisso, ma i dettagli del prodotto sono confusi. Senza conoscere il costo e la velocità del team, la visione del prodotto è il punto di partenza migliore perché richiede alle parti interessate di concordare un obiettivo di progettazione e promuove la trasparenza all'interno del team.

Mi piace il formato di visione del prodotto Scrum.org per il suo stile narrativo intuitivo. Ecco come appare:

Una volta impostata la visione del prodotto, puoi aggiungere la Roadmap del prodotto in una nuova scheda del foglio di calcolo per dare al cliente un'idea della pianificazione del progetto a lungo termine. La roadmap dovrebbe elencare obiettivi, caratteristiche chiave e scadenze per ciascuna versione della roadmap del prodotto.

Le versioni della roadmap sono edizioni pianificate, rivolte al consumatore o al cliente, di un prodotto che ne guidano la traiettoria di mercato. La prima versione della roadmap è il prodotto che puoi debuttare sul mercato. Le successive versioni della roadmap rappresentano le versioni sul mercato con nuove interessanti funzionalità che si allineano alla visione del prodotto.

Per usare Microsoft come esempio: Windows 8 era probabilmente una versione della roadmap. Windows 10 era un'altra versione della roadmap che presentava molte funzionalità nuove e desiderabili.

Una volta completate la visione del prodotto e la roadmap, è il momento di chiedere al cliente di impegnarsi in un MVP.

Negozia le caratteristiche MVP con il grafico a triplo vincolo

Questo è il momento di modellare le aspettative del tuo cliente in termini di tempo e spese utilizzando il grafico del triplo vincolo:

In un approccio Waterfall, le caratteristiche fisse determinano tempi e costi e lo sviluppo procede secondo un piano di progetto dettagliato. Al contrario, i costi fissi e la pianificazione di Agile determinano le caratteristiche del prodotto e queste caratteristiche vengono costantemente riassegnate in base alla visione più flessibile del progetto.

Il grafico del triplo vincolo mostra al cliente che l'inclusione di tutte le funzionalità desiderate nella prima versione aumenterà i tempi di sviluppo e i costi del fumetto. Invece, collabora con il client per selezionare solo le funzionalità "indispensabili" per un MVP e elenca le funzionalità rimanenti per le versioni future.

I fogli di calcolo semplificano il raggruppamento e la riassegnazione delle funzionalità a versioni, versioni e priorità diverse in base alle mutevoli esigenze del cliente e visualizzano istantaneamente i costi di queste modifiche.

Mentre stai identificando le caratteristiche di MVP, chiedi aiuto ai tuoi esperti in materia (PMI) per elencare i passaggi del progetto in base a progetti simili su cui hanno lavorato. Utilizzerai questi passaggi per creare epopee in seguito. Una volta che hai quegli input pronti, puoi iniziare a costruire un preventivo.

Inizia con la taglia della maglietta

Per iniziare il primo backlog, chiedi al proprietario del prodotto una descrizione dettagliata delle caratteristiche del prodotto, quindi assegna una taglia di maglietta a ciascuna caratteristica in base al suo livello di difficoltà.

La taglia della maglietta mostrerà la complessità relativa e la durata di ogni attività di sviluppo prima di avere valori assoluti. Man mano che avanziamo nella pianificazione del progetto, convertiremo queste dimensioni relative in punti della storia e ore di lavoro.

Ad esempio, se il tuo cliente vuole che sviluppi una serie di pop-up sul sito di incontri, ciò richiederebbe molto tempo ma sarebbe semplice. Potresti caratterizzare la complessità del compito come un "Piccolo", ma lo sforzo sarebbe un "Medio". Potresti abbreviarlo come "SM". D'altra parte, lo sviluppo di una connessione back-end per una nuova API sarebbe un compito più complesso a causa di tutta la documentazione e i test richiesti. L'abilità e l'attenzione necessarie per questo potrebbero renderlo un "Grande" sia per lo sforzo che per il livello di abilità: "LL".

Una volta terminato il dimensionamento della maglietta, avrai un'idea del relativo carico di lavoro e dei requisiti di abilità per ogni futuro membro del team. Un esperto tecnico del team di sviluppo può quindi aiutarti a correlare la taglia della tua maglietta a intervalli di ore e punti della storia.

Imposta i tuoi parametri

Ora sei pronto per mettere in funzione il tuo foglio di calcolo e calcolare la tua stima. Inizia creando una scheda Parametri. Questo servirà come chiave per i tuoi calcoli e i valori che inserisci qui alimenteranno le formule utilizzate nelle schede Backlog/Storie utente e Riepilogo stime per rilascio.

Ecco tutto ciò di cui avrai bisogno nella scheda Parametri:

Moneta. Qui è dove inserisci le conversioni di valuta. Ad esempio, se il budget del cliente è in real brasiliani, puoi inserire il tasso di conversione corrente per dollari o euro.

Data d'inizio. La data di inizio dello sviluppo prevista verrà utilizzata per creare una sequenza temporale del progetto. In ogni esempio, la nostra data di inizio è il 25 ottobre.

Bilancio iniziale. Il budget fornisce vincoli che mostrano se tutte le funzionalità MVP si adatteranno o meno al suo interno.

Taglia della maglietta. Inserisci le taglie delle tue magliette come tabella e assegna punti storia e un intervallo di ore a ciascuna combinazione di taglie. In questo esempio, utilizziamo da una a due ore per un SS e da 33 a 48 ore per un LL.

Tieni presente che la durata dello sprint limiterà le ore della tua taglia massima di maglietta. Se lo sprint dura solo una settimana, la dimensione massima non può superare le 40 ore. Questo è il motivo per cui consultare una PMI è così importante quando si assegnano le taglie delle magliette ai compiti .

Tariffe all'ora. Utilizzare questa tabella per documentare le tariffe retributive per ciascun ruolo. Se i tuoi sviluppatori back-end hanno tariffe diverse, usa la media delle due.

Sovraccarico. Assegna una percentuale dello sforzo totale del progetto alle attività amministrative come riunioni sullo stato, sessioni di feedback e revisioni del progetto. Il dieci percento (o quattro ore della settimana lavorativa di ciascun partecipante) è un buon punto di partenza, ma le spese generali potrebbero essere più elevate per i progetti più complessi.

Contingenza. Questo indica la potenziale varianza nella tua stima. Iniziare con una contingenza dello 0% ti mostrerà il budget e la sequenza temporale migliori (cioè improbabili) dati i valori che hai inserito nel foglio di calcolo. Più avanti nel nostro esempio, aumenteremo la contingenza a una varianza approssimativa dell'ordine di grandezza (ROM) del 50% per mostrare la fascia alta potenziale dei costi e la durata del progetto. La contingenza si ridurrà man mano che otterrai numeri più precisi.

Ridimensiona ogni versione con Epics

Iniziamo con un dimensionamento approssimativo dell'intero prodotto per assicurarci di non sprecare tempo o denaro del cliente. A seconda di quanto il dimensionamento si avvicina al budget e alla scadenza proposti, il cliente può decidere di abbandonare il progetto o investire in preventivi più dettagliati. Poiché a questo punto non abbiamo molti dettagli, inseriamo le caratteristiche principali come epiche nella scheda Backlog/Storie utente. Quindi, per ogni epica, inseriamo il numero di ore che le PMI e i leader dello sviluppo hanno suggerito per ogni stack di sviluppo in base alla tabella delle taglie delle magliette nella scheda Parametri.

Innanzitutto, seleziona la colonna "EPIC?" e assicurati che sia selezionato solo "Epic".

Quindi, scrivi la descrizione epica e inserisci il numero di ore per ciascuna colonna dello stack di sviluppo. Ad esempio, l'epico "Connessione e accesso sicuri" richiederà circa otto ore di sviluppo dell'interfaccia utente, 40 per il back-end e così via.

Si noti che nella maggior parte dei casi, le celle nella colonna "Punto" visualizzano "34*". Se torni alla scheda Parametri, vedrai che 34 punti corrispondono a un intervallo orario compreso tra 33 e 48 ore. Quel numero di ore è troppo grande se la durata dello sprint è solo di una settimana.

Una volta che avremo maggiori dettagli, queste ore dovranno essere ridotte, o le epopee dovranno essere suddivise in storie più gestibili. Per motivi di tempo, tuttavia, ignoreremo la colonna Punti e continueremo con la stima approssimativa.

Ora vai alla scheda Riepilogo stima per rilascio. Nella parte superiore del foglio di lavoro, vedrai i valori "Spese generali" e "Contingenza" come definito nella scheda Parametri. C'è anche un pulsante che puoi selezionare per mostrare le stime per epiche o storie degli utenti.

Poiché non abbiamo ancora storie utente da visualizzare, controlla il pulsante "Modalità epica".

Ora puoi vedere i costi approssimativi e le tempistiche per l'MVP e le funzionalità e gli aggiornamenti meno urgenti nelle versioni future (R3 e R4). In questo esempio, la seconda versione (R2) è vuota perché il cliente ha richiesto che tutte le epopee MVP vengano lanciate nella prima versione.

Ora puoi vedere il costo aggregato più ottimistico: $ 28.810. Questa cifra è la somma del costo di ogni versione dall'MVP a R4.

Abbiamo anche una stima della tempistica più breve per la consegna del prodotto, che corrisponde all'ultima data di completamento nello stack di sviluppo R4. I project manager chiamano questi stack di sviluppo più lenti "percorsi critici" perché determinano la velocità dell'intero rilascio.

In questo caso il percorso critico è lo sviluppo del front-end, con data di completamento il 31 gennaio.

Ora è il momento di regolare i parametri per simulare il budget peggiore e la sequenza temporale più lunga.

Regola la contingenza al 50%

Sappiamo ancora relativamente poco dei requisiti di impegno e competenza per il prodotto, quindi aggiungeremo una contingenza ROM del 50% nella scheda Parametri. La contingenza diminuirà man mano che apprendiamo maggiori dettagli sul progetto.

Ancora una volta, ecco la stima totale del progetto con una contingenza dello 0%.

Ed eccolo al 50% di contingenza.

Ciò significa che la stima della ROM per l'intero progetto è compresa tra $ 28.810 e $ 41.860. Nel migliore e nel peggiore dei casi, il budget di $ 20.000 del cliente non sarà sufficiente per includere tutte le funzionalità nella sua lista dei desideri.

La data di completamento del progetto completo con una contingenza del 50% cade ora il 14 marzo, sei settimane dopo la data di completamento con una contingenza dello 0%.

Nel frattempo, l'MVP sarà pronto il 10 gennaio.

Invece di abbandonare il progetto, il cliente richiede un preventivo più dettagliato per vedere se potrebbe arrivare più vicino al budget target con una tempistica più breve.

Riassegna la priorità per rispettare le scadenze

Supponiamo che il cliente fissi una data obiettivo del 25 dicembre per l'MVP, due mesi dal kickoff del 25 ottobre.

Per anticipare l'attuale data di completamento dell'MVP del 10 gennaio, il cliente ha accettato di posticipare due epiche MVP fino alla prossima versione (R2).

Il foglio di calcolo calcola l'effetto a cascata di questo aggiustamento. In questo caso, la sequenza temporale dell'MVP si riduce al 27 dicembre. Lo sviluppo front-end e back-end sono i percorsi critici in questa simulazione perché impiegheranno più tempo per essere completati.

Sulla base di queste informazioni, potresti decidere di aggiungere altri due sviluppatori per allineare le date di completamento del front-end e del back-end con gli altri stack di sviluppo. Per fare ciò, aumenta le ore da 40 a 80 nella riga "Ore settimanali" MVP.

Entrambi gli stack di sviluppo front-end e back-end ora terminano a novembre e il QA diventa il nuovo percorso critico (con una data di completamento del 20 dicembre). Si noti che il costo non cambia. Questo perché le ore totali di lavoro in ogni pila rimangono le stesse. Invece di uno sviluppatore che lavora per due settimane (80 ore), due sviluppatori lavorano per una settimana (80 ore).

Il foglio di calcolo tiene conto anche delle differenze tra il lavoro a tempo pieno e quello part-time. Supponiamo che lo sviluppatore dell'interfaccia utente lavorerà a tempo parziale. Possiamo modificare l'interfaccia utente "Ore di progettazione alla settimana" a 20 per simulare il ritardo nella consegna.

Con un programma a tempo pieno, UX/UI sarà completo il 29 novembre.

Con un programma part-time, UX/UI sarà completato il 27 dicembre.

Ancora una volta il costo non cambia, ma UX/UI diventa il nuovo percorso critico, estendendo la timeline dell'MVP al 27 dicembre.

Puoi continuare questo approccio per tentativi ed errori fino a raggiungere un percorso critico accettabile date le tue risorse e la scadenza del cliente. Una volta stabilita una scadenza appropriata, è il momento di iniziare a perfezionare la tua stima.

Affina la tua stima con le storie degli utenti

Poiché la stima di emergenza del 50% non rientrava nel budget del cliente, vale la pena perfezionare le variabili in modo da poter ridurre la contingenza e ottenere una stima più realistica.

Per fare ciò, collabora con i tuoi sviluppatori e le PMI per suddividere i tuoi poemi epici in storie utente dettagliate. Le storie sono definite meglio delle epiche, quindi possiamo ridimensionarle in modo più accurato.

Quindi, regola i valori nella scheda Parametri in base a qualsiasi nuova informazione. Ad esempio, le PMI e il team di sviluppo potrebbero disporre di una serie più accurata di tariffe per ciascun ruolo e potrebbero anche voler modificare le taglie delle magliette e l'assegnazione dei punti. Con questi nuovi parametri in atto, puoi avere maggiore fiducia nei tuoi calcoli e ridurre la contingenza al 25%.

Diamo un'occhiata a come abbiamo suddiviso l'epopea in storie utente più piccole e dettagliate:

A differenza della stima epica che richiedeva l'inserimento manuale delle ore stimate per ogni pila, la stima della storia utilizza la taglia della maglietta come scorciatoia. È qui che le taglie delle magliette che hai inserito nella scheda Parametri tornano utili.

In "Taglia maglietta" nella scheda Backlog/Storie utente, inserisci la combinazione di dimensioni che i tuoi sviluppatori e PMI hanno assegnato ai loro stack per ogni storia. Da lì, la formula del foglio di calcolo compilerà automaticamente le ore corrispondenti dalla scheda Parametri. Ricorda che la taglia più grande, LL, deve rimanere al di sotto di 34 punti per garantire che possa essere completata entro la durata dello sprint concordata. Tutte le storie che valgono ancora 34 punti o più dovranno essere suddivise.

Dopo esserti assicurato che a tutte le storie siano assegnati meno di 34 punti, deseleziona il pulsante "Modalità epica" nella scheda Riepilogo stima per pubblicazione per visualizzare solo la "Storia".

Ora vedrai un nuovo set di numeri:

Dopo aver dettagliato tutte le attività e aver rispettato solo le funzionalità MVP, la sequenza temporale e il costo ora corrispondono ai requisiti del cliente. Poiché il saldo rientra ampiamente nel proprio budget, il cliente decide di procedere con l'MVP e testarlo prima di impegnarsi in ulteriori rilasci.

Fallo tuo

I fogli di calcolo sono semplici da usare e, con una conoscenza di base delle formule (non sono necessarie macro), puoi adattarli a quasi tutte le esigenze. Se la tua conoscenza di Excel è arrugginita, i corsi online su Udemy ed edX ti aiuteranno a rispolverare queste abilità.

Questo articolo ha trattato la stima della scoperta, ma puoi utilizzare lo stesso foglio di calcolo per produrre grafici di burnup/burndown, regolare le linee temporali e calcolare le stime in base alla velocità e agli sprint per le fasi successive. Uso i miei fogli di calcolo personalizzati per integrare applicazioni, come Jira, Asana e Trello, e ritengo che siano uno strumento potente nel mio kit di gestione dei progetti. Spero che ti dimostrino altrettanto utili e versatili.

Preferisci i fogli di calcolo personalizzati agli strumenti di gestione dei progetti standard? Dicci perché o perché no nei commenti.