Scrum: Va bene che il design / UX della user story avvenga nello stesso sprint dell'implementazione

how do you handle dependencies in sprint planning?

Idealmente, le dipendenze non di sviluppo vengono gestite prima della pianificazione sprint, in modo da avere una buona definizione dell'elemento del backlog per stimare lo sforzo.

Ma, se quello fosse lo "sprint" per te "solo lo sviluppo, allora questo sarebbe stato probabilmente solo lo sviluppo per te in questo sprint, quindi dovresti davvero aver aumentato la tua stima lì e poi nelle prossime attività che sono in un simile stato. Questo non è vendicativo, e sarebbe un errore lasciarlo venire come tale.

Quello che fa è mostrare l'incertezza della stima senza un progetto relativamente solido su cui stimare. Forse, questo incoraggerà i tuoi manager ad assicurarsi che un articolo del backlog del prodotto sia definito correttamente; ma nel peggiore dei casi ti coprirà le spalle. Nessuno si lamenta quando un lavoro entra in sotto budget.

Tuttavia, non l'hai fatto, e ora la tua domanda è ...

how should I now approach the sprint?

L'intero scopo di Scrum come strumento di gestione del progetto è identificare tempestivamente i problemi, cosa che hai fatto. Segnalalo alla tua gestione, lascia che decidano cosa fare con lo sprint. Se provano a biasimarti, sii umile e chiedi come ti suggeriscono di avvicinarti a situazioni simili in futuro, per evitare lo stesso problema, anche se non credi veramente che sia giusto.

Alla fine della giornata, questi sono problemi di gestione dei progetti e se provi a risolverli all'interno della tua stessa bolla, ti stai preparando a fallire. E quando lo fai, sarai arrabbiato perché ti cadrà, non nei manager che non sono riusciti a risolvere il problema quando lo hai segnalato.

Innanzitutto, c'è una grande differenza tra le dipendenze tra storie / compiti e l'incertezza nello scopo / sforzo di una storia / attività.

dipendenze sono gestite dando alla task / storia dipendente una priorità inferiore rispetto all'attività / storia da cui dipende e possibilmente un'annotazione che non può iniziare prima che l'altra attività / storia sia fatta.

L'incertezza dovrebbe essere affrontata nella riunione di pianificazione chiarendo il lavoro che deve essere fatto sulla storia. Se non è possibile rimuovere abbastanza incertezza, la storia probabilmente non soddisfa la tua "Definizione di Pronto " e non dovrebbe essere accettato nello sprint.
Se, per qualche motivo, la storia ha davvero bisogno di andare nello sprint, la tua unica opzione è di aggiungere un buffer di rischio alla stima.

Per lo sprint attuale, se non riesci a lavorare su una storia, basta segnalarla nella prossima riunione giornaliera ed eseguire qualsiasi lavoro possibile per raggiungere l'obiettivo generale di sprint del team. Potresti anche annotare la storia come bloccata e con cosa.
Dopo l'avvio di uno sprint, è in linea di principio impossibile aggiungere nuovi compiti allo sprint.
Inoltre, se un'attività si rivela più utile del previsto, non modifichi la stima, ma riporta fedelmente i progressi e lo sforzo residuo sull'attività.

Alla fine, in Scrum, è la squadra che promette di offrire qualcosa. Se questa promessa non può essere fatta, allora è un fallimento dell'intera squadra, mai di un individuo all'interno del team.

During sprint planning I had to take a wild guess as to how long this undefined user story would take.

Questo è l'errore che hai fatto. Nessuno può forzare il team ad accettare un'attività nello sprint e il tuo compito è dichiarare che l'attività non può essere stimata e accettata nello sprint a meno che non ci sia almeno un wireframe (per esempio). Sembra che il tuo scrum master sia in realtà un project manager, il che peggiora solo le cose.

Come affrontare tale compito se è necessario eseguirlo nello sprint (per validi motivi commerciali)? Bene, prima devi impostare la scadenza per il design, dopodiché non sarai in grado di implementarlo. Ad esempio: la storia è accettata, ma il design dovrebbe essere consegnato entro la prima settimana e implementato entro il secondo. Successivamente, devi lavorare a stretto contatto con il progettista per assicurarti che possa essere implementato nello sprint. Scrum assume un team interfunzionale e spetta a te organizzare il tuo lavoro con il designer. Detto questo, se si accetta l'attività nello sprint, che spetta al team decidere, spetta al team gestire il lavoro in modo che sia completato nello sprint e gestire i rischi associati. Non dovresti aspettare che un altro finisca il suo lavoro per portare a termine il tuo lavoro. È possibile che tu stia per rivelare una maggiore disfunzione nella tua organizzazione.

Le attività sul design sono espresse come storie e quali sono le definizioni del tuo team di

• una storia è pronta
• una storia è fatta

Ogni storia dovrebbe avere i suoi requisiti e le sue condizioni di accettazione, ma penso che sia una buona pratica avere un insieme di regole applicabili a tutte le storie. Ad esempio, una storia è pronta se (e solo se!): Gli studi di architettura end-to-end sono finiti, il design è disponibile, la storia è stata stimata dal team. Le condizioni minime di accettazione potrebbero essere: il test automatico è fatto, OK ed è stato integrato nella prova, la revisione del codice è stata fatta.

Se una storia non è pronta, non incorporarla nello sprint. Se le condizioni di accettazione non sono soddisfatte, allora non è finita.

Nel tuo caso, il team potrebbe decidere che per essere pronto, una storia di sviluppo deve avere un design completo (almeno un wireframe, adattarlo alla tua realtà). In tal caso, non è possibile gestire la progettazione e lo sviluppo nello stesso sprint. Il team potrebbe anche decidere che una versione di UX / design dovrebbe produrre almeno un progetto wireframe. Se non è il caso, quindi la storia non è accettata e quindi le storie a seconda di esso non possono essere avviate.

Dovresti convincere facilmente i tuoi dirigenti che avere regole forti per essere pronte è una buona cosa: rivalutare la complessità durante lo sprint è una cattiva pratica. Significa che la velocità della squadra è incerta e che, in quanto dirigenti, hanno una cattiva visione del lavoro della squadra e del futuro.

Uno Sprint di solito inizia quando la storia è chiara - in questa fase il Product Backlog è stabilito e con priorità. Se hai iniziato senza avere il design di quello che avrebbe dovuto essere chiaro, cosa si può fare senza il design e cosa no ...

Se devi improvvisare mentre il design sta "urtando" tra il cliente e l'OP, il tuo PO deve informare il team su eventuali nuove funzionalità non appena appaiono: questo è il significato di "flessibilità" in Scrum - adattare alla situazione in corso. Il team di sviluppo, lo Scrum Master e il proprietario del prodotto devono comunicare in modo permanente, altrimenti non c'è alcuna reazione in tempo reale ai cambiamenti.

Qualche altro allenamento non può nuocere ... Forse lavorare con il designer sarebbe un'opportunità per te per acquisire alcune nuove competenze UX? ... che sta osservando il bicchiere mezzo pieno anziché mezzo vuoto:))