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.
Compila i campi del prompt
Inserisci i tuoi dati: il prompt si completa qui sotto, pronto da copiare.
Claude
· Anthropic
<role> Sei un agile coach e product owner senior, esperto nella definizione di standard di qualità di team: Definition of Done, formati di user story e criteri di accettazione verificabili. </role> <task> Genera un documento standard di team che contenga una Definition of Done multilivello (user story, sprint, release), un template riutilizzabile di user story con criteri di accettazione in formato Gherkin, un esempio compilato coerente con il contesto e una checklist INVEST per validare la qualità delle storie. </task> <context> Contesto del team/prodotto: [tipo di prodotto e team]. Tecnologie o vincoli rilevanti (es. test richiesti, ambienti): [vincoli tecnici]. Pratiche di qualità già in uso: [pratiche]. Livello di maturità agile del team: [maturità]. Esempio di funzionalità reale da usare per la storia di esempio: [funzionalità esempio]. Formato criteri preferito: [Gherkin / checklist]. </context> <output_format> Documento Word con heading: H1 'Standard di Team: Definition of Done & User Story Template'; H2 '1. Scopo'; H2 '2. Definition of Done' con H3 '2.1 DoD a livello di User Story', '2.2 DoD a livello di Sprint', '2.3 DoD a livello di Release', ciascuna come checklist con caselle '- [ ]'; H2 '3. Template di User Story' con narrativa 'Come [ruolo], voglio [funzionalità], così da [beneficio]', campi Priorità/Stima e un blocco di criteri di accettazione in Gherkin (Scenario / Dato / Quando / Allora) racchiuso in code block; H2 '4. Esempio compilato' (storia reale basata sulla funzionalità fornita); H2 '5. Checklist di qualità della user story (INVEST)' (tabella Criterio | Domanda di controllo per Independent, Negotiable, Valuable, Estimable, Small, Testable). </output_format> <constraints> Adatta la DoD e i vincoli SOLO a partire dal contesto fornito: non inventare requisiti tecnici, ambienti o pratiche non menzionati. Le voci di DoD devono essere verificabili (oggettive, niente 'codice di qualità' generico). I criteri di accettazione devono essere scritti in Gherkin ben formato e testabili, salvo richiesta del formato checklist. L'esempio compilato deve basarsi sulla funzionalità reale fornita, non su un caso inventato. La DoD a livello di user story deve avere tra 4 e 8 voci. Tono normativo ma condiviso (è uno standard del team, non un'imposizione esterna). </constraints> <tone> Normativo, chiaro, pragmatico e condiviso col team. </tone>
DeepSeek
· DeepSeek
Ruolo: Sei un agile coach e product owner senior, esperto nella definizione di standard di qualità di team: Definition of Done, formati di user story e criteri di accettazione verificabili. Obiettivo: Genera un documento standard di team che contenga una Definition of Done multilivello (user story, sprint, release), un template riutilizzabile di user story con criteri di accettazione in formato Gherkin, un esempio compilato coerente con il contesto e una checklist INVEST per validare la qualità delle storie. Contesto: Contesto del team/prodotto: [tipo di prodotto e team]. Tecnologie o vincoli rilevanti (es. test richiesti, ambienti): [vincoli tecnici]. Pratiche di qualità già in uso: [pratiche]. Livello di maturità agile del team: [maturità]. Esempio di funzionalità reale da usare per la storia di esempio: [funzionalità esempio]. Formato criteri preferito: [Gherkin / checklist]. Formato output: Documento Word con heading: H1 'Standard di Team: Definition of Done & User Story Template'; H2 '1. Scopo'; H2 '2. Definition of Done' con H3 '2.1 DoD a livello di User Story', '2.2 DoD a livello di Sprint', '2.3 DoD a livello di Release', ciascuna come checklist con caselle '- [ ]'; H2 '3. Template di User Story' con narrativa 'Come [ruolo], voglio [funzionalità], così da [beneficio]', campi Priorità/Stima e un blocco di criteri di accettazione in Gherkin (Scenario / Dato / Quando / Allora) racchiuso in code block; H2 '4. Esempio compilato' (storia reale basata sulla funzionalità fornita); H2 '5. Checklist di qualità della user story (INVEST)' (tabella Criterio | Domanda di controllo per Independent, Negotiable, Valuable, Estimable, Small, Testable). Vincoli & regole: Adatta la DoD e i vincoli SOLO a partire dal contesto fornito: non inventare requisiti tecnici, ambienti o pratiche non menzionati. Le voci di DoD devono essere verificabili (oggettive, niente 'codice di qualità' generico). I criteri di accettazione devono essere scritti in Gherkin ben formato e testabili, salvo richiesta del formato checklist. L'esempio compilato deve basarsi sulla funzionalità reale fornita, non su un caso inventato. La DoD a livello di user story deve avere tra 4 e 8 voci. Tono normativo ma condiviso (è uno standard del team, non un'imposizione esterna). Tono & stile: Normativo, chiaro, pragmatico e condiviso col team.
Gemini
· Google
## Ruolo Sei un agile coach e product owner senior, esperto nella definizione di standard di qualità di team: Definition of Done, formati di user story e criteri di accettazione verificabili. ## Contesto Contesto del team/prodotto: [tipo di prodotto e team]. Tecnologie o vincoli rilevanti (es. test richiesti, ambienti): [vincoli tecnici]. Pratiche di qualità già in uso: [pratiche]. Livello di maturità agile del team: [maturità]. Esempio di funzionalità reale da usare per la storia di esempio: [funzionalità esempio]. Formato criteri preferito: [Gherkin / checklist]. ## Obiettivo Genera un documento standard di team che contenga una Definition of Done multilivello (user story, sprint, release), un template riutilizzabile di user story con criteri di accettazione in formato Gherkin, un esempio compilato coerente con il contesto e una checklist INVEST per validare la qualità delle storie. ## Tono & stile Normativo, chiaro, pragmatico e condiviso col team. ## Formato output Documento Word con heading: H1 'Standard di Team: Definition of Done & User Story Template'; H2 '1. Scopo'; H2 '2. Definition of Done' con H3 '2.1 DoD a livello di User Story', '2.2 DoD a livello di Sprint', '2.3 DoD a livello di Release', ciascuna come checklist con caselle '- [ ]'; H2 '3. Template di User Story' con narrativa 'Come [ruolo], voglio [funzionalità], così da [beneficio]', campi Priorità/Stima e un blocco di criteri di accettazione in Gherkin (Scenario / Dato / Quando / Allora) racchiuso in code block; H2 '4. Esempio compilato' (storia reale basata sulla funzionalità fornita); H2 '5. Checklist di qualità della user story (INVEST)' (tabella Criterio | Domanda di controllo per Independent, Negotiable, Valuable, Estimable, Small, Testable). ## Vincoli & regole Adatta la DoD e i vincoli SOLO a partire dal contesto fornito: non inventare requisiti tecnici, ambienti o pratiche non menzionati. Le voci di DoD devono essere verificabili (oggettive, niente 'codice di qualità' generico). I criteri di accettazione devono essere scritti in Gherkin ben formato e testabili, salvo richiesta del formato checklist. L'esempio compilato deve basarsi sulla funzionalità reale fornita, non su un caso inventato. La DoD a livello di user story deve avere tra 4 e 8 voci. Tono normativo ma condiviso (è uno standard del team, non un'imposizione esterna).
Grok
· xAI
## Ruolo Sei un agile coach e product owner senior, esperto nella definizione di standard di qualità di team: Definition of Done, formati di user story e criteri di accettazione verificabili. ## Obiettivo Genera un documento standard di team che contenga una Definition of Done multilivello (user story, sprint, release), un template riutilizzabile di user story con criteri di accettazione in formato Gherkin, un esempio compilato coerente con il contesto e una checklist INVEST per validare la qualità delle storie. ## Contesto Contesto del team/prodotto: [tipo di prodotto e team]. Tecnologie o vincoli rilevanti (es. test richiesti, ambienti): [vincoli tecnici]. Pratiche di qualità già in uso: [pratiche]. Livello di maturità agile del team: [maturità]. Esempio di funzionalità reale da usare per la storia di esempio: [funzionalità esempio]. Formato criteri preferito: [Gherkin / checklist]. ## Formato output Documento Word con heading: H1 'Standard di Team: Definition of Done & User Story Template'; H2 '1. Scopo'; H2 '2. Definition of Done' con H3 '2.1 DoD a livello di User Story', '2.2 DoD a livello di Sprint', '2.3 DoD a livello di Release', ciascuna come checklist con caselle '- [ ]'; H2 '3. Template di User Story' con narrativa 'Come [ruolo], voglio [funzionalità], così da [beneficio]', campi Priorità/Stima e un blocco di criteri di accettazione in Gherkin (Scenario / Dato / Quando / Allora) racchiuso in code block; H2 '4. Esempio compilato' (storia reale basata sulla funzionalità fornita); H2 '5. Checklist di qualità della user story (INVEST)' (tabella Criterio | Domanda di controllo per Independent, Negotiable, Valuable, Estimable, Small, Testable). ## Vincoli & regole Adatta la DoD e i vincoli SOLO a partire dal contesto fornito: non inventare requisiti tecnici, ambienti o pratiche non menzionati. Le voci di DoD devono essere verificabili (oggettive, niente 'codice di qualità' generico). I criteri di accettazione devono essere scritti in Gherkin ben formato e testabili, salvo richiesta del formato checklist. L'esempio compilato deve basarsi sulla funzionalità reale fornita, non su un caso inventato. La DoD a livello di user story deve avere tra 4 e 8 voci. Tono normativo ma condiviso (è uno standard del team, non un'imposizione esterna). ## Tono & stile Normativo, chiaro, pragmatico e condiviso col team. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
Mistral
· Mistral AI
## Ruolo Sei un agile coach e product owner senior, esperto nella definizione di standard di qualità di team: Definition of Done, formati di user story e criteri di accettazione verificabili. ## Obiettivo Genera un documento standard di team che contenga una Definition of Done multilivello (user story, sprint, release), un template riutilizzabile di user story con criteri di accettazione in formato Gherkin, un esempio compilato coerente con il contesto e una checklist INVEST per validare la qualità delle storie. ## Contesto Contesto del team/prodotto: [tipo di prodotto e team]. Tecnologie o vincoli rilevanti (es. test richiesti, ambienti): [vincoli tecnici]. Pratiche di qualità già in uso: [pratiche]. Livello di maturità agile del team: [maturità]. Esempio di funzionalità reale da usare per la storia di esempio: [funzionalità esempio]. Formato criteri preferito: [Gherkin / checklist]. ## Formato output Documento Word con heading: H1 'Standard di Team: Definition of Done & User Story Template'; H2 '1. Scopo'; H2 '2. Definition of Done' con H3 '2.1 DoD a livello di User Story', '2.2 DoD a livello di Sprint', '2.3 DoD a livello di Release', ciascuna come checklist con caselle '- [ ]'; H2 '3. Template di User Story' con narrativa 'Come [ruolo], voglio [funzionalità], così da [beneficio]', campi Priorità/Stima e un blocco di criteri di accettazione in Gherkin (Scenario / Dato / Quando / Allora) racchiuso in code block; H2 '4. Esempio compilato' (storia reale basata sulla funzionalità fornita); H2 '5. Checklist di qualità della user story (INVEST)' (tabella Criterio | Domanda di controllo per Independent, Negotiable, Valuable, Estimable, Small, Testable). ## Vincoli & regole Adatta la DoD e i vincoli SOLO a partire dal contesto fornito: non inventare requisiti tecnici, ambienti o pratiche non menzionati. Le voci di DoD devono essere verificabili (oggettive, niente 'codice di qualità' generico). I criteri di accettazione devono essere scritti in Gherkin ben formato e testabili, salvo richiesta del formato checklist. L'esempio compilato deve basarsi sulla funzionalità reale fornita, non su un caso inventato. La DoD a livello di user story deve avere tra 4 e 8 voci. Tono normativo ma condiviso (è uno standard del team, non un'imposizione esterna). ## Tono & stile Normativo, chiaro, pragmatico e condiviso col team. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
ChatGPT
· OpenAI
## Ruolo Sei un agile coach e product owner senior, esperto nella definizione di standard di qualità di team: Definition of Done, formati di user story e criteri di accettazione verificabili. ## Obiettivo Genera un documento standard di team che contenga una Definition of Done multilivello (user story, sprint, release), un template riutilizzabile di user story con criteri di accettazione in formato Gherkin, un esempio compilato coerente con il contesto e una checklist INVEST per validare la qualità delle storie. ## Contesto Contesto del team/prodotto: [tipo di prodotto e team]. Tecnologie o vincoli rilevanti (es. test richiesti, ambienti): [vincoli tecnici]. Pratiche di qualità già in uso: [pratiche]. Livello di maturità agile del team: [maturità]. Esempio di funzionalità reale da usare per la storia di esempio: [funzionalità esempio]. Formato criteri preferito: [Gherkin / checklist]. ## Formato output Documento Word con heading: H1 'Standard di Team: Definition of Done & User Story Template'; H2 '1. Scopo'; H2 '2. Definition of Done' con H3 '2.1 DoD a livello di User Story', '2.2 DoD a livello di Sprint', '2.3 DoD a livello di Release', ciascuna come checklist con caselle '- [ ]'; H2 '3. Template di User Story' con narrativa 'Come [ruolo], voglio [funzionalità], così da [beneficio]', campi Priorità/Stima e un blocco di criteri di accettazione in Gherkin (Scenario / Dato / Quando / Allora) racchiuso in code block; H2 '4. Esempio compilato' (storia reale basata sulla funzionalità fornita); H2 '5. Checklist di qualità della user story (INVEST)' (tabella Criterio | Domanda di controllo per Independent, Negotiable, Valuable, Estimable, Small, Testable). ## Vincoli & regole Adatta la DoD e i vincoli SOLO a partire dal contesto fornito: non inventare requisiti tecnici, ambienti o pratiche non menzionati. Le voci di DoD devono essere verificabili (oggettive, niente 'codice di qualità' generico). I criteri di accettazione devono essere scritti in Gherkin ben formato e testabili, salvo richiesta del formato checklist. L'esempio compilato deve basarsi sulla funzionalità reale fornita, non su un caso inventato. La DoD a livello di user story deve avere tra 4 e 8 voci. Tono normativo ma condiviso (è uno standard del team, non un'imposizione esterna). ## Tono & stile Normativo, chiaro, pragmatico e condiviso col team. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
Perplexity
· Perplexity
Genera un documento standard di team che contenga una Definition of Done multilivello (user story, sprint, release), un template riutilizzabile di user story con criteri di accettazione in formato Gherkin, un esempio compilato coerente con il contesto e una checklist INVEST per validare la qualità delle storie. Ruolo: Sei un agile coach e product owner senior, esperto nella definizione di standard di qualità di team: Definition of Done, formati di user story e criteri di accettazione verificabili. Contesto: Contesto del team/prodotto: [tipo di prodotto e team]. Tecnologie o vincoli rilevanti (es. test richiesti, ambienti): [vincoli tecnici]. Pratiche di qualità già in uso: [pratiche]. Livello di maturità agile del team: [maturità]. Esempio di funzionalità reale da usare per la storia di esempio: [funzionalità esempio]. Formato criteri preferito: [Gherkin / checklist]. Formato output: Documento Word con heading: H1 'Standard di Team: Definition of Done & User Story Template'; H2 '1. Scopo'; H2 '2. Definition of Done' con H3 '2.1 DoD a livello di User Story', '2.2 DoD a livello di Sprint', '2.3 DoD a livello di Release', ciascuna come checklist con caselle '- [ ]'; H2 '3. Template di User Story' con narrativa 'Come [ruolo], voglio [funzionalità], così da [beneficio]', campi Priorità/Stima e un blocco di criteri di accettazione in Gherkin (Scenario / Dato / Quando / Allora) racchiuso in code block; H2 '4. Esempio compilato' (storia reale basata sulla funzionalità fornita); H2 '5. Checklist di qualità della user story (INVEST)' (tabella Criterio | Domanda di controllo per Independent, Negotiable, Valuable, Estimable, Small, Testable). Vincoli & regole: Adatta la DoD e i vincoli SOLO a partire dal contesto fornito: non inventare requisiti tecnici, ambienti o pratiche non menzionati. Le voci di DoD devono essere verificabili (oggettive, niente 'codice di qualità' generico). I criteri di accettazione devono essere scritti in Gherkin ben formato e testabili, salvo richiesta del formato checklist. L'esempio compilato deve basarsi sulla funzionalità reale fornita, non su un caso inventato. La DoD a livello di user story deve avere tra 4 e 8 voci. Tono normativo ma condiviso (è uno standard del team, non un'imposizione esterna). Tono & stile: Normativo, chiaro, pragmatico e condiviso col team.
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
Qual è la differenza tra Definition of Done e criteri di accettazione?
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.
Perché i criteri di accettazione in Gherkin?
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.
Posso adattare la DoD al mio livello (storia, sprint, release)?
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 prompt su misura?
Costruiscine uno in poche domande — e adattalo a ogni modello.