Livello di dettaglio di una user story

Question

Livello di dettaglio di una user story

#1 da (3 voti)
#2 da (2 voti)

2

Sto per iniziare sessioni di User story nel mio team. È abbastanza nuovo per loro e sto anche lottando con certe cose. Per il progetto attuale abbiamo alcuni wireframe ben elaborati.

Ho letto molto sul modo di scrivere storie di utenti. Come dovrebbe essere il template e su diversi aiuti come Invest

Il piano è di trasformarli in storie di utenti. Diciamo che ho uno schermo in cui un utente può modificare un ordine. Ci sono molti dettagli su quello schermo. Ora quando si crea una user story di questa storia. Basterà dire:

As an Admin I can edit a purchase order so that mistakes typed by the user can be enhanced.

O dovrei specificare ogni dettaglio come:

As an Admin I can resend an invoice to the customer, so he can get a copy of his lost one.

As an Admin I can review the customer order so he has detailed information about each purchase

As an admin I can remove items forma on order so that in case the customer made a mistake I can remove Items.

E per quanto riguarda i criteri di accettazione. Come dovrebbe essere definito per un utente come tale. Dove posso definire quali campi devono essere visualizzati in una pagina dei dettagli dell'ordine? Può far parte dei criteri di accettazione?

agile scrum user-story

posta sanders 11.09.2013 - 15:08

fonte

2 risposte

Leggi altre domande sui tag agile scrum user-story

Utilizza il metodo sort () dell'array di ruby o aggiungi elementi nella posizione corretta con una ricerca binaria? Design documento per progetto in C

score 3 · Answer 1

Poiché questo è taggato con scrum , è probabile che tu voglia rimandare a una storia utente più dettagliata. Se stai usando qualcosa come XP o FDD, puoi essere un po 'più agile perché la pietra miliare non è basata sul tempo.

Con Scrum, vuoi solo definire la storia dell'utente abbastanza per essere in grado di dare una stima accurata del tempo, nonostante la definizione che richiede.

Dipende davvero dai capricci del team e dagli stakeholder, ma se si delineano 10 aspetti o sottofunzioni di modifica degli ordini di acquisto, non è probabile che si possa aggiungere un altro una volta che lo sprint è stato pianificato, e se una di queste sottofunzionalità è sufficientemente coinvolta (come la rimozione di oggetti da un ordine, forse), potrebbe essere necessario trasformarla in una funzionalità con una storia a parte.

È impossibile fare Scrum perfettamente, tuttavia l'obiettivo finale di Scrum non è quello di rimuovere tutte le ambiguità, ma piuttosto di definire chiaramente le funzionalità di base per rimuovere un'ambiguità sufficiente a fornire una stima del tempo per lo più accurata.

score 2 · Answer 2

Non esiste un modo "prescritto" per fare storie in mischia, quindi non c'è una risposta diretta alla tua domanda, tuttavia posso darti dei consigli generali sulla base dell'esperienza:

Se la tua squadra non ha esperienza in mischia, crea le storie il più possibile ridotte . Infatti, se riesci a renderli abbastanza piccoli, puoi sostituirli per la stima del punto della storia senza perdere molta prevedibilità.
Metti il meno possibile nella storia. Evita di progettare software nelle storie, includi solo ciò che conta per l'utente . I campi esatti sono assolutamente necessari? È meglio assicurarsi che siano sviluppati: utilizzare test di accettazione. I campi non sono strettamente necessari finché una determinata operazione può avere successo? Metti il successo di questa operazione come accettazione, invece dei campi.
Assicurati che il proprietario del tuo prodotto sia disponibile durante lo sprint per rispondere alle domande e fornire i dettagli. Non cadere nella trappola di avere il PO solo interagire alla riunione di pianificazione o utilizzare le storie come una bacheca per il team. Il PO è parte del team e deve essere presente nel team durante lo sprint.

Spero che questo ti faccia iniziare nella giusta direzione! Buona fortuna!