Come scrivere una storia utente specifica per le attività in questo caso [duplicato]

1

Abbiamo pianificato di scrivere una storia utente

As a player I want to view the game map to know current standings of my team

Lo sprint è per due settimane. Saremo in grado di completare solo HTML in due settimane, questa storia utente impiegherà 4-6 settimane per essere completata in quanto abbiamo una carenza di risorse per la progettazione dei contenuti.

Come possiamo cambiare questa User story in modo che il completamento dell'HTML possa essere considerato come un fatto per questa user story e dobbiamo riprendere l'integrazione di questa user story nel prossimo sprint?

È possibile creare due diverse user story, una per HTML e altre per l'integrazione, test, correzione dei bug ecc?

    
posta Vignesh Subramanian 18.08.2014 - 12:32
fonte

2 risposte

2

Come per tutte le storie, pensa a ciò di cui hai bisogno, a chi è destinato e perché ne hanno bisogno. L'utente non deve essere l'utente finale. Ricorda che l'obiettivo finale di scrivere storie è quello di aiutare te e il tuo team . Non ottieni punti bonus per creare storie che si adattano a una definizione da un libro. Rompi la storia in pezzi più piccoli che aiutano la tua squadra a concentrarsi.

Ad esempio, una storia frontale:

As a developer building the game map, I need the HTML markup to be created so that I can display the map.

... e una storia di back-end

As a developer building the game map, I need to back-end API to support fetching the game data so that I can display it on the map

... forse una storia di design

As a developer building the game map, I need to final style sheets to be developed so that the user enjoys using the map.

... e così via.

    
risposta data 18.08.2014 - 13:22
fonte
0

Penso che la tua domanda nasconda un problema più grande: la mancanza di contenuti che progettano le persone (per favore non chiamare le risorse delle persone, le depersonalizza) sembra indicare che il tuo team sta lavorando nei silo di sviluppo.

In un recente progetto su cui ho lavorato è successo lo stesso. Avevamo front end, integratori e back end.

Ero un incubo. Sebbene i front end fossero costantemente impegnati, gli integratori non lo erano, e i backenders non sapevano cosa finire prima. Finì con 40 o più storie non finite a un certo punto nel tempo, con niente finito (oltre ai problemi del team, dovemmo anche aspettare all'infinito che le cose fossero finite da un'altra parte).

Abbiamo dovuto stimare il completamento delle storie solo per dare al cliente un'indicazione dei progressi. La tua domanda mi ha ricordato questo. Sì, potremmo mostrare i prototipi al cliente, ma finché non è riuscito a utilizzarli (completati, documentati, testati e approvati), non avevano alcun valore per lui.

Il mio consiglio: quando il contenuto che progetta le persone sta iniziando il lavoro su una storia, permetti loro di accoppiare il programma con alcuni degli altri. All'inizio potrebbe costare un po 'di tempo, ma a lungo andare potrebbe valere la pena. Con il 20% delle conoscenze, spesso l'80% del lavoro può essere svolto. Può esercitare una certa pressione sugli attuali progettisti di contenuti e creare un flusso migliore all'interno del team.

    
risposta data 20.08.2014 - 00:57
fonte

Leggi altre domande sui tag