Primo: dai un'occhiata a questo simpatico talk , Florian Haas ha dato al FROSCON (GER). Riguarda l'impossibilità pratica di fare scrum.

Le buone notizie : poiché scrum è impossibile da implementare, sei libero di fare ciò che vuoi.

Le cattive notizie : non chiamare quella mischia.

Questo ti libera dalla domanda: »Sto facendo scrum vero?« (Risposta: No non lo fai ) e potresti passare alle domande pratiche della vita, quella questione.

We do not have a UI/UX designer and the developers work the UI/UX with the product owner

Questa è una situazione non insolita. Ma la mischia AFAIR è contro la specializzazione: tutti dovrebbero avere lo stesso skillset e potrebbero lavorare in modo intercambiabile.

Everytime we are about to create the backlog and we do not define the exact UI/UX design before the beginning of the spring we end up spending too much time during the sprint trying to finalize the UI/UX design.

Sì, ora quella situazione è fin troppo buona. Ho lavorato in un team, dove abbiamo dovuto gestire backlogitems molto ampi come »Come utente, voglio vedere le informazioni x « e basta. Quindi l'oggetto è atterrato sullo sprint board. Un dev lo ha preso. Risolto. Dopo averlo implementato, ha avuto luogo una prima revisione tra pari, in cui è iniziata la discussione su come dovrebbe essere l'interfaccia utente.

Poi è arrivata la fase QA e la discussione è iniziata di nuovo.

Dopo lo sprint, abbiamo fatto come scrum richiede review dove il design è stato squarciato dal PO . Sfortunatamente il nostro cliente non è arrivato alle recensioni, quindi non ha visto il software a quel punto.

Ma poi il ciclo ricominciava da capo finchè PO era soddisfatto.

E poi è arrivato il cliente ...

Da questa storia di guerra vedi, che questo (tipo speciale) di processo è dannatamente inefficace.

Alla fine, ciò che ha funzionato per noi è stato il lancio di scrum .

Ma questa non è la soluzione alla tua domanda;)

Do you think that every possible detail about a feature should be given to the developers before the start of the sprint or should it be a task within the features?

Una soluzione a questo dilemma implicherebbe un feedbackloops stretto tra a) il cliente stesso e il PO , in modo che i criteri siano formulati in modo relativamente stretto. b) Uno stretto scambio di opinioni tra scrum-team e PO per ridurre al minimo la possibilità di guidare fuori strada.

Rompere alcune (più) regole di scrum per definire un backlogitem: un »manichino di lavoro«. Che potrebbe essere rivisto rapidamente da PO e dal cliente per ridurre al minimo lo sviluppo trascorso su un articolo semplice.

tl; dr

What should be the input of a scrum team?

Sufficienti informazioni per soddisfare le specifiche nel minor tempo possibile.

Offtopic:

Non facciamo più scrum. Non facciamo stime. Abbiamo mantenuto la scheda dello sprint. Non facciamo sprint. Sviluppiamo bug di funzionalità / correzione e rilasciamo ASAP. Quando vengono implementate nuove funzionalità, vengono inviate al più presto a un server pubblico in cui è possibile discutere ulteriormente il design con i clienti il più possibile.

La risposta canonica è "fai ciò che funziona per te".

Scrum è una delle metodologie agili. È esplicitamente progettato per cambiare e adattarsi alla tua squadra e al tuo progetto. Il tuo focus dovrebbe essere:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan (Agile manifesto)

Non è una questione di ciò che il tuo team dovrebbe deve iniziare su una storia, è una questione di quale input consente al tuo particolare team di risolvere le particolari esigenze aziendali.

Nella mia esperienza personale, dipende dall'obiettivo aziendale. Alcune storie hanno già una ricerca UI / UX e disegni completi, e questo è OK. Alcune storie hanno requisiti vaghi, perché l'azienda ha solo bisogno di un problema risolto. Anche questo è OK.

Ci sono anche altri fattori, ovviamente. Come se i tuoi designer facessero parte del team di sviluppo, o del marketing, o dello sviluppo del prodotto, ecc. Molti fattori. Fai solo ciò che è necessario per soddisfare il business, sii flessibile e assicurati di discutere queste cose durante le tue retrospettive, regolando il processo se necessario.

Ho avuto un simile respingimento dagli sviluppatori. Il problema dal loro punto di vista era che erano cauti su quanto tempo la parte UX avrebbe potuto prendere per implementare. Se acconsentono a provare a consegnare N storie in uno sprint, ma alcune delle storie impiegano molto più tempo del previsto a causa dell'andare avanti e indietro sulla UX, allora hanno ritenuto che riflettessero male su di loro.

Ciò che ha funzionato per noi è:

1. Qualcuno lavora con il proprietario del prodotto per creare mock up degli schermi da sviluppare. Questi vengono rivisti durante il consueto processo di affinamento della storia prima che la storia venga trascinata in uno sprint che dà a tutti la possibilità di avere una discussione onesta.
2. Non tentare di finalizzare il progetto prima della codifica, basta farlo uscire e quindi avere una conversazione su ciò che deve essere cambiato. I costi di modifica sono quindi più chiari e aiutano il proprietario / cliente del prodotto a decidere se vale la pena.
3. Fiducia tra il proprietario del prodotto / i clienti e gli sviluppatori. Alla fine tutti cercano di consegnare cose al cliente. Al PO non è permesso di lamentarsi della squadra che non consegna tutto da uno sprint. Gli sviluppatori non possono essere deliberatamente ostruzionistici perché sono preoccupati di non consegnare.
4. Practice. Abbiamo appena ottenuto una stima delle dimensioni delle storie e siamo in grado di individuare i probabili problemi.

Tl; DR: non definire completamente l'UX prima della codifica. Attendi fino a quando gli utenti lo vedono e giocaci.

Do you think that every possible detail about a feature should be given to the developers before the start of the sprint or should it be a task within the features?

In parole semplici, se il proprietario del prodotto non è in grado di fornire il design ui / ux prima dello sprint, lo sviluppo di ui / ux dovrebbe essere una storia , non un compito.

I deliverable dello sprint non devono sempre essere un codice funzionante e il team stesso può essere il "chi" della storia. Puoi avere una storia del tipo "Come membro del team di sviluppo, abbiamo bisogno di mockup dell'interfaccia utente per poter implementare l'interfaccia utente". Quindi stimerai quanto tempo impiegherà la tua squadra a consegnare i prototipi e questa diventerà una delle prime storie su cui lavori.

Non è necessario specificare l'interfaccia utente, accetta solo la richiesta funzionale (storia) e la segna sapendo che devi pensare a un'interfaccia utente. Avere il client specificare che l'interfaccia utente sta cercando problemi.

Ora che sai che l'interfaccia utente ti costerà un po 'di tempo dovresti essere in grado di pianificare meglio, la prossima volta che svolgi un'attività che include un'interfaccia utente, assegnerai alcuni punti extra alla storia.

Se sei mischia chiunque può essere un designer UI / UX.

L'UI / UX non dovrebbe essere un ripensamento. Dovrebbe essere un deliverable. Dovrebbe essere approvato dal proprietario del tuo prodotto. Dovrebbe apparire, anche se solo come gif, durante la consegna.

Questo non significa che non possa cambiare. È qualcosa che cambierà spesso. È anche qualcosa su cui desideri un feedback in anticipo. Non lasciare che il codice guidi il design dell'interfaccia utente. Lascia che sia il cliente a guidarlo. Respingi solo quando il cliente chiede magia. Altrimenti, basta renderli consapevoli della quantità di lavoro che chiedono e quanto costerebbe.

L'unica UI / UX finalizzata è su software morto.

Dal tuo commento:

"It should be approved by your product owner." This is exactly where the problem arises. There is a huge amount of time spent on this approval process and we end up spending days instead of few hours that was initially estimated. - Rashid

Elimina tutto ciò che inutilmente ti rallenta.

Hai un'idea. Dillo al proprietario del prodotto. Dovrebbero essere seduti accanto a te.

Lo odiano? Vai avanti. Lo adoro? Fallo. Non capisco? Mostrali.

Brevi riunioni non programmate frequenti. Parlare. Doodle su una lavagna o carta. Mock up in un programma di pittura utilizzando schermate. Comunicare, approvare, implementare e rivedere rapidamente le idee.

Se il proprietario del prodotto non è in giro, prendi un umano conveniente e chiediglielo. Qualunque cosa serva per iniziare a scorrere. Riattiva il proprietario del prodotto non appena possibile.

Non passare un secondo a renderlo bello. Basta arrivare al punto. Mantieni le tue idee piccole e incrementali e puoi farle prima che qualcuno ti chieda un preventivo.

Nella mia esperienza:

• L'analisi up-front troppo poco efficace causa uno sviluppo stop-start inefficiente
• Un'analisi troppo rapida causa una paralisi dell'analisi (lo Sprint non viene mai avviato)

Cosa facciamo:

• Definisci alcuni " Ready for Development " criteria
• Per le storie UX, potrebbe essere "abbiamo un wireframe che è ben compreso dal team"

Durante la pianificazione dello sprint:

• Tutte le storie che non sono pronte per lo sviluppo vengono buttate fuori (sarebbero troppo dirompenti per la squadra e torneranno per ulteriori analisi)
• Tutte le storie borderline sono dichiarate "ad alto rischio" e intraprese proprio all'inizio dello Sprint
• Le storie ben comprese sono stimate e permesse nello Sprint

Questo sistema ci permette di dedicare la maggior parte di ogni Sprint all'esecuzione, cioè lavoriamo in modo molto più efficiente.

Qualsiasi compito nella tua mischia deve avere una stima per il lavoro totale coinvolto e un risultato verificabile.

Se metto un compito nella tua scrum "implementare la caratteristica X con un'interfaccia utente di cui il product manager è soddisfatto", questo ha un risultato verificabile, ma è chiaramente impossibile stimare la quantità di lavoro richiesto. Quindi questo compito non può essere ragionevolmente messo in una mischia.

Ora metto un compito nella tua mischia "progetta un'interfaccia utente per la feature X". Questo può essere stimato, e il risultato è verificabile. È un compito Ok all'interno di una mischia. Al termine dell'attività, l'hai fatto.

Ora, una volta terminata l'attività, il tuo product manager può dire che non gli piace il risultato. Va bene. C'era un compito nella mischia, l'hai fatto, e questo è il tuo lavoro. Può mettere un altro compito nella prossima mischia. Forse con un po 'più di direzione che tipo di interfaccia utente vorrebbe davvero. Questo è il suo lavoro. Impostazione delle attività che danno risultati utili . A volte è difficile, e il lavoro è fatto che risulta essere inutile. Ecco perché lo chiamano "agile"; vengono svolti compiti che risultano inutili, e poi si cambia in una direzione migliore.

Inoltre, il design UX, in particolare il design UX, è un lavoro a tempo pieno per qualcuno che ha praticato il design UX. Molti buoni sviluppatori di software possono fare un lavoro passabile creando una UX, ma non lo faranno altrettanto validi e convenienti quanto un buon progettista di UX (se potessero, allora creerebbero progetti UX e non svilupperebbero software). Quindi non avere un progettista UX è inefficace - di nuovo un problema per il proprietario del prodotto.

Non sono sicuro che tu stia seguendo principi agili, ma ecco come dovrebbe essere gestito.

we do not define the exact UI/UX design before the beginning of the sprint

L'obiettivo non è quello di essere perfetto a questo punto. Ottieni tanto input per i requisiti in modo che gli sviluppatori possano creare qualcosa che corrisponda a ciò che è stato chiesto il più vicino possibile. Non apportare modifiche o provare a progettare cose che non sono state richieste. Perderai il tuo tempo.

we end up spending too much time during the sprint trying to finalize the UI/UX design.

Lavorare su un modo per determinare quando le cose sono fatte. Ho la sensazione, qualcuno sta continuando a fare un sacco di avanti e indietro valutazione dell'UI / UX. Troppe persone hanno opinioni su UX / UI senza nulla da parte del cliente per supportare le loro ipotesi.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

Questo genere di cose può andare avanti all'infinito. Non è un difetto di Scrum. Qualcuno sta interferendo con i requisiti durante lo sprint. Torna indietro per decidere cosa vuole il cliente, determinare quanto tempo ci vorrà e lavorare con loro per stabilire le priorità. Se pensano che ci vorrà troppo tempo, chiedi loro di cosa sbarazzarsi.

Esiste una società che progetta loghi a prezzo fisso. Limitano il numero di richieste di modifica perché sanno che alcuni clienti li uccideranno con la morte da mille tagli con tutte le loro modifiche. Fermati o carica di più. Si chiama business.