Le tue storie includono compiti in tutte le discipline? Come si fa a pianificare la capacità?

Forse.

Sono stato agile con tutto prima. Alcune cose (progettazione grafica, UX, BA) sono suddivise in gruppi diversi e, in una certa misura, storie utente diverse. Quindi la dura dipendenza può essere risolta prima per rimuovere la storia dipendente dal backlog.

Per cose come la documentazione o il controllo qualità, queste sono cose che devono essere veramente fatte con lo sviluppo con . Non dipendono tanto dalle attività correlate che devono essere completate prima che qualcosa possa essere "fatto".

Questa è una domanda complicata. Il problema è che hai bisogno di alcune delle risorse (come hai detto comps, wireframe) come input per le altre attività (sviluppo). Basandomi su questo, direi che stimare le attività di sviluppo è difficile senza questo input, che ovviamente è qualcosa che si vuole evitare.

Posso vedere due approcci per aiutare con questo:

Storie separate

Tratta le attività in modo da fornire gli input richiesti per lo sviluppo come storie separate, ad es. avere una storia per "Account Screen UI" e una seconda per "Account Screen Dev", con una dipendenza l'una dall'altra. Quindi il team dell'interfaccia utente può lavorare sulla prima storia in Sprint X e il team Dev può lavorare sulla seconda storia in Sprint X + n, dato che la storia dell'interfaccia utente è terminata.

Potresti incorrere in problemi a causa della dipendenza, ad es. se non è chiaro che esiste una dipendenza.

L'interfaccia utente funziona fuori dallo Sprint

In questo approccio, lavora sulle attività di interfaccia utente al di fuori dello sviluppo di Sprint. Trattate ancora l'interfaccia utente come una dipendenza per lo sviluppo, ma il team di interfaccia utente non funziona come parte del team di sviluppo e non all'interno dello stesso Sprint.

Questo è il modo in cui stiamo attualmente lavorando, poiché abbiamo alcune delle stesse dipendenze. Abbiamo creato una Definizione di pronto , che definisce le informazioni che devono essere disponibili affinché una storia sia ritenuta pronta , cioè può essere spostata sullo sviluppo. Una parte di questa definizione di Ready è che tutte le storie dell'interfaccia utente contengono mockup, screenshot o wireframe. Come parte di Story Grooming, lavoriamo con il team di interfaccia utente per passare attraverso le storie, e creano mockup ecc. Una volta che ci sono e la storia ha criteri di accettazione, può essere stimata (Planning Poker). Fatto ciò, è ready .

In questo modello, il lavoro di grooming o dell'interfaccia utente può essere eseguito in modo agile anche quando il team di grooming e / o UI sta utilizzando un processo agile. Potrebbe essere Scrum, o potrebbe anche essere Kanban, che potrebbe essere più adatto per questo tipo di lavoro.

Manterrei i tuoi team interdisciplinari. Se una squadra è troppo grande, dividerei il progetto in team Scrum separati, con ogni squadra sottoposta a una disciplina interdisciplinare. (In una spinta, le persone possono dividere i loro sforzi su due o più team, se necessario, basta tenerne conto quando si stima contro la velocità.) Suddividere team e storie in design / prototipazione / dev etc è controproducente, penso , per i motivi che ho fornito nel commento a @nwinkler: dovresti creare solo storie che offrano valore al cliente.

Kanban o Scrumban sono buoni approcci che possono aiutare il tuo pensiero in merito alle dipendenze. Se controlli con giudizio i tuoi limiti WIP, ti consentirebbero di creare wireframe prima che avvenga lo sviluppo, senza ridurre il tempo totale di completamento di una funzione. Ho trovato questo particolarmente utile se le persone hanno mai avuto bisogno di indossare "cappelli" diversi: ad es. se la colonna "test" raggiunge il limite WIP, un BA o uno sviluppatore potrebbe indossare il proprio cappello tester per il giorno.