Template per Definition of Done e User Story
Serve a product owner, Scrum Master e team di sviluppo che vogliono fissare uno standard unico di 'fatto' e un formato coerente di user story, eliminando le ambiguità che generano rework e contestazioni in fase di review.
Esempio di output
# Standard di Team: Definition of Done & User Story Template ## 1. Scopo Questo documento fissa cosa significa «fatto» nel nostro team e come scriviamo le user story, per ridurre ambiguità e rework. ## 2. Definition of Done ### 2.1 DoD a livello di User Story - [ ] Codice sviluppato e sottoposto a code review - [ ] Test unitari scritti e verdi - [ ] Criteri di accettazione tutti soddisfatti - [ ] Nessun bug bloccante aperto ### 2.2 DoD a livello di Sprint - [ ] Incremento integrato e deployabile in ambiente di staging - [ ] Documentazione utente aggiornata ### 2.3 DoD a livello di Release - [ ] Test di regressione superati - [ ] Approvazione del Product Owner ## 3. Template di User Story **Titolo:** [breve] **Narrativa:** Come [ruolo], voglio [funzionalità], così da [beneficio]. **Priorità:** Alta/Media/Bassa · **Stima:** [SP] ### Criteri di accettazione (Gherkin) ``` Scenario: Reset password riuscito Dato un utente registrato con email valida Quando richiede il reset della password Allora riceve un'email con link valido entro 2 minuti ``` ## 4. Esempio compilato **Titolo:** Reset password via email **Narrativa:** Come utente registrato, voglio reimpostare la password via email, così da rientrare nell'account se la dimentico. ## 5. Checklist di qualità della user story (INVEST) | Criterio | Domanda di controllo | |---|---| | Independent | La storia è autonoma? | | Valuable | Porta valore all'utente? | | Estimable | È stimabile? | | Small | Sta in uno sprint? | | Testable | I criteri sono verificabili? |
Domande frequenti
La DoD vale per tutte le storie e definisce la qualità minima di rilascio (test, code review, documentazione). I criteri di accettazione sono specifici della singola storia e descrivono il comportamento atteso. Il template produce entrambi e ne spiega la distinzione al team.
Il formato Dato/Quando/Allora rende i criteri verificabili e direttamente traducibili in test. Il template li scrive così di default, ma puoi chiedere una versione a checklist se il team non usa Gherkin.
Sì. Il template produce una DoD multilivello: per la singola user story, per lo sprint e per la release, così ogni gate di qualità è esplicito e non si confonde con gli altri.
Vuoi un template su misura?
Costruiscine uno in poche domande — con la struttura corretta per il tuo standard.