Scrum: quanto può il Product Owner scuotere il Product Backlog?

Sembra che l'OP stia semplicemente facendo il suo lavoro. È loro compito conoscere le esigenze del cliente e bilanciare quelle con le esigenze dell'azienda. Sono quelli che decidono ciò che l'azienda alla fine venderà. Se passano dalle automobili alle mazze da baseball, presumibilmente è perché hanno deciso che i pipistrelli sono più importanti. Se sono più importanti, perché vuoi continuare a costruire un'automobile?

Se la squadra è infastidita da questo, parla con il PO e comunica loro le tue preoccupazioni. Di nuovo, stanno solo facendo il loro lavoro, ma dovrebbero conoscere l'effetto che questo abbandono ha sul team di sviluppo. È difficile concentrarsi su un prodotto quando cambi continuamente prodotti avanti e indietro.

> how much can the Product Owner really shake up the Product Backlog?

È compito del Product Owner di "scuotere il Product Backlog".

In Scrum è il lavoro del proprietario del prodotto per classificare e assegnare la priorità alle funzionalità in Product_Backlog .

proprietario del prodotto e team concordano cosa implementare nel prossimo sprint e inserire queste funzionalità nel Sprint_Backlog

Come sviluppatore devi discutere se hai bisogno di caratteristiche tecniche nel registro sprint che il proprietario del prodotto non vede.

In Scrum tradizionale, il Product Owner è la persona che possiede il Product Backlog. Questa persona è responsabile per l'aggiunta o la rimozione di storie come appropriato e per garantire che l'elenco abbia la priorità in base alle esigenze degli stakeholder. Tuttavia, il team di sviluppo ha la responsabilità di garantire che gli articoli del Product Backlog che vengono aggiunti siano capiti e sufficientemente validi (completi, chiari, verificabili, fattibili, ecc.) Da stimare e consegnare quando arrivano in uno sprint futuro.

Dal tuo punto di vista sul team di sviluppo, non dovresti affidarti al backlog del prodotto. Tutte le tue azioni - l'elaborazione dei requisiti, l'architettura e la progettazione, l'implementazione e i test devono essere completamente basati sullo Sprint Backlog. Questo è ciò che viene corretto per uno Sprint particolare e le modifiche allo Sprint Backlog dovrebbero essere ridotte al minimo.

Ricorda che il Product Owner è la voce dello stakeholder per il team di sviluppo. Sono quelli che capiscono quali sono le esigenze aziendali per il sistema e quali funzionalità o caratteristiche potrebbero avere l'impatto maggiore.

I cartelli di avvertimento a cui prestare attenzione sono il proprietario del prodotto che tenta di modificare lo Sprint Backlog o di avere un proprietario del prodotto che non è in contatto con le esigenze dell'azienda o della base di utenti.

how much can the Product Owner really shake up the Product Backlog?

Per quanto gli piace.
È il lavoro "Product Owners" a rappresentare l'utente e ottenere ciò che vogliono.

Is it really fair game to ignore what's already in the backlog and keep on shoving new stories at the top?

Certo.
Se le vecchie storie non sono più rilevanti per l'utente, perché costruirle. Vuoi solo costruire ciò che è importante per l'utente. Ma fa attenzione. Si suppone che una storia sia un'azione dell'utente. Dovresti essere in grado di descrivere una storia in termini di un'azione eseguita da un utente (nessun dettaglio tecnico).

I've tried to argue that this is hogwash

È il lavoro dello "Scrum Master" per proteggere gli sviluppatori dal cambiamento irriducibile.
È compito dello "Scrum Master" scegliere ciò che rende lo sprint e proteggere gli sviluppatori dal "Product Owner" e assicurarsi che la parte tecnica del progetto funzioni. Ciò significa che dovrebbe scegliere oggetti per formare prima l'architettura. Dovrebbe provare a fornire alcune storie di utenti ma quelle che hanno senso (cercando di rispettare la priorità dei Proprietari di Prodotto ma non ha bisogno di attenersi ad essa al 100% se ciò non ha senso tecnologico).

Note: As pointed out below my definition of "Scrum Master" here may not be fully standard. I was simply using it to point out that it is not the Job of the PO to pick tasks for the scrum backlog as this is a technical in nature (and the PO being a chicken has no voice in the sprint planning). It is the job of the team to pick what goes in the sprint backlog as they are technically inclined and understand how components will interact. They will be heavily influenced by the priority in the product backlog but that is not there only consideration they use when making technical decisions. My use of the term "Scrum Master" is heavily influenced by my experience where the "Scrum Master" is usually the technical or team lead (usually a senior dev with the clout/fortitude to stand up to management who tend to be pushy when they can get away with it) this of course is not required by scrum.

-

but I often hear counter-arguments such as "adapting to frequently changing business needs," "we're moving so fast - we're super agile" and I don't know what to say to those arguments,

Questi sono buoni argomenti. Ma assicurati

1. Stai parlando di storie vere
2. La tua architettura ha la priorità sull'interfaccia utente

although I feel it is not how Scrum was meant to be.

Scrum ha lo scopo di permetterti di reagire rapidamente.
Ma durante uno sprint non ci dovrebbero essere cambiamenti nello sprint backlog. E assicurati che i tuoi sprint siano di una lunghezza ragionevole: da 3 a 4 settimane. Questo dovrebbe darti la possibilità di finire una piccola storia ragionevole o costruire le basi per una grande storia.

Ottime risposte qui e sono d'accordo che è compito dell'OP fare ciò in modo da determinare il miglior ROI possibile per il prodotto. Lui / lei farebbe la cosa sbagliata costruendo PBI meno preziosi.

Tuttavia ci sono alcune regole fondamentali.

• L'ordine di acquisto non può cambiare lo sprint corrente spostando gli elementi dentro e fuori per capriccio.

• Quando l'ordine di acquisto aggiunge un nuovo elemento, il team deve stimarlo e l'ordine di acquisto deve rispettare tale stima

• L'ordine di acquisto è quindi responsabile della gestione del tempo, del budget e dell'ambito (il triangolo magico). Ad esempio, se aggiungono nuovi elementi devono ottenere più budget o rimuovere un oggetto con valore inferiore equivalente.

• L'ordine di acquisto è responsabile per assicurarsi che gli elementi dispongano di dettagli sufficienti in modo che il team possa scegliere 1 su pianificazione sprint. Dovrebbe avere abbastanza informazioni che il team può fare domande di chiarimento minori. Questa è spesso una disfunzione in molte squadre dove si spende molto tempo a discutere di quale sia il requisito, invece di piccoli chiarimenti.

• L'OP nelle sessioni di toelettatura dovrebbe consultare il team e dare ascolto ai propri consigli su eventuali sfide potenziali con nuovi requisiti, impatti o dipendenze. Questo dovrebbe aiutarlo / a prendere decisioni migliori.

La responsabilità e la responsabilità del team sono la definizione di ciò che viene costruito o quello di come dovrebbe essere costruito? La linea di fondo non è la decisione o il rischio da prendere e il team dovrebbe concentrarsi su consegna di articoli di qualità indipendentemente da cosa siano.

Infine, utilizza le retrospettive per eliminare eventuali dubbi che potresti avere