I tentativi di contrattazione sulle stime di Scrum sono parti legittime del processo?

La situazione che descrivi è tossica. Questo tipo di contrattazione ignora la realtà e l'esperienza del team, nasconde intenzionalmente informazioni dal team e dall'organizzazione in generale e impedisce al team di migliorare nel tempo.

Se vuoi il collegamento come autorità, vorrei evidenziare:

Only the Development Team can assess what it can accomplish over the upcoming Sprint.

e

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.

Il proprietario del tuo prodotto potrebbe desiderare che un'attività sia possibile in sole 4 ore. Potrebbe anche essere un obiettivo ragionevole. Una reazione salutare potrebbe essere quella di accettare la stima del team, misurarla se è accurata e chiedere "cosa avremmo bisogno di cambiare per essere in grado di completare questo tipo di attività più rapidamente?" Negoziare la portata del lavoro coinvolto nell'attività potrebbe anche essere ragionevole e evidenziare un'importante differenza nel modo in cui gli sviluppatori e il proprietario del prodotto capiscono che lavoro è a portata di mano. Richiedere che il team modifichi le proprie stime senza nuove informazioni garantisce solo stime inesatte.

Ci sono molte strategie che il team di sviluppo potrebbe usare per provare a cambiare questo modello, ma quando si dà una risposta di esempio di "Non posso spiegarlo al management" sono molto nervoso. Sembra che il proprietario del tuo prodotto non abbia la fiducia della gestione (le stime non accurate che stanno producendo probabilmente non aiutano) e potrebbe non essere disposto a essere trasparente riguardo agli attuali errori del processo.

A mio parere, uno dei più grandi successi di SCRUM è lo sviluppo di story point, con l'espresso esplicito intento di evitare i problemi di negoziazione menzionati qui. L'intero punto dei punti-storia è di evitare una connessione diretta tra un'attività e quanti giorni ci vorrà. Invece, questi due concetti sono collegati dall'idea di velocità.

Se fossi uno sviluppatore, e mi stavo dando da fare per chiamare una storia di 13 punti con una storia di 8 punti, sarei felice di accontentarlo. Le sue capacità di stima stanno avendo un impatto. Semplicemente ridimensionerò tutte le mie difficoltà per combaciare. Alla fine la velocità della squadra diminuirà in termini di punti storia a settimana per soddisfare la volontà della dirigenza di "sottrarre" punti storia. I numeri consegnati alla direzione dovrebbero corrispondere: "Abbiamo ridotto con successo il numero di punti storia di lavoro necessari per raggiungere il traguardo del 50%, tuttavia abbiamo visto una corrispondente diminuzione della velocità del 50%, quindi l'effetto netto è realizzeremo esattamente ciò che avremmo realizzato esattamente nel tempo che ci sarebbe voluto ". Il concetto di velocità esiste per combattere il pio desiderio del management superiore.

Ora ci sono due estremi che penso valga la pena guardare. Uno è un completo fallimento della gestione e l'altro è in realtà una preoccupazione molto valida per la gestione di cui preoccuparsi. Il primo caso è una condanna a morte per SCRUM, quando agli sviluppatori viene detto "non sei abbastanza produttivo, devi produrre più punti storia di valore". Se ciò accade, in realtà non stai utilizzando SCRUM, sei un Cookoo, che ha cacciato SCRUM dal nido e sta cercando di essere nutrito dall'uccellino madre che ritorna al successivo.

Ora c'è un caso in cui ritengo che la gestione dovrebbe essere in grado di impegnarsi in una rotazione del braccio come questa. Dovrebbe essere ragionevole per il cliente dire "Non posso permettermi 50 punti-storia per completare questo compito se la tua velocità è di 20 punti / settimana. Ho bisogno che tu lo realizzi in 30 punti-storia", se quel cliente è disposto rinegoziare il contenuto di tali storie per ridurne il campo d'applicazione del 40%. SCRUM non è un biglietto gratuito per gli sviluppatori per fare quello che vogliono, è uno strumento di comunicazione per aiutarli e la direzione parla apertamente di ciò che deve essere fatto. È anche valido per un cliente mettere lo squeeze sullo sviluppatore e dire "fare il lavoro in 30 punti" se sono disposti ad accettare il rischio intrinseco che il lavoro semplicemente non sarà completato nel tempo. Quando manca la scadenza, se gli sviluppatori possono dire "ti abbiamo dato la nostra migliore stima che diceva che il lavoro non poteva essere fatto in tempo, e hai scelto di continuare sul percorso attuale senza aggiustare", allora è sulla gestione spiegare perché il la scadenza è stata persa. Ho visto questo approccio utilizzato per dare il via a un processo di sviluppo: i manager chiedono più di quello che si può fare, spingono il team a essere il più produttivo possibile e poi accettano tutto ciò che è stato fatto. Penso che ci siano modi migliori per misurare la produttività di una squadra, ma devo ammettere che è un processo che funziona.

Per uno, l'OP non dovrebbe fornire informazioni sulla gestione alla task. Le stime dei compiti sono strettamente a vantaggio della squadra. L'unica cosa che qualcuno al di fuori del team deve sapere è su quali storie stanno lavorando, quali sono i loro valori puntuali e qual è la velocità media della squadra. T

In secondo luogo, a meno che l'ordine di acquisto non sia uno sviluppatore di livello senior con una profonda conoscenza del software, la loro opinione sulle stime del compito non dovrebbe avere molto peso. Gli sviluppatori sono quelli con la conoscenza del sistema e quelli che stanno facendo il lavoro. A meno che non siano tutti freschi di scuola con competenze di stima zero, le loro stime dovrebbero essere escluse.

Questo non vuol dire che a volte le stime non possono essere messe in discussione. Se è così, questo deve accadere in modo positivo. Ad esempio "hai considerato che abbiamo già fatto metà del lavoro per" x "" o "ti sei ricordato di includere il tempo per fare Y?".

Conclusione: gli sviluppatori dovrebbero sentirsi sicuri di fare tutte le stime che vogliono, a patto che facciano un tentativo in buona fede di essere accurati. Se dicono che ci vogliono quattro ore, devi accettarlo.

What do the Scrum guidelines say on this topic, or do they say anything on it?

Non dicono nulla. La stima delle attività non fa parte della mischia. Con la mischia, la stima si ferma ai punti della storia. La stima del compito è semplicemente uno strumento per aiutare le squadre a fare meglio a stimare i punti della storia, assicurandosi che abbiano pensato a tutto il lavoro necessario per completare una storia.

È compito del Scum Master assicurarsi che il processo di mischia sia seguito. Ciò include il fatto che il team non esegue (in modo coerente) l'overcommit sulla quantità di lavoro che possono essere eseguiti in uno sprint.
Da un lato, ciò significa regnare una squadra eccessivamente entusiasta, ma d'altra parte respingere il Product Owner se sta facendo pressione sulla squadra.

Un buon modo per mantenere realistico l'impegno / previsione è guardare le storie effettivamente realizzate negli ultimi sprint. Questo è ciò che il team ha dimostrato di poter realizzare, quindi non c'è motivo di tirare molto più lavoro in uno sprint, in quanto non verrà completato.

Come indicano anche altre risposte, la contrattazione sulle stime fornite dal team è non parte del processo Scrum. Il team è il più familiare con il software, quindi dovrebbero sapere meglio quanto lavoro è.

Ciò che può essere negoziato è lo ambito di una storia. Se il Product Owner ritiene che una storia sia stimata come più grande o più piccola di quanto si possa ragionevolmente prevedere, allora può chiedere un chiarimento al team per vedere se la visione del lavoro che deve essere eseguita coincide tra le parti.
Se la trama è davvero così faticosa, il Product Owner può decidere di suddividerlo in diverse storie più piccole e distribuire la funzionalità su quelle più piccole.

Il team è responsabile della fornitura di qualità e che non dovrebbe mai aprirsi per la contrattazione.

Sì e no.

Sì, il team di sprint dovrebbe negoziare con il proprietario del prodotto su che cosa ottiene nello sprint.

No, il proprietario del prodotto riceve no per quanto tempo impiegano le cose. Sei gli esperti, non loro.

Guarda, non dovresti avere a che fare con quel tipo di spazzatura: il tuo manager o il tuo team leader sono lì per prepararti al successo. Ciò significa trattare con il PM (o il suo capo) in modo che tu abbia successo. Detto questo, non è così difficile.

"No".

Cosa faranno? Scrivi il codice loro stessi?

Permettere questo comportamento è un fallimento dello Scrum Master. Il suo lavoro, in primo luogo, è quello di proteggere la squadra. L'OP, per le ragioni sopra descritte, è miope. Lo Scrum Master dovrebbe intervenire e, in modo positivo, riformulare il contesto della discussione.

Tale pressione, ovviamente, porterà ad una pressione al ribasso sulla velocità, qualcosa che l'OP ha già citato. Se i team non riescono a terminare gli sprint, lo Scrum Master dovrebbe intervenire di nuovo e chiedere perché questo potrebbe essere il caso. In ambienti veramente tossici, i membri del team potrebbero non sentirsi liberi di essere onesti nelle Retrospettive. Ma in quella situazione, lo Scrum Master ha la responsabilità di chiamare un cattivo comportamento e proteggere la squadra.

Se ti trovi in una situazione in cui il tuo Scrum Master non può o non vuole fare queste cose, allora probabilmente hai bisogno di un altro Scrum Master. L'OP sta rispondendo alle pressioni tipiche. La squadra, nella speleologia, risponde anche come fanno spesso gli umani. È compito dello Scrum Master vedere questo per quello che è e fermarlo. La responsabilità dell'OP è qui di portare questo in Retrospective e, se necessario, a lead e manager. Se ancora non lo risolvi, aggiorna il tuo profilo LinkedIn e trova persone migliori con cui lavorare.

Un team di sviluppo prodotto (cioè tutti, dal proprietario del prodotto, agli sviluppatori, ai tester) può seguire il processo agile e ottenere buoni risultati con persone ragionevolmente competenti e aspettative realistiche.

Oppure possono seguire un processo che assomiglia superficialmente al processo agile.

Quel PO probabilmente pensa che otterrà risultati migliori cercando di ottenere stime di tempo inferiore per le attività. Certo che non funziona. Se qualcosa dura tre giorni, mi dai un sacco di soldi e ti darò una stima che posso farlo in un'ora. Ci vorranno ancora tre giorni. Se vieni a gridare contro di me perché non è finito tra un'ora come promesso ci vorranno cinque giorni.

Tutto ciò che ottiene è rompere il processo agile e rinunciare a tutti i risultati positivi che potrebbe ottenere. Il maestro di mischia dovrebbe avere l'esperienza, il potere e il coraggio per impedirlo. Se la gestione fa sì che qualcuno scrum master che non ha esperienza, o non dia al maestro di mischia il potere di prevenirlo, è colpa loro se si rompe agilmente. Se il mischia non ha il coraggio, allora condivide la colpa con il Primo Ministro.

Direi che dipende molto dalla motivazione qui. L'obiettivo generale della stima è quello di farsi un'idea di quanto la squadra può ottenere durante uno sprint determinato, il che consente di prevedere il lavoro futuro in base a tale velocità. Ad esempio, se il team sta completando 30 punti storia per ogni sprint, e ci sono circa 60 punti storia davanti all'Articolo X sul backlog, il Product Owner può quindi ragionevolmente dire che l'Articolo X sarà completo in qualcosa come 6 settimane (basato su un sprint standard di due settimane).

Per rendere questa stima il più accurata possibile, non è raro avere disaccordi sul numero di punti storia di un particolare oggetto. Scrum in realtà lo incoraggia. A volte questo disaccordo può anche essere riscaldato. Tuttavia, l'obiettivo finale dovrebbe essere la stima accurata della complessità del PBI, non deflazionare artificialmente lo sforzo in modo da poter provare a stipare più PBI in una data velocità.

Questo è in realtà il modo in cui la pianificazione del poker funziona, in linea di principio. Ognuno espone la loro stima. Lo Scrum Master, quindi prende la stima alta e bassa e chiede perché il membro del team pensa che dovrebbe essere così alto / basso. Questo dà al team la possibilità di ascoltare prospettive alternative del lavoro in questione e avere una migliore idea di quanto sia effettivamente complesso il compito. Dopo la discussione, tutti gettano nuovamente le loro stime. Questo processo viene sciacquato e ripetuto fino a quando non c'è un consenso generale sulla complessità.

In altre parole, non è sbagliato sfidare la tua stima, dato che lo sfidante ha una logica per cui non sono d'accordo, a parte che vogliono solo abbassarlo. È tua responsabilità, quindi, convincere la tua squadra che la tua stima è corretta, se ritieni che lo sia ancora.