Incremento del prodotto potenzialmente spedibile - cosa succede se agli utenti non piace l'ultimo incremento?

I tuoi sprint sono troppo grandi o troppo complessi. I tuoi sprint stanno fallendo un test chiave, mettendo un sacco di lavoro in pericolo. Credo che un rischio (l'utente non gradisca un'implementazione) non sia gestito in modo completo o corretto, causando un ampio lavoro di rilavorazione. Lo stile di gestione del progetto del tuo team è in errore e devi pianificare gli sprint di conseguenza.

I mockup di carta o schermo, accompagnati da un sacco di handwaving, sono molto meno costosi del codice da produrre (presumo: si potrebbe invece avere una struttura di derisione UI killer). Una procedura dettagliata o un gioco di ruolo con soggetti di prova appropriati richiede uno sforzo enormemente inferiore rispetto alla creazione e alla messa a punto di un sistema per la distribuzione. Poiché sai già che l'accettazione da parte dell'utente è ad alto rischio e che probabilmente non riuscirai a farlo bene la prima volta, puoi pianificare più iterazioni all'interno dello sprint corrente per ottenere il set di funzionalità giusto.

Dato che uno sprint non dovrebbe avere elementi consegnabili che dipendono da elementi precedenti nello sprint, non si dovrebbe pianificare di fornire l'interfaccia utente / elementi della feature che si decidono durante lo sprint corrente. Invece, i risultati dei test informano la pianificazione e lo sviluppo dello sprint seguente.

Secondo la mia esperienza, non è irragionevole per uno sprint includere, diciamo, un) codice e finitura per caratteristiche hard-and-fast, b) picchi tecnologici per sprint indefinitamente in futuro, e c) UI & funzionalità test per sprint nel prossimo futuro. Ciò ti consente di gestire le cose ad alto rischio continuando a fornire un codice solido e accettabile con tutta la documentazione appropriata, ecc., Che accompagna una versione del prodotto.

Nel mio ultimo progetto, abbiamo avuto uno sprint costruito con un mix di a) una descrizione di un paragrafo di una feature o elemento UI per la revisione da parte del gruppo di utenti, b) una schermata dettagliata e una sessione a mano libera, c) un prototipo pronto per il test di una funzione da uno sprint precedente, e d) una funzione di test di accettazione finale che è stata presentata per la prima volta due sprint.

Scrum afferma che lo scopo di uno Sprint è di produrre un incremento di prodotto potenzialmente rilasciabile. Nella situazione che descrivi, dove gli utenti non apprezzano ciò che il team ha prodotto, cerca di capire perché. Ispezionare il ragionamento e adattarsi di conseguenza.

La grande novità di Scrum è che ora trovi questi problemi, alla fine di uno Sprint e non alla fine di un progetto di sviluppo di 18 mesi.

Potresti scoprire che c'è un valore nel coinvolgere maggiormente il Product Owner con gli stakeholder per capire meglio i loro desideri e le loro motivazioni. Questo, a sua volta, aiuta a ordinare gli articoli sul Product Backlog in modo appropriato e potresti scoprire di essere maggiormente in grado di deliziare i tuoi stakeholder alla prossima Sprint Review.

È responsabilità del proprietario del prodotto - creare un prodotto che soddisfi le esigenze degli utenti.

Quindi potresti chiederti come il proprietario del tuo prodotto ha scritto le storie degli utenti - non le ha controllate con gli utenti finali? Non ha creato dei prototipi di schermate per valutarli? Non ha raccolto i loro bisogni?

Se agli utenti non piace quello che hai fatto, il Product Owner deve scoprire cosa deve cambiare e come, e quindi puoi apportare tali modifiche. Se necessario (ma improbabile direi), puoi tornare alla versione precedente e creare da lì.

Sembra che tu debba impegnarti di più con il tuo cliente.

Forse ci hai già provato e non si impegneranno perché sono impegnati con quello che vedono come il loro "vero lavoro". Se è così, a un livello di gestione più elevato, l'IT deve ottenere un riscatto dai clienti per essere più coinvolto nel progetto.

Le fasi iniziali di prototipazione potrebbero aiutare.

In qualche modo renderli consapevoli del costo potrebbe essere d'aiuto, anche se il binning dice che 2 settimane o il lavoro dovrebbero essere un'indicazione sufficiente. Lo spostamento delle date di spedizione o delle funzionalità di taglio dalle versioni future potrebbe concentrarsi.