Altre storie in sprint per soluzioni rapide

Sembri un capitano sconvolto dal fatto che i tuoi rematori stiano prendendo tempo per scaricare l'acqua dalla tua barca che perde. Il bailing non ti porterà dove vuoi andare. Ma ignorare il bailing può mandarti in fondo.

Il semplice fatto è che la tua squadra deve fare un po 'di salvataggio. Hanno anche bisogno di fare pause pranzo. Vai a casa e guarda le loro famiglie. E una volta ogni tanto dormi. La vera domanda è, il tracciamento di tutto ciò in un aiuto sprint?

La pianificazione dello sprint non deve essere l'unico arbitro del credito che le persone ricevono per il loro lavoro. Se non lo è, puoi risparmiare un sacco di rumore mantenendo quel lavoro fuori dalla pianificazione. La correzione di bug insignificanti e l'aggiunta di funzionalità banali possono essere ignorate nello sprint tanto quanto le interruzioni del bagno.

Sei preoccupato che questo influenzi le misurazioni della velocità. Beh, potrebbe succedere se i bug e le caratteristiche insignificanti si esauriscano improvvisamente o si raddoppino. Ma capisci che con una sola squadra e solo 3 mesi di velocità dei dati sarà estremamente sfocato. A prescindere da quanto lavoro banale sia minimizzato, la velocità non farà ancora molto, oltre a rendere il team più prudente su quanto prevedono di poter realizzare in uno sprint determinato. Questo è il modo migliore per utilizzarlo.

Se vuoi monitorare questo lavoro, devi assolutamente consentire agli sviluppatori di aggiungere e dimensionare storie per bug e miglioramenti "facili". Non raccomanderei di portarlo via da loro. Vorrei incoraggiare l'assegnazione di priorità ai compiti e fare prima le cose più difficili.

Dici di essere principalmente preoccupato dell'impatto di queste piccole cose sulla tua capacità di stimare. Ecco la cosa, però: correzioni di bug e piccole funzionalità "quick-wins" funzionano . Calcolano nella tua velocità. Dovresti specarli e stimarli (con i punti storia o qualsiasi altra cosa tu stia facendo) in modo da poterli considerare nei tuoi dati di velocità. In altre parole, non sono una distrazione dal lavoro, SONO lavoro.

Non hai detto quale ruolo occupi nello Scrum Team, ma sembri uno Scrum Master. La domanda che ho per te è: cosa ne pensa il tuo Product Owner? È la loro chiamata. Anche durante lo sprint, spetta esclusivamente al tuo PO dire se daranno la priorità a queste cose in arrivo abbastanza alte da suggerire di inserirle nello sprint, e la responsabilità del team di sviluppo di dire se saranno loro a negoziare nello sprint Piano. Se qualcuno porta questo tipo di cose direttamente a uno sviluppatore, deve essere reindirizzato al proprietario del prodotto.

Un piano di sprint non è un impegno, è una previsione. Niente è bloccato nella pietra (o anche "impegnato in") su un piano di sprint. Il piano sprint rappresenta il lavoro che il team prevede di poter fare per raggiungere lo Sprint Goal che hanno realizzato durante la pianificazione.

STI realizzando Sprint Goals per ogni sprint, giusto? Potresti considerare di aggiungere qualcosa come "... mantenendo i clienti soddisfatti della nostra cura reattiva dei loro bisogni.", In modo che questo tipo di cose non siano completamente fuori campo da compiti fuori campo.