In un processo agile, quanto lavoro deve essere svolto dall'OP su un progetto o funzione prima di presentarlo al team?

Questo scende al livello appropriato di dettaglio.

L'OP e le parti interessate avranno una visione a lungo termine del prodotto rispetto al team di scrum. Mentre una consapevolezza è utile, c'è il pericolo che il team inizi a crollare e progetti di lavoro che non saranno completati per un certo numero di anni (se non del tutto).

Allo stesso modo, se il PO sta andando e progettando tutte queste funzionalità senza sapere quanto tempo sarà richiesto o quanto sia rischiosa (se possibile) una storia / caratteristica / epica, allora non prenderanno una decisione informata quando arriverà per dare la priorità.

Il mio suggerimento sarebbe di usare le tue sessioni di perfezionamento del Backlog per esaminarle. La squadra dovrebbe impiegare un po 'di tempo per assicurarsi di capire il lavoro immediato e prepararsi allo sprint. Dovrebbero abbattere parte del lavoro a medio raggio ad un livello molto più piccolo di dettagli. Poi hanno potuto fare alcune storie base di alcune delle funzionalità a lungo raggio delle OP.

Ciò garantisce che abbiano consapevolezza delle funzionalità e abbiano la possibilità di porre domande e offrire feedback, inoltre assicura che l'OP riceva dal team le informazioni di cui ha bisogno.

Il trucco ovviamente sarà quello di assicurarti di trascorrere il giusto equilibrio di tempo concentrandoti sulle storie giuste!

Penso che il PO abbia ragione. Le specifiche e il design approssimativo dovrebbero essere creati prima che il team ottenga il compito. Altrimenti, come puoi stimare l'attività?

Tuttavia! Questo approccio porta il team di sviluppo a diventare un "negozio" che sforna i prodotti secondo le specifiche. Bene in teoria, ma in pratica come probabilmente sapete, ciò che viene specificato non è sempre la soluzione migliore.

Una volta che hai prodotto qualcosa di specifico, ma non di cui hai bisogno, un paio di volte il PO arriverà al tuo modo di pensare e ti chiederà "qual è il modo più veloce per ottenerlo" o "C'è un buon modo? fare quello?" domande di stile prima di specificare le cose.

Naturalmente questo approccio ha anche degli svantaggi. Può portare a ritardi in cui le attività non sono completamente chiarite in anticipo, codice hacky in cui vengono raggiunte soluzioni di compromesso e scadenze mancate in cui i requisiti aggiuntivi sono realizzati solo alla fine del progetto.

È facile per un team di sviluppo produrre rapidamente codice specifico. E le pratiche degli aglie possono funzionare bene per questo. Ma il duro è sapere quali dovrebbero essere le specifiche.

Se il cliente sta scrivendo le specifiche, in un certo senso non ti interessa se ottengono il risultato giusto. Ma quando l'azienda sta definendo i propri requisiti ognuno subisce la perdita se viene commesso un errore.