Modello · PMO e prodotto
Sprint di due settimane
Uno sprint Scrum di dieci giorni: planning con l'obiettivo, lavoro sulla board, affinamento del backlog, review con gli stakeholder, retrospettiva.
- 2
- settimane di piano
- 4
- fasi: le liste dello Space
- 24
- task con stime e dipendenze, 4 milestone
A chi serve
Il lavoro, com'è davvero.
Team agili, Product Owner e Scrum Master che lavorano a sprint di due settimane e vogliono eventi, capacità, Definition of Done e retrospettiva nello stesso posto del lavoro.
Con «Usa questo modello» nasce lo Space «Sprint» nel tuo workspace, con le date dal giorno che scegli: liste e stati, task con stime e dipendenze, milestone, rischi e pagine dei documenti.


Le fasi
Pianificazione
settimana 1- Inizio dello sprint
- Capacità del team nello sprint
- Sprint planning
- Obiettivo dello sprint concordatoDopo «Sprint planning», «Capacità del team nello sprint».
- Sprint backlog scomposto in taskDopo «Obiettivo dello sprint concordato».
Sviluppo
settimane 1–2- Daily ScrumDopo «Obiettivo dello sprint concordato».
- Elementi del product backlog scelti per lo sprint4 sottotaskDopo «Obiettivo dello sprint concordato».
- Difetti entrati durante lo sprintDopo «Obiettivo dello sprint concordato».
- Debito tecnico concordato con il Product OwnerDopo «Obiettivo dello sprint concordato».
- Indagine tecnica su un elemento incertoDopo «Obiettivo dello sprint concordato».
- Affinamento del product backlogDopo «Obiettivo dello sprint concordato».
- Rimozione degli impedimentiDopo «Obiettivo dello sprint concordato».
- Test di integrazione e di regressioneDopo «Indagine tecnica su un elemento incerto».
- Incremento conforme alla Definition of DoneDopo «Elementi del product backlog scelti per lo sprint», «Difetti entrati durante lo sprint», «Debito tecnico concordato con il Product Owner», «Test di integrazione e di regressione».
Review
settimana 2- Preparazione della reviewDopo «Incremento conforme alla Definition of Done».
- Rilascio dell'incremento, se il Product Owner lo decideDopo «Incremento conforme alla Definition of Done».
- Sprint Review con gli stakeholderDopo «Preparazione della review».
Retrospettiva
settimana 2- Dati dello sprint per la retrospettivaDopo «Incremento conforme alla Definition of Done».
- Sprint RetrospectiveDopo «Dati dello sprint per la retrospettiva».
- Fine dello sprintDopo «Sprint Review con gli stakeholder», «Sprint Retrospective», «Rilascio dell'incremento, se il Product Owner lo decide».
I rischi tipici
L'obiettivo dello sprint cambia a metà
Alto · 12Una richiesta urgente della direzione o del cliente entra nello sprint e scalza il lavoro concordato: l'obiettivo salta e il team smette di credere al planning.
Mitigare: Le urgenze passano dal Product Owner, che decide se possono aspettare il prossimo sprint; se l'obiettivo diventa inutile, solo il Product Owner può annullare lo sprint.
Elementi non pronti al planning
Alto · 12Arrivano al planning elementi senza criteri di accettazione o troppo grandi: si stima a occhio e a metà sprint si scopre il lavoro vero.
Mitigare: Affinamento a metà di ogni sprint; al planning entrano solo elementi che rispettano i criteri della pagina «Quando un elemento è pronto».
Impegno oltre la capacità
Alto · 12Si scelgono elementi per la velocità dello sprint migliore, senza contare ferie e assenze: lo sprint si chiude con metà del lavoro fatto.
Mitigare: Capacità calcolata prima del planning, con i giorni di presenza; si sceglie sulla media degli ultimi tre sprint, non sul massimo.
Definition of Done aggirata per chiudere
Alto · 12Elementi dichiarati fatti senza test o revisione per far tornare il burndown: il debito torna nello sprint dopo, più grande.
Evitare: Un elemento che non rispetta la Definition of Done torna nel product backlog; in review si mostra solo ciò che è fatto.
Dipendenze da altri team o da fornitori
Medio · 9Un servizio, un ambiente o una risposta che arriva da fuori blocca un elemento a metà sprint.
Mitigare: Dipendenze esterne chiarite nell'affinamento; un elemento con una dipendenza non confermata non entra nello sprint.
Stakeholder assenti alla review
Medio · 9La review diventa una riunione interna: il riscontro di chi usa il prodotto arriva tardi, quando cambiare costa di più.
Mitigare: Date delle review fissate per il trimestre; inviti personali del Product Owner a chi conta per l'obiettivo dello sprint.
Retrospettive senza azioni
Medio · 6Si ripetono gli stessi problemi ogni due settimane e non cambia niente: il team smette di parlarne.
Mitigare: Al massimo tre azioni, ognuna nello sprint backlog del prossimo sprint con chi la porta avanti; si comincia sempre dalle azioni della volta prima.
Le pagine dei documenti
- Definition of Done del team
- Eventi di uno sprint di due settimane
- Quando un elemento è pronto
- Traccia della retrospettiva
I file
In KeenHour, in Excel o in CSV.
Il modello vive in KeenHour, dove le date, il percorso critico e il carico si aggiornano da soli. Se preferisci partire da un file: l'Excel con il Gantt e il registro dei rischi, o il CSV da importare in una lista, con le date dal lunedì prossimo.
Tutti i modelli →Every hour, under control.
Il prossimo lunedì, apri la settimana con il quadro completo.
Crea il workspace, invita il team e importa i progetti in corso. Hai 14 giorni per provarlo, senza carta.