2013-06-04 21 views
13

Nel tentativo di capire cosa vedo in Accesso Web TFS 2012 in LAVORO | arretrato | Product Backlog, ho utilizzato il pulsante "Crea query di backlog" e ho quindi aperto la nuova query nella modifica per vedere come funziona. Ho notato che visualizza PBI che si adattano due descrizioni:Che cosa significa che un PBI viene eseguito mentre si trova nel backlog in MSF Scrum 2.2?

  • PBI ovunque sotto l'iterazione root (l'arretrato) nello Stato di New/Approvato.
  • PBI nel backlog (l'iterazione di root) in stato Nuovo/Approvato/Commesso.

Perché una PBI si adatta a questa seconda descrizione? Perché mai un PBI dovrebbe essere impegnato nell'arretrato? È forse un modo per mantenere i PBI a livello di temi o di livello epico dopo il perfezionamento e impostarli su commit quando i bambini a livello di story-story sono impegnati in veri e propri sprint? È forse solo un modo per compensare la contabilità scadente in cui i PBI incompleti sono presi a calci nell'arretrato, ma senza riportare i loro stati all'approvazione? Forse qualche altra ragione?

risposta

63

Nuovo - Questi sono PBI che qualcuno ha aggiunto al backlog del prodotto e non sono stati esaminati dal proprietario del prodotto e non sono stati accettati per la costruzione.

Approvato - Si tratta di PBI che il proprietario del prodotto ha concordato, modificato e verificato che siano comprensibili per il team. Una volta approvati, sono pronti per la squadra a riprendere la pianificazione sprint.

Impegnato - Un team di Scrum ha discusso il PBI nella pianificazione sprint, ha creato alcune attività e ha accettato di costruire il PBI nello sprint corrente.

Fine - Nella revisione sprint, il proprietario del prodotto ispeziona il lavoro svolto dal team e se è d'accordo che soddisfa i requisiti e gli standard di qualità, quindi l'articolo viene spostato sul risultato.

+1

spiace, ma questo in realtà non affronta la questione. – bwerks

+4

Ok, lo dirò a voi. Si dispone di un arretrato di prodotti con un elenco di requisiti per l'intero prodotto. Questi requisiti possono essere assegnati a diversi team. Chiunque può aggiungere un articolo del backlog del prodotto al backlog del prodotto. Quindi è nuovo. Se l'OP ama l'idea, lui/lei può approvarla.Al momento della pianificazione dello sprint, una squadra inserisce l'articolo del backlog del prodotto nel proprio backlog dello sprint e lo contrassegna come Committed; questa è una squadra che sta lavorando al PBI nello sprint attuale. Una volta che l'ordine di acquisto è felice, il team ha consegnato il PBI, l'ordine di acquisto contrassegna come fatto –

+1

Il primo significa quindi un lavoro non avviato. Il secondo significa lavoro incompleto incluso il lavoro che non è stato avviato –

4

Hai ragione! Da una prospettiva SCRUM non ha senso elencare un PBI Committed nel backlog. Il team ha o ha impegnato il PBI in uno sprint oppure no.

È interessante notare che il termine Committed non è menzionato nella Guida SCRUM per Sprint Planning o Sprint Backlog.

La mia ipotesi - Microsoft ha utilizzato il termine Committed per descrivere la proprietà del team di sviluppo di un PBI quando viene spostato dal Product Backlog in un Sprint, ma non ha voluto far rispettare la regola attraverso la validazione o automaticamente modifica dello stato PBI.

Se stai cercando una fonte più autorevole, è disponibile un articolo sullo stato MSDN che descrive i punti di stato disponibili senza riferimento a Sprints.

enter image description here