Scrum: L'OP dovrebbe accettare uno sprint nella riunione della Sprint Review? Se no, qual è la migliore pratica?

La migliore pratica è per il Product Owner di impegnarsi attivamente con il team mentre completano le storie e di fornire feedback e approvazione o note durante lo sprint stesso. Se arrivi al punto in cui stai facendo la tua revisione/demo e l'OP sta vedendo le cose per la prima volta, stai facendo qualcosa di molto sbagliato.

Dovresti completare le storie durante lo sprint - probabilmente non il primo o il secondo giorno, ma il tuo burndown non dovrebbe essere caricato all'indietro. Quando il team arriva al punto in cui pensa di aver "finito" una storia, l'OP dovrebbe essere chiamato per dare un'occhiata, rivedere la storia rispetto ai criteri di accettazione, e dare il suo pollice in su o in giù sul lavoro. Se è accettato, allora è pronto per essere mostrato e rivisto; se non lo è, allora ha bisogno di ulteriore lavoro.

Tenete a mente che la "definizione di fatto" e i "criteri di accettazione" sono due cose completamente diverse. La DoD è una lista di tutte le cose che devono essere fatte per ogni storia perché sia considerata fatta -- questa è di solito la lista della lavanderia delle cose amministrative che i team di sviluppo si assumono: revisione del codice, test unitari funzionanti, deploy su CI senza rotture, ecc. I criteri di accettazione sono specifici per ogni storia e descrivono come l'OP esaminerà la storia e cosa deve effettivamente fare per essere considerata "completa". In un paio dei miei ruoli precedenti, ci riferivamo a qualcosa che gli sviluppatori completavano come "fatto", qualcosa che soddisfaceva i DoD come "fatto-fatto", e qualcosa che otteneva l'approvazione dell'OP come "fatto-fatto-fatto".

Vuoi raggiungere il "fatto-fatto-fatto" il più presto possibile nello sprint per ogni singola storia che ti impegna.