Che cosa dovrebbe contenere una corretta definizione Ready for Sprint?

Dovrebbe contenere abbastanza informazioni che, alla fine dello sprint, l'accettazione non sarà un problema.

A volte una singola frase è abbastanza buona.

Molto spesso, alcuni membri del team vorranno ulteriori informazioni / requisiti scritti per assicurarsi che nessuno cambi idea e ricordi tutto ciò che è stato concordato.

Qualsiasi cosa scritta dovrebbe essere il più obiettiva / verificabile possibile. Mi piacciono molto i formati "dato / quando / poi" e "come ... io ... così ...", in quanto trasmettono molte informazioni e requisiti verificabili in una forma compatta.

Ho visto un paio di tentativi di definire "regole" o porte per le diverse fasi del ciclo di vita di una storia (pronto per lo sprint, accettato ...) - e nella mia esperienza le regole da sole non funzionano bene. È molto facile finire con un elenco troppo esaustivo di cose che una storia deve contenere per essere presa in considerazione (caso d'uso, piano di test, modelli di prova, criteri di accettazione, documentazione, ecc.). È molto difficile garantire che tali elementi siano "buoni". E in molti casi (storie semplici con un sacco di contesto condiviso o contenuti non sorprendenti), mock, piani di test e dettagli sono una perdita di tempo.

Un esempio recente: incoraggiando "come X voglio Y", ho finito con "Come amministratore, mi aspetto che la riservatezza e l'integrità dei dati siano mantenute nella piattaforma". Soddisfa le linee guida, ma è completamente inutile nel dire allo sviluppatore ciò di cui hanno bisogno per consegnare / testare / documentare.

Non penso che tu possa sfuggire dall'avere una buona comunicazione tra PO e dev, e una buona sensazione di ciò che ogni parte penserà è abbastanza buona.

Una storia è "pronta per lo sprint" quando:

• contiene requisiti verificabili e
• ritieni che corrisponda a ciò che il cliente desidera.

Dovresti anche provare a lavorare con il tuo proprietario per aumentare il tempo che possono dedicare a lavorare con te, e trovare modi in cui possono fare un po 'di manutenzione del backlog da soli, se non possono già farlo. Il modo migliore per ottenere un maggiore coinvolgimento sta per fornire qualità con il livello attuale di interazione e spiegare che un ulteriore coinvolgimento può migliorare ulteriormente i risultati.

Penso che la definizione di ready sia piuttosto auto-esplicativa e che non valga davvero la pena di definire esplicitamente.

Se l'ordine di acquisto scompare fino alla fine dello sprint (che può accadere) e il team costruisce ciò che la trama dice, c'è un modo in cui il Product Owner può dire "Questo non è quello che abbiamo concordato"? In caso contrario, è pronto.

A seconda del coinvolgimento del PO nello sprint e del tipo di trama, questo può essere molto dettagliato o molto semplice.