La parte di Iteration Planning della Iteration stessa?

Lo Sprint è il contenitore per tutto il lavoro svolto nello sprint, tra cui Planning, Sprint Review e Retrospective e tutto il lavoro in mezzo.

Niente ti impedisce di regolare Burndown per iniziare il giorno 2 e targetizzare il giorno prima della revisione dello sprint.

Spritn Burndown non è mai stato pensato per essere seguito lungo la linea ideale. La linea ideale aiuta il team a valutare se sono in anticipo o in ritardo rispetto al loro piano corrente, in modo che possano agire e adattare il piano.

Lo sviluppo del software tende a essere complesso e può essere fangoso, i team onesti raramente seguiranno la linea ideale. Trovano un nuovo lavoro lungo il percorso, trovano alternative che potrebbero essere migliori, ricevono feedback o trovano nuovi casi d'angolo precedentemente non pianificati. Quando il burndown riflette continuamente questi cambiamenti, il team può utilizzarlo per prendere decisioni informate.

PS: Grooming è stato rinominato in Affinamento . La ragione di questo ha a che fare con la connotazione negativa associata alla parola Grooming. Qualcosa che ha a che fare con ragazzini e vecchi uomini cattivi (in generale) e webcam.

In Scrum, come definito dalla Guida Scrum , lo Sprint include "Sprint Planning, Daily Scrum, il sviluppo, Sprint Review e Sprint Retrospective ". Quindi la risposta alla tua domanda dalla prospettiva di Scrum è sì, la pianificazione della tua iterazione (e anche la revisione della tua iterazione) fanno parte dell'iterazione stessa.

Tuttavia, Scrum non è l'unico modo per essere agili. Solo perché Scrum dice che qualcosa non lo rende così. Puoi scegliere di basare i tuoi Sprint in tempo escludendo le tue attività di pianificazione e retrospettiva.

Tuttavia, penso che le tue preoccupazioni riguardo al non aver mai raggiunto l'ideale non siano una grande preoccupazione. La linea ideale è proprio quella - ideale. Assume un lavoro costante e costante. È un indicatore su come stai andando a completare i tuoi punti storia contro il tuo timebox iterativo. Probabilmente non seguirai mai esattamente la tua linea ideale, ma puoi usarla per segnalare tempestivamente alle parti interessate se i tuoi impegni sono a rischio.

What I don't like in the mind set of "iteration is everything" is the aspect of planning the thing what is already started and where I'm already in and changing things where it is said it should be stable (for the iteration). The iteration backlog should not be changed during the iteration/sprint!? How can this be done if the planning is inside and I need to add user stories and estimate them with the team. From my perspective the iteration backlog for the team is fixed from the time point starting the functional progress/work of implementing the user stories.

Sembra che tu stia provando ad applicare tecniche tradizionali, basate su piani, a metodi agili. Non funzionerà.

Prima di tutto, non è garantito che le iterazioni siano stabili. Idealmente, dovrebbero essere per lo più stabili. Se stai eseguendo da Scrum per scrum guide, riconosce anche il fatto che il team di sviluppo può modificare Sprint Backlog.

Secondo, Sprint Planning non è un piano dettagliato. Affronta solo due problemi: ciò che il team può fornire nello Sprint e che lavoro dovrà essere svolto per fornire. Il Product Owner ha in genere un obiettivo in mente per raggiungere e collaborare con il team di sviluppo per ordinare il Product Backlog sulla base di tale obiettivo e di eventuali considerazioni tecniche. Il team di sviluppo e il proprietario del prodotto collaborano continuamente alla definizione dei requisiti e delle attività necessarie per implementare tali requisiti.

Se sei abituato a un lavoro più fisso, a risposte più calcolate, l'agilità sarà impegnativa. I metodi agili sono pensati per essere reattivi e guidati dai dati, ma anche collaborativi. Non avrai piani e azioni fermi, molti dei quali provengono dall'esperienza e ciò che ognuno sente è la cosa giusta da fare.

La pianificazione è parte dello sprint.

Sembra che tu stia guardando uno sprint come se fosse un intervallo di tempo dedicato alla programmazione e al test. Non è quello che è uno sprint. Uno sprint è un blocco di tempo riservato a un team di persone che lavorano insieme su un problema. Parte di quel lavoro è la codifica, ma parte di quel lavoro è la pianificazione, parte è la demo e la retrospettiva, parte di ciò sta andando a casa e dormendo.

Per quanto riguarda il burndown ... è importante ricordare che la linea ideale di un grafico di burndown è un indicatore piuttosto che un obiettivo , quindi il fatto che tu possa non raggiungerlo mai non è un problema, a meno che alla fine dello sprint non si abbia ancora del lavoro da fare.

Il suo unico scopo è aiutarti a vedere se è probabile che finisca in tempo o meno. Questa informazione è praticamente inutile il primo o il secondo giorno dello sprint perché non hai lavorato molto, quindi non importa quanto la pianificazione influenzi il grafico. È (probabilmente) completamente inutile anche l'ultimo paio di giorni dello sprint, poiché a quel punto dovresti già sapere se hai intenzione di finire o meno.

Quindi, il grafico di burndown è davvero utile solo per la parte centrale dello sprint. Se ciò è problematico, puoi sicuramente disegnare un grafico di burndown che inizia dopo la pianificazione e prima della demo e delle retrospettive, ma stai rendendo il processo più complesso di quanto dovrebbe essere.