I progettisti di UX lavorano uno Sprint in anticipo

However in Scrum you are only supposed to have user stories that provide value to the user.

Il valore non viene misurato solo nelle righe del codice trasferibile.

Sembra che tu stia insinuando che avere un'interfaccia utente ben progettata non fornisce alcun valore. Certo che lo fa. Ovviamente c'è un valore per l'utente finale, ma c'è anche un valore per il tuo team di sviluppo, che è uno stakeholder perfettamente valido. Se non hai gli strumenti e i materiali per svolgere il tuo lavoro, non puoi fornire valore all'utente finale.

Non restare impigliato nei dogmi di scrum. Scrum è lì per renderti più efficiente. Se si esegue una storia UX, uno sprint prima di implementare l'interfaccia utente aiuta a fornire un software migliore, fallo.

I principali svantaggi sono questi:

1. Sei un conduttore: se i tuoi progettisti sono in ritardo, i tuoi sviluppatori rimangono senza lavoro; se i tuoi sviluppatori sono in ritardo, il tuo designer finirà per lavorare più di una iterazione in anticipo. Non è una situazione stabile - non è sostenibile .

2. I tuoi designer stanno lavorando in anticipo, stai pagando i costi per storie che potrebbero o meno essere sviluppate. Anche se accade raramente, stai ancora buttando via i soldi.

3. I progettisti di UX stanno prendendo decisioni in anticipo senza coinvolgere gli sviluppatori. Mancano informazioni utili e aumenta il rischio che i progetti siano nettamente sbagliati o irrealistici. Questo è abbastanza comune perché il design di UX non è un esercizio "astratto": deve essere creato a partire dalle caratteristiche dell'applicazione (compreso ciò che è fattibile / consigliabile o non tecnicamente)

4. Escludere o disattivare i tuoi sviluppatori non è un modo sostenibile per eseguire un progetto.

5. I designer non offrono valore: questo significa che è difficile, se non impossibile, dare la priorità al loro lavoro in modo corretto. Di solito, il lavoro dello sviluppatore è prioritario usando preoccupazioni, valore, fattibilità diversi nel prossimo sprint, quantità di sforzo. Molte storie temporali vengono negoziate e modificate per renderle "in forma" o per una discussione utile: se una di queste modifiche cambia l'interfaccia utente (e si può supporre che lo faccia se non è un semplice dettaglio di implementazione), cosa si fa con la storia? Non puoi più riprodurlo.

6. Si presume che una storia che può essere inserita in un'unica iterazione per i progettisti si inserisca in un'unica iterazione per gli sviluppatori: come si possono suddividere le storie in modo che questa ipotesi sia corretta?

Mi piace, per due motivi:

1. sembra funzionare per te; è difficile discutere con successo!
2. il team UX prende la storia e avvia la conversazione in anticipo - e le conversazioni sono un po 'il punto delle storie

Un requisito fondamentale di Scrum è che il team di mischia abbia tutte le competenze necessarie per creare un prodotto potenzialmente rilasciabile. Nella situazione che descrivi, questo non sta succedendo.

Il team UX non sta producendo prodotti potenzialmente rilasciabili e il team di Scrum non è in grado di produrre fette verticali di funzionalità in quanto non hanno tutte le competenze richieste. Queste sono disfunzioni.

Sklivvz ha scritto un post eccellente sui problemi che le suddette disfunzioni potrebbero portare a. In sintesi, non penso che tu stia praticando Scrum.

Ma non c'è assolutamente nulla di sbagliato in questo. Se hai scoperto un modo di lavorare che offre valore per tutti voi e ne siete tutti contenti, continuate a farlo. Il mio unico consiglio sarebbe di ispezionare e adattare frequentemente.

Nota, tuttavia, che se il tuo obiettivo è quello di fornire software usando Scrum, dovrai affrontare le disfunzioni identificate.

Ci sono due problemi qui, uno sul design centrato sull'utente e l'altro sull'allineamento dello sprint.

Prima : le storie degli utenti devono essere allineate con le esigenze degli utenti, non solo con il backlog. Le storie UX devono avere un valore chiaro per gli utenti. Questo non richiede una specifica completa e una breve istruzione come

"Users will have easier access to account activity on a single page rather than divided between multiple pages"

è adattabile e adattabile a varie implementazioni e tuttavia ancora chiaro sul valore per l'utente (accesso più facile all'attività dell'account).

Secondo : allineamento dello sprint. UX progetta funzioni in sprint X che gli sviluppatori implementano nella primavera X + 1. In pratica, ciò accade in molti negozi e talvolta potrebbe essere più simile all'implementazione in sprint X + 2 o X + 3. Con una squadra nitida e con esperienza, questa configurazione può funzionare. Diventa difficile se hai una nuova squadra o nuovi membri che non hanno familiarità con i set di abilità, le preferenze, le abitudini, gli stili di lavoro e le tendenze degli altri membri del team. Se hai lavorato insieme per meno di 6 mesi, è probabile che questo sia un problema.

Fai un passo indietro e rivaluta. Sul lato positivo, i progettisti e gli sviluppatori di UX lavorano fianco a fianco, il che è un vantaggio. Inizia facendo in modo che le tue storie abbiano un valore chiaro per gli utenti.

Uno dei possibili problemi che vedo è che in Scrum l'ambito per lo sprint N + 1 viene normalmente determinato subito prima dell'avvio. Quindi, come puoi fare UX per sprint N + 1 storie nello sprint N per prima di sapere quali storie saranno in ambito. Se decidi di correggere l'ambito per lo sprint N + 1 all'inizio dello sprint N, perdi un po 'di flessibilità.

However in Scrum you are only supposed to have user stories that provide value to the user. In our case the UX design stories don't provide such value (they are more like a backlog grooming activity).

Per come la vedo io, stanno offrendo un sacco di valore al loro utente. Il fatto è che il loro utente non è l'utente finale dell'azienda, il suo utente è il team di sviluppo che implementerà la funzione allo sprint X + 1.

Sei bloccato nella religione del processo e lungo il modo in cui vedo mischia / agile che viene abusato e gli utenti etichettati male. Scrum non è uno strumento universale, è un mezzo per un fine.

Penso che il tuo gruppo abbia erroneamente etichettato chi sono i tuoi utenti e stanno pianificando per il pubblico sbagliato.

Il gruppo UX sta usando scrum in modo classico, valore utente e adattamento agile agli input di alcuni utenti finali magici. Sono quelli con gli utenti. Il tuo gruppo sta facendo un uso improprio della mischia perché stai semplicemente inserendo dei meccanismi per realizzare un lavoro di progettazione esistente, non c'è nulla di agile e la scrum sta riempiendo il ruolo del monitoraggio della gestione.

Questo è il motivo per cui questo ti sembra sbagliato, in realtà non hai bisogno o benefici della mischia perché sei in un gruppo di servizio e il tuo lavoro scorre dalle persone con UX che hanno già fatto le parti agili / scrum .

Non c'è niente di male lì, solo un processo diverso è a posto di quello che ti è stato detto.