it-swarm.dev

PBI vs User Story

Kürzlich wurde dem Product Backlog vom Product Owner ein Artikel hinzugefügt, der besagt: "Wenn ich von der x-Seite zur Anmeldeseite gehe, wird ein Fehler angezeigt. Ich möchte, dass dieser Fehler entfernt wird.".

Es scheint mir, dass dies kein Anwendungsfall ist und kein PBI (Product Backlog Item) sein sollte. Als ich darüber sprach, sagte mir Scrum Master jedoch, dass User Stories keine PBIs sind und dass ein PBI ein Fehlerbericht, eine Aufgabe, eine User Story, irgendetwas und buchstäblich jedes Element sein kann, das zuerst angesprochen werden sollte.

Ich bin mir darüber nicht sicher. Außerdem kann ich keine gute Definition von PBI finden im Web . Meine Frage ist also, welche Art von Dingen als Elemente in das Product Backlog gelangen können. Wird ein Product Backlog-Element einer User Story zugeordnet? Sind sie gleich?

19
Saeed Neamati

Wird ein Product Backlog-Element einer User Story zugeordnet? Sind sie gleich?

Nicht unbedingt, aber im Allgemeinen. Wie Ihr Scrum Master sagte, können auch andere Dinge Product Backlog-Elemente sein. Es hängt jedoch davon ab, wie Ihr SCRUM funktioniert. Einige Teams haben einen separaten Bug-Backlog, der auch für Sprints berücksichtigt wird, während andere solche Dinge im Product-Backlog behalten.

Zwei separate Protokolle erschweren es dem Product Owner, Aufgaben zu priorisieren, da jetzt zwei Protokolle für den nächsten Sprint berücksichtigt werden müssen. Sie bieten jedoch eine bessere Übersicht und beide können separat priorisiert werden.

Meine Frage ist also, welche Art von Dingen können als Artikel in das Product Backlog gelangen.

Dies kann alles sein, was Teil der Produktvision und der Reise zu dem Produkt ist, das Sie erstellen möchten. Es enthält hauptsächlich Anforderungen (User Stories), kann aber auch Aktionen oder technische Dinge enthalten, die nicht direkt zum Produkt gehören (z. B. "Neuen Server für Entwicklerteam kaufen", "Werbung für Produkt erstellen"). Der Rückstand sollte unnötige Details vermeiden und nicht versuchen, technische Dinge im Mikromanagement zu verwalten. Das Produkt-Backlog kann alles enthalten, was dem Produkt einen Wert liefert.

Es gibt nicht den einen wahren Scrum. Manchmal sind separate Rückstände eine bessere Möglichkeit, das Produkt zu verwalten, manchmal sind sie nur im Weg. Finden Sie heraus, was für Sie am besten funktioniert.

20
Falcon

Alle oben genannten Antworten verweisen nicht auf das maßgebliche Quelldokument für das Scrum-Framework: The Scrum Guide .

Produktrückstand

Es gibt einen Abschnitt, der das Product Backlog und die darin enthaltenen Elemente beschreibt, die häufig als PBIs bezeichnet werden.

Das Product Backlog listet alle Features, Funktionen, Anforderungen, Verbesserungen und Korrekturen auf, die die Änderungen darstellen, die in zukünftigen Versionen am Produkt vorgenommen werden müssen.

Ist aber nicht fest wie ein Projektplan.

Das Product Backlog entwickelt sich mit der Entwicklung des Produkts und der Umgebung, in der es verwendet wird. Das Product Backlog ist dynamisch. Es ändert sich ständig, um festzustellen, was für ein Produkt angemessen, wettbewerbsfähig und nützlich sein muss.

Benutzer Geschichte

Der Begriff User Story Wird im Scrum Guide nie angezeigt, weil

es ist ein Rahmen, in dem Sie verschiedene Prozesse und Techniken anwenden können.

Die Verwendung einer User Story ist nur eine mögliche Technik zum Aufzeichnen der PBIs.

ZUSÄTZLICH: Obwohl es üblich ist, das Format "Wie ich will, also das" zu sehen, kann es seinem rsprüngliche Absicht widersprechen. Dieses problematische Format wurde auch unter Agile 2017 behoben.

3
Alan Larimer

Wenn wir an Fehlern arbeiten, fügen wir sie dem Backlog hinzu und nennen sie Bug Stories. Durch das Hinzufügen von Fehlerkorrekturen im Backlog auf diese Weise wird deutlich, dass es sich nicht nur um die Fehlerkorrektur handelt. Wir können weitere Aufgaben hinzufügen, um sicherzustellen, dass automatisierte Tests geschrieben und die Überprüfung durchgeführt wird. Es macht auch deutlicher, dass das DoD befolgt werden sollte.

Wir haben den Begriff PBI nie verwendet (obwohl unser Backlog-Tool sie so nennt), er ist immer ser Stories, Bug Stories oder einfach nur Stories.

Es ist hauptsächlich nur die Wahl der Terminologie Ihres Teams und solange Sie alle klar sind, worauf es ankommt, ist das nicht wirklich wichtig.

3
Hugo

Es gibt ein weit verbreitetes Missverständnis, dass in einem Product Backlog nur User Stories zulässig sind. Im Gegensatz dazu ist Scrum in Bezug auf Anforderungstechniken neutral. Wie der Scrum Primer besagt,

Product Backlog Items werden klar und nachhaltig artikuliert. Im Gegensatz zu weit verbreiteten Missverständnissen enthält das Product Backlog keine "User Stories". es enthält einfach Gegenstände. Diese Elemente können als User Stories, Anwendungsfälle oder andere Anforderungsansätze ausgedrückt werden, die die Gruppe für nützlich hält. Unabhängig vom Ansatz sollten sich die meisten Artikel darauf konzentrieren, den Kunden einen Mehrwert zu bieten. *

2
user666

@ Falcon hat es gut erklärt. Eine Seite mit einer formalen Definition lautet: http://en.wikipedia.org/wiki/Scrum_ (Entwicklung) #Product_backlog Was Sie beschrieben haben, darf nicht gemäß dieser Beschreibung in das Produkt-Backlog aufgenommen werden mindestens.

2
NoChance
  • Bestimmte Spezifikationen für Änderungen und Ergänzungen des Produkts werden als Product Backlog Items (PBIs) bezeichnet, die zusammen das Product Backlog bilden.
  • Jeder PBI beschreibt etwas, das die Entwickler entwickeln und bereitstellen können, um den relevanten Stakeholdern einen Mehrwert zu bieten, wenn dies erledigt ist (siehe Definition von Fertig).
  • Der häufigste Stakeholder ist der Markt oder sein Vertreter - der Product Owner.
  • Ein PBI kann jedoch Arbeiten beschreiben, die die Kosten für das Unternehmen senken oder den Aufwand für das Entwicklungsteam verringern, oder ein Tool, das dem Product Owner Team hilft, seine Arbeit besser zu erledigen.
  • Ein PBI kann alles beschreiben, was für einen Stakeholder einen potenziellen Wert hat.
1
NiceDevice

Eine (Benutzer-) Story ist ein hilfreiches Standardformat für Backlog-Elemente. Das Grundprinzip dahinter lautet: "Wenn sich niemand darum kümmert, verschwenden Sie keine Zeit damit." Außerdem kann die Bestellung die Dringlichkeit des Artikels beurteilen, da definiert wird, für wen Sie ihn ausführen und wie schlecht er ist.

In Ihrem Fall kann der Fehler leicht als Story formatiert werden.

  • Als Benutzer
  • Ich möchte mich von Seite X aus anmelden können (und stattdessen keinen Fehler erhalten).
  • so werde ich keine Zeit verlieren, mich ärgern und das Vertrauen in das Produkt verlieren

Das klingt nach Mühe.

0
Martin Maat