In che modo forniamo stime di tempo valide durante Sprint Planning senza fare "troppo" design?

1. Pianifica una riunione "grooming" ricorrente in cui hai queste discussioni sul design. La squadra in cui mi trovo li ha una volta per ogni sprint, il giorno prima della pianificazione. L'obiettivo è quello di avere il design sufficientemente definito da consentire al team di concordare le stime di tempo per la storia generale. Potresti prendere in considerazione l'idea di interrompere l'attività in questo incontro, in modo tale che la pianificazione diventi puramente un esercizio per decidere quanto raccogliere. In altre parole dovresti fare il disegno negli sprint PRIMA di iniziare a fare il lavoro vero.

2. Considera l'utilizzo del pianificazione del poker , ovvero punti / unità di "sforzo" piuttosto che giornate uomo per stimare compiti. Cerca anche di abbattere le storie il più possibile. Più lunga / complessa è una storia, minore è la probabilità che la tua stima sia accurata.

3. Nella pianificazione, il mischia dovrebbe mantenere la pianificazione in pista chiamando a una fermata qualsiasi discussione che arriva troppo in "risoluzione". A quel punto i membri della squadra sono tenuti a raggiungere rapidamente un accordo sulla stima, di solito dando un numero limite superiore / peggiore. È molto più facile raccogliere più lavoro se le attività finiscono per essere più semplici di quanto pianificate, piuttosto che affrontare lo slittamento delle pianificazioni a causa di attività che richiedono più tempo del previsto e storie che si susseguono in più sprint.

4. Parla di come le stime sono state estrapolate nella retrospettiva alla fine dello sprint. Soprattutto se ce n'erano alcuni che erano notevolmente lontani. Il team ha imparato qualcosa da come è andata la storia rispetto a come si aspettavano che andasse? Il maestro di mischia dovrebbe mantenere l'attenzione sui cambiamenti attuabili che possono essere apportati al tuo progetto / processo di stima.

Penso che il problema sia che stai provando a stimare il tempo. Non farlo.

Stima la complessità. Osserva un requisito (si spera che sia una user story) e valuta quanto sia complicato il team pensa di capire come crearlo e testarlo, in relazione a quanto complicati siano gli altri requisiti o le user story. A volte ti sbagli, ma spesso ti farai un'idea di quanto durerà qualcosa. Scoprirai anche che gli oggetti con la stessa complessità tendono a richiedere lo stesso sforzo per completare.

Quindi, le classifiche della complessità diventano i "punti della storia" associati alle storie degli utenti nel backlog del prodotto. Dopo aver lavorato su alcuni sprint, avrai un'idea di quanti punti della storia puoi attraversare in uno sprint, e questa è la tua velocità. A quel punto, avrai un'idea molto migliore di quanto tempo ogni elemento avrà.

Consiglio vivamente le User Stories applicate di Mike Cohn .

So che la tua domanda riguarda specificamente l'evitare la progettazione nella pianificazione. Ma questo è un tipo di XY Problem .

Sono stato dove sei. Piuttosto che darti qualcosa che possa fornire un miglioramento incrementale, mi piacerebbe aiutarti a superare alcuni di questi stati intermedi.

Qui ci sono tre cose che il nostro team fa specificamente in relazione alla pianificazione e all'esecuzione del lavoro. Questi ci hanno aiutato a evitare il thrashing del design e ad evitare stime temporali imprecise.

Criteri di accettazione automatici

Le nostre storie sono indicate dal loro numero di Criteri di accettazione automatici . Questo significa che se dovessimo scrivere test automatici per confermare che la storia è stata fatta, quali sarebbero?

Ad esempio, "Quando l'utente fa clic su" riproduci "su un iPad con iOS 6+, inizia la riproduzione del video." Potrebbe essere difficile automatizzare questo test, ma è un criterio di accettazione (AC) della storia e contribuisce a un punto.

Usiamo la scala di Fibonacci, e arrotoliamo sempre. Quindi, se una storia ha quattro criteri di accettazione automatici, è una storia di cinque punti.

La dimensione massima del nostro story point è di otto punti, ma raramente li abbiamo. Se una storia ha più di cinque criteri di accettazione automatici, troviamo un modo per dividerli.

Pre-Preparando

Lunedì abbiamo una riunione preliminare, ma i nostri incontri di toelettatura sono il luogo in cui avviene la pianificazione del team. Prima di governare, i membri del team pre-governano una storia descrivendo il risultato e prendendo una pugnalata ai criteri di accettazione automatici.

Il grooming porta le competenze del team a gestire storie pre-governate, a soddisfare requisiti non specificati, a rompere storie, ecc.

A volte elenciamo le attività oltre ai criteri di accettazione, ma non si tratta di un tempo stimato. Non stimiamo mai il tempo. I compiti sono solo dichiarazioni di lavoro che devono essere fatte a sostegno dei criteri.

Limitazione del work-in-progress

Scrum tradizionale tenta di limitare il tempo di lavoro alla durata dello sprint. Abbiamo scoperto che questo ci ha causato artificialmente di avere fretta di rispettare le scadenze, uccidendo i nostri fine settimana perché lo sprint finisce venerdì.

Un altro approccio è limitare il work in progress in qualsiasi momento. Siamo passati a quest'ultimo e siamo stati notevolmente più felici.

Una volta che una storia si sposta dall'arretrato al work in progress, la caratterizziamo come in uno dei diversi stati:

• Sospeso: il lavoro di squadra non può avvenire perché stiamo aspettando qualche attività extra del team
• In sviluppo: lavorare per raggiungere i criteri di accettazione
• Test delle esigenze: crediamo di aver incontrato l'AC, in attesa che qualcun altro verifichi
• In Test - la storia è in fase di valutazione rispetto all'AC, i bug vengono affrontati
• Pronto per la distribuzione - alla prossima opportunità disponibile, è in esecuzione

Quindi usiamo il numero di storie in ogni stato per guidare l'attenzione del team. Ad esempio, uno sviluppatore potrebbe essere disponibile per affrontare una nuova storia, ma se abbiamo molte storie In Test, è meglio che ti aiutino nelle storie esistenti.

In primo luogo, riconoscere che stime accurate sono impossibili in tali circostanze. Non stressarti se sbagli. Tuttavia, hai ancora bisogno di un'idea ruvida per pianificare, e in realtà l'unico modo per spiegare la completa incertezza è aggiungere altri punti della storia alla tua stima. Se non sai se è un 5 o un 13, usa il 13.

È anche utile rompere le storie il meno possibile. Spesso abbiamo una storia di ricerca / design con l'unico scopo di fare abbastanza lavoro per avere una migliore idea di come fare la funzione, quindi la stessa storia caratteristica va in uno sprint successivo. Pensa perché questo funziona. Anche se non hai idea di quanto sarà difficile, solitamente sai con esattezza dall'esperienza passata quanto tempo ci vorrà per scoprirlo.

Ci sono due cose che puoi fare qui.

Prima di tutto hai una sorta di scrum master il cui ruolo è monitorare la discussione e dire "Ehi, stai progettando di nuovo" quando sei. È più difficile di quanto sembri, ruotare le persone in esso giorno per giorno e inizialmente fare in modo che tutti siano i supervisori della mischia, in modo che chiunque possa rimediarci.

In secondo luogo, se stai progettando durante la pianificazione dello sprint devi essere in grado di distinguere tra non sapere abbastanza per effettuare una chiamata sulla durata di un compito, o se stai solo progettando perché è più divertente.

Ancora una volta, il mischia dovrebbe entrare e dirti di mettere l'oggetto in attesa fino a quando non ne sai abbastanza per programmarlo, o di smettere di progettare e rispondere alla domanda originale (Quanto tempo ci vorrà).

Quindi, se stai pianificando sprint, è logico avere uno sponsor aziendale lì per esaminare l'arretrato con te e dare priorità a ciò che vogliono vedere fatto prima. Se lo fai, scoprirai che è più difficile da progettare durante la sessione perché diventeranno irrequieti e alla fine non vorranno venire.

Abbiamo operato sulla base della stima della storia "a freddo" durante la pianificazione dello sprint con solo alcune discussioni limitate. Le stime sono davvero alquanto imprecise nonostante l'istituzione di team con un focus abbastanza ristretto ... principalmente a causa dell'esistenza di un sacco di codice legacy non documentato e non commentato, senza alcuna reale idea di ciò che dovrebbe effettivamente accadere e un personale che è ampiamente cambiato da quando è stato scritto l'originale.

Quello che stiamo provando ora è trascorrere un po 'di tempo prima di pianificare l'investigazione di ciascuna storia - e qui solo uno sviluppatore indagherà su una storia ... Speriamo che questo significhi che lo sviluppatore che ha investigato sarà in grado di fornire alcuni chiarimenti e intuizione per aiutare la stima. Finora questo ha aiutato nelle occasioni in cui è stato provato.

Devo ancora essere convinto che l'indagine aggiuntiva rende le stime abbastanza accurate per giustificare il costo, ma lo proveremo per alcuni sprint.