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.

Lo Space «Sprint» in KeenHour: la board del modelloLo Space «Sprint» in KeenHour: la board del modello

Le fasi

  1. 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».
  2. 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».
  3. 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».
  4. 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 · 12

    Una 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 · 12

    Arrivano 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 · 12

    Si 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 · 12

    Elementi 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 · 9

    Un 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 · 9

    La 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 · 6

    Si 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 modelli li scriviamo con cura, ma possiamo sbagliare: una norma cambiata, una durata ottimistica, un passaggio che manca. Sono un punto di partenza, non una consulenza: prima di impegnarti con un cliente, adattali al tuo caso. Hai trovato un errore? Scrivici: lo correggiamo per tutti e ti diciamo quando è fatto.

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.