La causa piú comune tra quelle che provocano la cancellazione dello Sprint in corso é quando il Product Owner valuta che non é piú utile completare lo Sprint (ad esempio perché il Goal dello Sprint é obsoleto e non piú valido).
In questo caso é il Product Owner che ha l'autoritá di decidere la cancellazione.
C'é un altro possibile caso.
Scrum indica chiaramente che durante il Planning Meeting all'inizio dello Sprint
- gli Item dello Sprint Backlog sono scelti dal Product Backlog insieme allo Sprint Goal
- tutti i task neccessari a completare gli Item dello Sprint Backlog che il team puo identificare in quel momento vanno aggiunti allo Sprint Backlog
E durante uno Sprint:
Quando il Burn Down Chart evidenzia che lo Sprint é in ritardo, il Goal dello Sprint puó essere ancora raggiunto ed é possibile produrre un incremento potenzialmente rilasciabile del prodotto, é necessario informare il Product Owner che puo individuare quali Item dello Sprint Backlog potenzialmente possono essere rimossi e quali semplificati. Qundi si prosegue a monitorare il Burn Down Chart.
Quando
- emerge che il Goal dello Sprint non puo essere raggiunto o non verrá prodotto un incremento potenzialmente rilasciabile del prodotto per la fine dello Sprint
- emergono attivitá urgenti non pianificate
é responsabilitá del team, ascoltati i suggerimenti dello Scrum Master, di provare a salvare lo Sprint o prevenire l'aggiunta di Item non pianificati. E dello Scrum Master quando é il caso di consigliare la cancellazione e ripianificazione dello Sprint al Product Owner che é l'unico ad averne l'autoritá.
In questo post le indicazioni utili a gestire questa situazione: Sprint Abnormal Termination
Leggi anche: How to sustain Adaptive planning
Print | posted @ lunedì 22 febbraio 2010 19:37