PBI vs User Story

Di recente un articolo è stato aggiunto al Product Backlog dal proprietario del prodotto, che dice "Quando vado alla pagina di accesso dalla pagina x, vedo un errore. Voglio che l'errore venga rimosso".

Mi sembra che questo non sia un caso d'uso e non dovrebbe essere un PBI (Product Backlog Item). Tuttavia, quando ne ho discusso, Scrum Master mi ha detto che le storie utente non sono PBI e che un PBI potrebbe essere una segnalazione di bug, un'attività, una storia utente, qualsiasi cosa e letteralmente qualsiasi elemento che dovrebbe essere affrontato per primo.

Non sono sicuro di questo. Inoltre non riesco a trovare una buona definizione di PBI sul web . Quindi, la mia domanda è: che tipo di cose possono entrare nel Product Backlog come articoli? Un articolo di backlog di prodotto è associato a una user story? Sono gli stessi?

Un articolo di backlog di prodotto è associato a una user story? Sono gli stessi?

Non necessariamente, ma in generale lo fanno. Come ha detto il tuo Scrum Master, anche altre cose possono essere articoli arretrati del prodotto. Tuttavia, dipende da come il tuo funziona MISCHIA. Alcuni team hanno un backlog di bug separato che viene preso in considerazione anche per gli sprint, mentre altri mantengono tali elementi nel backlog del prodotto.

Due registri separati rendono più difficile per il proprietario del prodotto stabilire le priorità delle attività, poiché ora due registri devono essere presi in considerazione per lo sprint successivo. Ma offrono una migliore supervisione ed entrambi possono essere prioritari separatamente.

Quindi, la mia domanda è: che tipo di cose possono entrare nel Product Backlog come articoli?

Questo può essere tutto ciò che fa parte della visione del prodotto e del viaggio verso il prodotto che si desidera creare. Contiene principalmente requisiti (user story) ma può anche contenere azioni o elementi tecnici che non appartengono direttamente al prodotto (ad es. "Acquista un nuovo server per il team di sviluppo", "Crea pubblicità per prodotto"). L'arretrato dovrebbe evitare dettagli inconsueti e non cercare di micromanage di cose tecniche. Il backlog del prodotto può contenere tutto ciò che fornisce valore al prodotto.

Non c'è l'unico vero Scrum. A volte i backlog separati sono un modo migliore per gestire il prodotto, a volte sono solo in mezzo. Scopri cosa funziona meglio per te.

Quando lavoriamo sui bug, li aggiungiamo al backlog e li chiamiamo storie di bug . Aggiungendo correzioni di bug al backlog in questo modo, è chiaro che non è solo la correzione di bug. Possiamo aggiungere altre attività per assicurarci che i test automatizzati vengano scritti e la verifica venga eseguita. Inoltre, rende più esplicito il rispetto del DoD.

Non abbiamo mai usato il termine PBI (anche se il nostro strumento di backlog li chiama così), sono sempre storie utente, storie di bug o semplicemente storie .

È principalmente solo la scelta della terminologia del tuo team e fintanto che hai tutte le idee chiare su ciò che non importa.

Tutte le risposte di cui sopra non fanno riferimento al documento di origine autorevole per il framework Scrum: The Scrum Guide .

Portafoglio prodotti

C'è una sezione che descrive il Product Backlog e gli articoli, spesso indicati come PBI, contenuti al suo interno.

Il Product Backlog elenca tutte le caratteristiche, funzioni, requisiti, miglioramenti e correzioni che costituiscono le modifiche da apportare al prodotto nelle versioni future.

Ma non è risolto come un piano di progetto.

Il Product Backlog si evolve man mano che si evolve il prodotto e l'ambiente in cui verrà utilizzato. Il Product Backlog è dinamico; cambia costantemente per identificare ciò di cui il prodotto ha bisogno per essere appropriato, competitivo e utile.

User Story

Il termine user story non appare mai in The Scrum Guide perché

è un framework all'interno del quale è possibile impiegare vari processi e tecniche.

L'uso di una user story è solo una possibile tecnica per la registrazione dei PBI.

INOLTRE: Sebbene sia comune vedere il formato "As a, I Want, So that", può essere in contrasto con il suo intento originale . Questo formato problematico è stato affrontato anche ad Agile 2017 .

@Falcon lo ha spiegato bene. Una pagina che ha una definizione formale è: http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog Quello che hai descritto non deve essere inserito nel backlog del prodotto almeno secondo tale descrizione.

Esiste un malinteso comune sul fatto che sono consentite solo le storie degli utenti in un Product Backlog. Al contrario, Scrum è neutrale nelle tecniche dei requisiti. Come afferma Scrum Primer ,

Gli articoli arretrati del prodotto sono articolati in modo chiaro e sostenibile. Contrariamente al malinteso popolare, il Product Backlog non contiene "user story"; contiene semplicemente elementi. Tali elementi possono essere espressi come user story, casi d'uso o qualsiasi altro approccio ai requisiti che il gruppo ritenga utile. Ma qualunque sia l'approccio, la maggior parte degli articoli dovrebbe concentrarsi sulla fornitura di valore ai clienti. *

• Le specifiche distinte di modifiche e aggiunte al prodotto, sono denominate Product Backlog Items (PBI), che insieme formano il Product Backlog.
• Ogni PBI descrive qualcosa che gli Sviluppatori possono sviluppare e fornire per aggiungere valore agli stakeholder rilevanti quando Fatto (vedi Definizione di Fatto).
• Lo stakeholder più comune è il mercato o il suo rappresentante - il Product Owner.
• Tuttavia, un PBI può descrivere lavori che riducono i costi per l'impresa o riducono gli sforzi per il team di sviluppo o uno strumento che aiuta il team dei proprietari di prodotti a svolgere meglio il proprio lavoro.
• Un PBI può descrivere qualsiasi cosa abbia un valore potenziale per un stakeholder.

Una storia (utente) è un utile formato standard per gli articoli arretrati. La logica alla base è "se a nessuno importa, non perdere tempo". Inoltre, consente all'OP di valutare l'urgenza dell'articolo perché definisce per chi lo farà e per quanto è grave.

Nel tuo caso il bug può essere facilmente formattato come una storia.

• Come utente
• Voglio essere in grado di accedere dalla pagina X (e non ottenere invece un errore)
• quindi non perderò tempo, sarò infastidito e perderò fiducia nel prodotto

Sembra che valga la pena di fare qualche sforzo.