best practice nella creazione di un backlog di prodotti in mischia [chiuso]

Ciò che facciamo è che il nostro livello più alto sia una "user story". Ogni storia utente dovrebbe descrivere alcuni vantaggi specifici che gli utenti riceveranno quando la funzionalità sarà completa. Ogni storia dovrebbe descrivere un utile elemento di funzionalità in sé e per sé. Ad esempio,

• "Gli utenti possono navigare verso un sito Web per ottenere informazioni di base sulla nostra azienda."
• "Gli utenti possono utilizzare un'app Web per gestire i propri abbonamenti."
• "Gli amministratori di sistema possono utilizzare una pagina Web per aggiungere, eliminare e modificare utenti."
• "Gli amministratori di sistema possono utilizzare una pagina Web per aggiungere ed eliminare contenuti."

Le attività descrivono quindi le azioni che devono essere intraprese per assicurare che la storia sia completa. Per "Gli utenti possono navigare verso un sito Web per ottenere informazioni di base sulla nostra azienda", potrei avere cose come:

• "Crea home page"
• "Crea la pagina" Contattaci "e collegala ad essa dalla home page"
• "Crea pagina" Indirizzi ufficio ""
• "Crea la pagina" Carriere "
• "Crea una barra di navigazione che rimandi alle sedi degli uffici e alle pagine delle carriere, con spazio per le funzionalità future"

Stai pensando troppo. Molto.

Ogni Sprint, la squadra si trova di fronte alla domanda: "Che cosa faremo in questo Sprint?". Idealmente, gli articoli del backlog devono essere di dimensioni tali da poter essere effettivamente completati in un singolo Sprint, e non così piccoli da diventare un incubo da organizzare e tenere traccia di tutto. Va bene avere oggetti molto grandi con bassa priorità, quindi dividerli in elementi più piccoli quando diventano più vicini alla parte superiore dell'elenco di priorità.

Funzioni, sotto-funzioni, attività. Che importa? Finché il Team è in grado di identificare gli elementi con priorità più alta ogni Sprint e farli terminare, allora il PB sta facendo il suo lavoro.

Trovo che le storie siano più facili da definire se sono accompagnate dai passaggi su come testarlo. I compiti sono le cose che dovresti fare per rendere possibile quella storia.

I passaggi per testarlo sono importanti in quanto aiutano a mantenere la storia onesta, impostano le aspettative su cui stiamo parlando senza impantanarsi con l'implementazione. Generalmente, le storie dovrebbero essere davvero leggere in modo che possano essere facilmente valutate e implementate con un breve periodo di tempo.

" Gli utenti possono segnalare un problema con un prodotto o il nostro sito web " avrebbero una descrizione che contiene pensieri di test di alto livello, come " Vai alla pagina dei contatti e compila il modulo. Controlla la casella di posta elettronica di ringraziamento. "Puoi dedurre molto sulle attività e sui requisiti (dovrai raccogliere un indirizzo email e configurare un server di posta) ma è deliberatamente aperto per guidare la discussione con il cliente quando è il momento di valutare.

Dove lavoro tendiamo ad avere il seguente formato per una user story:

As an X, I want to do Y because Z.

X = attore che desidera eseguire un'azione. Y = Azione da fare. Z = Motivo per volere questa azione in modo che le alternative possano essere considerate.

Le attività sono solitamente articoli che possono essere eseguiti in meno di qualche ora, come ricordo. Abbattere la costruzione di una pagina dipende un po 'da ciò che è nella pagina e simili poichè alcune pagine potrebbero essere viste come un compito semplice simile ad altre pagine già costruite in modo che ci vogliono meno di 20 minuti per creare la pagina e impacchettare le modifiche per promuovere la modifica in altri ambienti.

Parte di Scrum nella mia mente è che i primi sprint sono i punti in cui la velocità e gli errori vengono elaborati in termini di ciò che funziona per il team, poiché ciò che potrebbe funzionare per una squadra non è probabile che funzioni per un'altra.