Dividi l'elemento di lavoro in prototipo e elemento di lavoro principale?

Il livello di dettaglio nella riunione di pianificazione dipende molto dalla personalità e dalle competenze del PO.

Prendi l'interfaccia utente come esempio: alcuni proprietari di prodotti hanno forti capacità di UX o usano esperti di UX al di fuori del team. Questi PO vanno meglio con una specifica UX approssimativa alla riunione di pianificazione. In altri casi questa abilità è più presente all'interno del team. Questi team gestiscono il design UX come parte dell'implementazione. Il problema sorge se l'OP ha opinioni forti sull'interfaccia utente, ma non riesce a comunicare in anticipo ciò che vuole. Questo è ingiusto nei confronti della squadra.

In breve, se influisce sull'accettazione di un oggetto di lavoro, l'OP non dovrebbe evitare la domanda durante la pianificazione della riunione.

D'altra parte, non puoi aspettarti che lui abbia tutte le risposte preparate, la squadra deve anche pensare attivamente e dargli alcune opzioni tra cui scegliere.

Un buon modo per avvicinarsi a questo nella riunione di pianificazione, è di formulare domande al PO come "accetteresti la storia se ...".

Torna alle tue domande:

Should the team say no in approving the item unless team understands how the solution will look like?

Sì, se il PO non è in grado di dare chiarezza su ciò che accetterà e quali no.

Should the work item be splitted into research/analysis in which solution prototype will be proposed to the PO? Once the PO will approve the prototype, the main work item will be marked approved.

Se per un determinato elemento di lavoro, tutti sentono che un approccio iterativo sarebbe il migliore ("vediamo come funziona e poi decidi se è necessario un cambiamento"). Quindi è meglio dividerlo in due elementi. Ma non pensare al passaggio 1 come a un prototipo, rendilo "potenzialmente spedibile" in base alle attuali conoscenze del team e dell'OP. L'ordine di acquisto può sempre definire gli elementi di lavoro per migliorarlo in seguito.

Any other suggestion as to how it can be handled in better way?

Alcuni team o PO prepareranno le specifiche UX approssimative (wireframe) prima della riunione di pianificazione: mirare a un fallimento precoce. Quanto basta per essere d'accordo. In modo che quando la squadra si impegna su un oggetto di lavoro, lo scopo è stato chiarito in anticipo.

Un altro modo per farlo è suddividere la sessione in due parti.

Nel primo il Product Owner entra nel livello di dettaglio di cui il team ha bisogno per comprendere i requisiti. Nessuna stima dello sforzo verrà effettuata durante questa parte. Quindi il PO lascia la stanza e il team inizia con il processo di stima che include "come sarà fatto".

Il PO dovrebbe essere disponibile per rispondere alle domande che emergeranno. Questa è una parte importante della pianificazione sprint in cui è possibile includere la pianificazione del poker o qualsiasi altra tecnica di stima. È importante che la pianificazione non duri per sempre e che tu debba avere un orario di fine in cui chiudi la sessione.

Tutto ciò che il team ritiene importante dovrebbe essere discusso durante la sessione di pianificazione. È una buona pratica Se la squadra lascia la stanza e ha molte domande è impossibile essere produttivi. Nel caso ci siano troppi fattori sconosciuti, potresti iniziare un picco per cercare un concetto e / o creare un semplice prototipo. Ma dovrebbe essere l'eccezione e non la regola.

Should the team say no in approving the item unless team understands how the solution will look like?

No, certo che no. Non conoscendo i dettagli di implementazione si lascia il margine di manovra del team nel trovare la soluzione più semplice in seguito. Ciò non significa che la discussione debba essere prevenuta, ma dovrebbe essere certamente limitata.

Supponiamo ad esempio che nella riunione di pianificazione si decida di giocare una storia in un certo modo. La squadra dovrebbe essere costretta a usare quel disegno durante lo sprint? Questo è contrario al manifesto agile .

Should the work item be splitted into research/analysis in which solution prototype will be proposed to the PO? Once the PO will approve the prototype, the main work item will be marked approved.

No, questo non aiuterà il team, perché i prototipi non hanno valore per i tuoi utenti, e quindi dovrebbero avere la priorità più bassa secondo Scrum. Dovresti solo realizzare dei prototipi, se necessario, una volta che ti impegni alla storia, non prima.

Any other suggestion as to how it can be handled in better way?

Ne ho alcuni:

1. Perché il proprietario del tuo prodotto agisce come Scrum Master? I ruoli dovrebbero essere veramente separati , e fare altrimenti è generalmente una Bad Idea ™

2. Perché valuti le tue storie due volte? Questo non dovrebbe accadere davvero. Li valutate una volta, in modo impreciso, per avere un'idea di cosa si adatta in uno sprint. A nessuno dovrebbe interessare oltre quel punto - la misura diventa ciò che effettivamente realizzi. Naturalmente, ci possono essere stime di compiti , ma sono volutamente in un set separato di unità perché non dovrebbero mai essere utilizzate per stimare cosa si adatta in uno sprint, ma solo quanto lavoro è rimasto.

3. Sembra che tu abbia un problema nel collaborare con l'ordine di acquisto durante lo sprint. Ad esempio, si dice che "la squadra lotta durante i primi 2-3 giorni nel fare la ricerca e ottenere l'approvazione del PO per la soluzione". Questo non ha senso per me. L'ordine di acquisto dovrebbe riguardare il risultato finale per l'utente e non essere impegnato in una particolare soluzione. Devono specificare alcuni test di accettazione end-to-end prima della mano, ma tutto ciò che li passa è un gioco leale - qualsiasi altra cosa dovrebbe essere una nuova storia.

4. Il tuo suggerimento di avere un prototipo- > la trama della storia va contro la collaborazione e verso una separazione dei ruoli. Ciò di cui hai veramente bisogno, invece, è che l'OP e il team collaborino durante l'intero sprint e parlino tra loro. Le storie non dovrebbero essere progettate fino a quando non sono state fatte. Quello che chiami "prototipo" dovrebbe essere la storia.

Secondo me il tuo problema è qui:

"A meno che l'analisi non comporti grandi differenze nella stima dello sforzo, al team viene chiesto di completare la funzione."

Un'altra società che vuole "essere agile" per non sprecare tempo nella stima e una definizione più approfondita degli Stati Uniti (e che è del tutto ok), ma non ci sono "abbastanza agili" per capire la differenza tra un stima e un compromesso.

La SM è quella che ha bisogno di spiegarlo alla direzione, e se la situazione in cui la squadra ha bisogno di fare straordinari per le funzionalità complete è la norma sprint dopo lo sprint, la SM deve mettere immediatamente fine a questa assurdità e recuperare un ritmo sostenibile per la squadra.

Avere un passo sostenibile è uno dei valori fondamentali dell'agile, finendo tutti inclusi gli Stati Uniti in uno sprint, ovviamente non lo è. Nel lungo periodo il primo è molto più importante del secondo, la sua chiave per capire questo.