Scrum: come devono essere registrate le conversazioni con il proprietario del prodotto?

Innanzitutto, il tuo processo dovrebbe essere adattato a ciò che ritieni che funzioni meglio per te. Detto questo, penso che ci siano alcune linee guida generali che potrebbero aiutare:

• Non dovresti coinvolgere lo Scrum Master nel processo di chiarire i requisiti con il PO. Introduce una dipendenza e potresti essere bloccato se è occupato. Inoltre, rende la comunicazione con il PO passare attraverso un ulteriore livello, che è una ricetta per equivoci.
• Se hai compiti con pochi dettagli, dovrai sincronizzarti con il tuo PO più spesso, il che potrebbe diventare un impedimento se non è abbastanza disponibile. Quindi devi adeguare di conseguenza quel livello.
• La comunicazione funziona meglio quando si ha un rapido riscontro. Quindi di persona è meglio della chat, che è meglio della posta elettronica. Tuttavia, una volta raggiunta una conclusione, dovresti documentarla in qualche modo in JIRA o altrove. Altrimenti, altri membri della squadra potrebbero non sapere cosa avete discusso e potrebbero chiedere di nuovo le stesse domande. Inoltre, quella potrebbe essere l'unica documentazione che possiedi riguardo a quella particolare decisione.

Non si registra in qualsiasi momento con il proprietario del prodotto e non si passa attraverso lo scrum master. Questo è un mucchio di spese generali che semplicemente non ne vale la pena. Ricorda la primissima affermazione nel manifesto agile:

Individuals and interactions over processes and tools

Parla con il proprietario del prodotto. Le conversazioni fanno parte del processo di sviluppo del software proprio come la digitazione sulla tastiera. Se non si registra quante ore si digita, non è necessario registrare quante ore si interagisce con gli altri.

Se sei uno sviluppatore, assicurati di includere qualcuno del QA nella conversazione se è più di una semplice domanda. E se sei in QA, porta con te uno sviluppatore.

Dopo la conversazione, assicurati che le decisioni siano state eliminate. Una breve nota in un biglietto JIRA potrebbe essere sufficiente, o potresti aver bisogno di più criteri di accettazione. Oppure, forse basta parlare con gli altri compagni di squadra in modo che tutti siano sulla stessa pagina.

Camma del corpo del dipendente. È l'unico modo per essere sicuri

Seriamenteperò,seundevhaunadomandasuunticket,dovrebbeesseresollevatonellamischiagiornalieracomeunImpedimenterispostodalProductOwner(chepartecipaallamischiaperquestoscopo)

SeilPOnonèingradodirisolvereimmediatamenteladomanda,"controlla il documento X23!", "oh questo è sbagliato dovrebbe essere Q", quindi dovrebbero seguire la mischia giornaliera.

Se viene trovata la risposta, il ticket dovrebbe essere aggiornato con le informazioni.

Se la risposta espande l'ambito del ticket, il nuovo ambito deve essere inserito nel backlog, non nello sprint corrente.

Almeno questa è la risposta Scrum.

Qualcosa di cui sono rimasto sorpreso quando utilizza effettivamente Scrum come definito è la quantità di attività formali che ci sono. Uno degli articoli è chiamato "Backlog Grooming", che è uno dei luoghi in cui si suppone che i requisiti siano maturati con il cliente.

L'idea è che nel grooming del backlog, tu stia definendo cosa significa essere fatto e comprendendo ciò che il cliente vuole davvero. Puoi fare dei tagli iniziali alla stima, ma più che probabile che le storie nel backlog dovranno essere suddivise in storie più piccole - quelle che possono essere fatte in 1-2 giorni. L'effetto netto è che gli elementi nella parte superiore del backlog sono definiti meglio e gli elementi nella parte inferiore del backlog sono solo idee.

"Sprint Planning" è il luogo in cui decidi effettivamente quali elementi del backlog andare al prossimo sprint. Il cliente è lì per il primo turno a decidere la priorità e rispondere a tutte le domande che sono ancora lì. Nel turno successivo, il cliente non è presente, ma vicino se ci sono domande specifiche che devono essere poste. Ciò consente agli sviluppatori di diventare più tecnici.

Una cosa che Scrum non gestisce bene è lo scenario in cui lo stesso team gestisce il supporto delle operazioni e lo sviluppo. Un approccio strettamente correlato è chiamato "Kanban" che funziona molto bene per le operazioni.

La più grande differenza tra Kanban e Scrum è che non esiste un vero evento "Sprint Planning". Il grooming del backlog si comporta ancora come in Scrum, ma gli sviluppatori partono dal backlog per fare il lavoro. Ciò significa che anche il grooming del backlog deve dare la priorità al backlog.

Se provi a fare un approccio ibrido, tieni le tue sprint intenzionalmente inclinate. È necessario accumulare spazio per gestire ticket di supporto ad alta priorità, ma continuare a completare il lavoro da te sottoscritto. Se si termina il lavoro designato, si estrae dalla parte superiore degli elementi del backlog che è possibile completare e dimostrare prima della fine dello sprint.