Guida Scrum | 25. Gioco di stima della squadra

Il Team Estimation Game è una tecnica che facilita lo Sprint Planning in Scrum. In cosa differisce da Planning Poker? Perché alcuni team di sviluppo lo trovano uno strumento più efficace e altri no? Troverai tutto ciò che devi sapere al riguardo nel seguente articolo.

Gioco di stima della squadra – sommario:

1. introduzione
2. Regole del gioco di stima della squadra
3. Gioco di stima della squadra contro pianificazione del poker
4. Riepilogo

introduzione

Il Team Estimation Game è anche chiamato Swimlanes Estimation. Quest'ultimo termine è nato come osservazione spontanea di un gioco di carte poiché l'esposizione delle carte somigliava alle corsie di nuoto di una piscina d'acqua.

Scriviamo di questa tecnica nell'articolo precedente. Oggi, concentriamoci sul gioco di stima del team.

Regole del gioco di stima della squadra

Suggerimenti del gioco per la stima della squadra:

• un mazzo di carte User Story, preparato separatamente per ogni gioco
• un mazzo di carte Story Point – per un uso ripetuto

Per prima cosa, impila le schede User Story nell'ordine corrispondente alle voci nel Product Backlog. Per garantire che quelli più urgenti vengano valutati prima.

Le schede punteggio di solito contengono valori corrispondenti alla sequenza di Fibonacci. Questa è una sequenza dei seguenti numeri: 0, 1, 3, 5, 8, 13, 20, 40 e 100. Puoi anche etichettarli con poteri successivi del numero 2, cioè 2, 4, 8, 16, 32 e così via.

Le fasi del gioco Team Estimation:

1. Introduzione. Per giocare al Team Estimation Game, i membri dello Scrum Team si siedono attorno a un tavolo. Il Product Owner inizia pescando la prima carta dal mazzo User Story e condividendone il contenuto con tutti. Poi le carte restano sul tavolo. Quindi il Product Owner spiega al resto dello Scrum Team che d'ora in poi i giocatori valuteranno le User Story come facili o difficili da implementare posizionandole di conseguenza a sinistra e a destra. Se qualcuno ha un certo grado di difficoltà, il giocatore si accumulerà insieme, uno sopra l'altro sul tavolo. Ora, la persona seduta accanto a loro in senso orario fa la mossa successiva.
2. Un giocatore pesca una carta dal mazzo User Story. Dopo averne condiviso il contenuto con tutti, ne spiega l'essenza al Product Owner. La persona in possesso della carta la posiziona quindi sul tavolo e seleziona un posto in base alla propria opinione sulla difficoltà di questa User's Story. Quindi, il giocatore spiega a tutti la motivazione alla base della scelta e l'altro giocatore è libero di porre domande relative al ragionamento. Non possono mettere in discussione la decisione stessa, ma gli argomenti che giustificano la decisione.
3. Ora, i giocatori fanno un turno e hanno due opzioni tra cui scegliere:
• Ripetere il passaggio 2 o
• Sposta una delle carte sul tavolo nella posizione più appropriata

Se scelgono la seconda opzione, dovrebbero anche giustificare ciò che gli ha fatto cambiare idea. I giocatori, a turno, ripetono il passaggio 3 fino a quando tutte le carte del mazzo User Story vengono distribuite e stimate.

4. La fase finale del piazzamento delle carte User Story avviene una o più volte, a seconda della pratica dello Scrum Team. Durante questo round, ogni giocatore ha ancora un'altra opportunità per spostare una delle carte sul tavolo in un posto più appropriato.
5. Una volta che i giocatori hanno assegnato tutte le carte User Story alle loro posizioni che rappresentano i livelli di difficoltà, il Team di sviluppo passa al valore di corrispondenza assegnando le carte dalla pila dei punti storia. La prima carta User Story a sinistra riceve la carta Story Point con il minor numero di punti dal Product Owner. La regola per piazzare le carte successive è la stessa dei punti 3 e 4. Questo completa la stima.

Gioco di stima della squadra contro pianificazione del poker

Il Team Estimation Game è considerato uno strumento di stima più efficace di Planning Poker. A causa delle seguenti differenze tra queste due tecniche:

• Tavolo da gioco. Il gioco Team Estimation utilizza la famosa "regola del tavolo da gioco" dei popolari giochi di carte. Ciò significa che una volta posizionata una carta, non puoi riprenderla. Poiché la User Story viene stimata da una persona alla volta, la fluttuazione tra le stime e il numero di volte in cui le posizioni di spostamento sono significativamente inferiori, rispetto a Planning Poker.
• Un calcolo abbastanza accurato. In Planning Poker, dovrebbe essere raggiunto un consenso completo per ogni User Story. In Team Estimation Game, tuttavia, solo una persona decide. Anche se la sua stima è sbagliata, è probabile che un altro Sviluppatore la collocherà in modo più preciso in corrispondenza del suo valore. In questo modo si garantisce il raggiungimento di preventivi sufficientemente precisi e rapidi
• Faticoso argomento di discussione. Le scelte di discussione spesso diventano eccessivamente lunghe quando si gioca a Planning Poker. Il loro tempo è notevolmente ridotto durante un gioco di stima del team perché si concentrano su una singola decisione di uno degli sviluppatori piuttosto che sulla natura di ogni storia utente.

Un potenziale svantaggio del Team Estimation Game è un senso di ingiustizia. Se il Team di sviluppo è maggiore del numero di User Story programmate in un determinato Sprint, alcuni Sviluppatori potrebbero sentirsi esclusi.

Gioco di stima della squadra – riepilogo

Team Estimation Game ha un'opinione sulla tecnica di stima più efficace per la maggior parte degli Scrum Team. Tuttavia, è importante ricordare che è solo uno strumento per stimare la difficoltà e lo sforzo delle User Story. E come ogni strumento, dovremmo adattarlo alle esigenze e alle capacità dei membri del team.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog