Esempi di punti storia: una scala di riferimento da 1 a 13
Sei esempi di backlog per aiutare il tuo team a confrontare il lavoro, mettere in discussione le ipotesi e scegliere le proprie storie di riferimento.
Una stima in punti storia esprime la dimensione relativa del lavoro per un team, considerando sforzo, complessità e incertezza. Questo rende un elemento completato e familiare un utile riferimento per discutere il successivo. La guida alla stima di Atlassian spiega questo approccio relativo.
Per esempio, un team potrebbe assegnare a una modifica familiare delle impostazioni 2 punti e a un nuovo flusso di notifiche 5. La domanda utile è: quale lavoro aggiuntivo spiega la differenza?
Gli esempi seguenti appartengono a un team fittizio che sviluppa un’area di lavoro per documenti condivisi. Sono punti di partenza per una discussione, non prezzi standard per funzionalità. Il tuo team può ragionevolmente scegliere valori diversi.
Sei esempi sulla scala di un team
Assumi che questo team abbia già una libreria di componenti, permessi per l’area di lavoro, un servizio di notifiche e controlli automatizzati nei flussi di lavoro esistenti. Ogni stima include implementazione, revisione e i controlli necessari per rispettare la definizione di completamento del team.
| Punti | Elemento del backlog | Incluso in questo esempio | Perché questo team lo colloca qui |
|---|---|---|---|
| 1 | Spiegare un feed di attività vuoto | Testo approvato e un componente di stato vuoto esistente; nessun comportamento nuovo | Una piccola modifica familiare con pochi stati coinvolti |
| 2 | Permettere agli amministratori di modificare il nome condiviso dell'area di lavoro | Modulo impostazioni esistente, API e verifica permessi amministrativi; stati di validazione e salvataggio/errore | Un percorso familiare con alcune verifiche comportamentali; elemento di riferimento del team |
| 3 | Filtrare documenti per proprietario | Componente filtro esistente e supporto API; comportamento di reset e risultati vuoti | Più stati UI interattivi rispetto al riferimento, con un percorso dati noto |
| 5 | Notificare al proprietario del documento quando qualcuno richiede accesso | Servizio di consegna esistente; controlli permessi, contenuto notifiche, gestione duplicati e link alla richiesta | Più parti esistenti devono funzionare correttamente insieme |
| 8 | Trasferire la proprietà del documento all'interno di un'area di lavoro | Nuova operazione di trasferimento; cambi permessi, modifiche concorrenti e una voce di audit | Una transizione di stato più ampia con casi di errore che richiedono accordo accurato |
| 13 | Spostare una cartella e i suoi documenti in un'altra area di lavoro | Permessi di destinazione, link, errori parziali e comportamento di recupero | Troppe decisioni connesse perché il team consideri un elemento unico e gestibile; discutere di suddividerlo |
Le assunzioni sull'infrastruttura sono importanti. Un team senza un servizio di notifiche stimerebbe un lavoro aggiuntivo nell’esempio da 5 punti. Un team con una procedura di trasferimento di proprietà consolidata potrebbe attribuire quel lavoro a un valore inferiore.
Questi numeri non sono una formula. Contare schermate UI, endpoint o criteri di accettazione non riproduce stime affidabili.
Come il perimetro modifica la stima
Considera “modificare il nome visualizzato di un’area di lavoro”. La tabella assume un amministratore che modifica l’etichetta condivisa mostrata nelle impostazioni, con un endpoint di aggiornamento esistente e controllo permessi.
Ora modifica le condizioni di accettazione:
| Versione | Ambito | Stima illustrativa |
|---|---|---|
| A | Modificare l’etichetta mostrata nelle impostazioni dell’area di lavoro; usare la procedura di salvataggio esistente | 2 |
| B | Aggiornare anche il contenuto dell’invito e la navigazione cacheata; mantenere coerenti queste superfici se l’aggiornamento riesce solo parzialmente | 5 |
| C | Il nome determina anche l’URL pubblico dell’area di lavoro; preservare i vecchi link e gestire collisioni | Pausa per chiarire, poi forse 8 o suddividere |
La versione C solleva prima una questione di prodotto prima di una di stima: rinominare deve cambiare anche l’URL? Decidere di mantenere l’URL stabile potrebbe eliminare gran parte del lavoro aggiuntivo.
Se un partecipante vota 2 mentre un altro vota 8, chiedi a ciascuno di descrivere il comportamento incluso. Entrambi potrebbero ragionare coerentemente su versioni differenti. Riscrivi le condizioni di accettazione prima di votare di nuovo.
Scegli storie di riferimento che il tuo team ricorda
Scegli due o tre elementi completati con confini chiari. Una piccola modifica familiare, un flusso di lavoro moderato e una modifica più ampia ma compresa offrono al team confronti più utili di un singolo numero astratto.
Per ogni riferimento, annota brevemente:
- Quale risultato per l’utente ha prodotto?
- Quali sistemi e stati sono cambiati?
- Quale lavoro di revisione e verifica è stato incluso?
- Quali assunzioni ne hanno facilitato o complicato la realizzazione?
Poi confronta il nuovo lavoro con il riferimento più vicino. “Somiglia alla nostra modifica alle impostazioni, ma aggiunge due percorsi di permessi” offre al team una base concreta da mettere in discussione.
Se il team non ha una storia di consegna condivisa, scegli un elemento ben compreso come riferimento provvisorio. Rivedilo dopo la consegna e mantieni visibili le assunzioni. Non è necessario inventare una scala perfetta prima che il team abbia imparato insieme.
Copia questa nota di stima in un elemento del backlog
Usa quanto segue come aiuto alla discussione nel backlog o nelle note del team:
Risultato utente:
Comportamento incluso:
Esplicitamente escluso:
Riferimento completato più vicino:
Cosa rende questo più piccolo o più grande:
Incognite che potrebbero cambiare il perimetro:
Decisione: stima / suddividi / indaga
Stima concordata, se pronta:
Prossima chiarificazione e responsabile, se necessario:
Ecco un esempio compilato per l’elemento notifica di accesso:
Risultato utente: il proprietario del documento viene informato che un membro dell’area di lavoro ha richiesto accesso e può aprire la richiesta.
Incluso: utilizzo del servizio notifiche esistente, verifica dei permessi del destinatario, collegamento alla richiesta in sospeso, ed evitamento di notifiche duplicate in caso di ritentativo di consegna.
Escluso: email di promemoria, digest giornalieri e concessione automatica dell’accesso.
Riferimento: la nostra modifica alle impostazioni da 2 punti usa un percorso di salvataggio familiare. Questo elemento unisce i percorsi di richiesta, permessi e consegna, quindi coinvolge più coordinamento e casi di errore.
Domanda aperta: il servizio già previene la consegna duplicata? Il manutentore del servizio di notifiche confermerà prima di definire la stima.
Nello scenario fittizio della tabella, quel controllo conferma il supporto alla consegna riutilizzabile e il team concorda su 5. Senza di esso, il team deve discutere il lavoro aggiuntivo prima di usare lo stesso numero. Il riferimento spiega il confronto; non calcola la risposta.
Per la sequenza della riunione, usa la guida passo per passo di Planning Poker. Copre la votazione privata, la discussione delle differenze e la scelta del risultato del turno successivo.
Quando un numero non è ancora utile
Ritorna alla chiarificazione quando un’incognita cambia la natura del lavoro. “Quale testo deve usare la notifica?” è un’incertezza diversa da “L’area di lavoro di destinazione consente utenti esterni?”
Per l’esempio dello spostamento di cartelle, il team potrebbe prima concordare un risultato utente più piccolo: spostare un documento tra aree di lavoro che l’utente amministra. Questa prima porzione richiede comunque permessi di destinazione chiari, regole di accesso preservate e gestione sicura degli errori affinché uno spostamento interrotto non perda il documento o non lo esponga a persone sbagliate. Spostare lotti di documenti può essere un elemento separato. Ridurre la dimensione del lotto restringe il lavoro; non elimina la necessità di gestire guasti.
Dopo la suddivisione, stima ogni elemento separatamente. I nuovi numeri non devono sommarsi a 13: il team ha modificato il perimetro e appreso di più sul lavoro.
Domande frequenti dei team
Quante ore corrisponde a una storia da 3 punti?
Non esiste una conversione universale. Gli esempi qui confrontano lavori all’interno di un team fittizio. Se hai bisogno di una previsione di consegna, usa la tua storia delle consegne e la capacità attuale, e discuti l’incertezza separatamente dall’etichetta del punto.
Ogni bug è un elemento da 1 punto?
No. Un errore di visualizzazione riproducibile con causa nota è diverso da una perdita dati intermittente con causa ancora sconosciuta. Chiarisci cosa stai stimando: la correzione, un’indagine o entrambi.
Ogni team deve necessariamente suddividere una storia da 13 punti?
No. Qui, 13 indica un lavoro che questo particolare team vuole analizzare e suddividere. Il limite del tuo team dipende dai suoi riferimenti e dalla capacità di comprendere e consegnare un elemento.
Porta i tuoi riferimenti in Planning Poker
Scegli alcuni elementi in arrivo, scrivi i loro confini di accettazione e tieni le storie di riferimento accanto a esses. Usa Agilo Planning Poker per la sessione di stima del team.
Crea una stanza di Planning Poker quando gli elementi sono pronti per essere discussi.
