PBI gegen User Story

Kürzlich wurde dem Product Backlog vom Product Owner ein Artikel hinzugefügt, der besagt, dass beim Aufrufen der Anmeldeseite von x Seite ein Fehler angezeigt wird. Ich möchte, dass dieser Fehler behoben wird.

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

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

Ist ein Produktrückstandsartikel einer User Story zugeordnet? Sind sie gleich

Nicht unbedingt, aber im Allgemeinen. Wie Ihr Scrum Master sagte, können auch andere Dinge Produktrückstände sein. Dies 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 Produkt-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. Aber sie bieten 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 aufgenommen werden?

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

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

Wenn wir an Fehlern arbeiten, fügen wir sie dem Backlog hinzu und nennen sie Fehlergeschichten . Durch das Hinzufügen von Fehlerkorrekturen zum Rückstand 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 werden. Dies macht es auch expliziter, dass die DoD befolgt werden sollte.

Wir haben den Begriff PBI nie verwendet (auch wenn unser Backlog-Tool dies so nennt), es sind immer User-Stories, Bug-Stories oder einfach nur Stories .

Hauptsächlich liegt es an der Terminologie Ihres Teams und solange Sie sich im Klaren sind, worauf es nicht wirklich ankommt.

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

Produktrückstand

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

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

Ist aber nicht wie ein Projektplan fixiert .

Das Product Backlog entwickelt sich mit dem Produkt und der Umgebung, in der es verwendet wird. Das Product Backlog ist dynamisch. Es ändert sich ständig, um zu ermitteln, welche Produkte angemessen, wettbewerbsfähig und nützlich sein müssen.

Benutzer Geschichte

Der Begriff User Story wird in The 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 "As a, I want, So that" zu sehen, kann es seiner ursprünglichen Absicht widersprechen . Dieses problematische Format wurde auch auf der Agile 2017 angesprochen .

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

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 angibt,

Product Backlog Die Artikeldarstellung ist klar und nachhaltig. Entgegen dem weit verbreiteten Missverständnis enthält das Product Backlog keine "User Stories". es enthält einfach Gegenstände. Diese Elemente können als User Storys, Anwendungsfälle oder andere Anforderungsansätze ausgedrückt werden, die die Gruppe als nützlich erachtet. Unabhängig von der Herangehensweise sollten sich die meisten Artikel darauf konzentrieren, den Kunden einen Mehrwert zu bieten. *

• Spezielle Spezifikationen für Änderungen und Ergänzungen des Produkts werden als Product Backlog Items (PBIs) bezeichnet, die zusammen das Product Backlog bilden.
• Jede PBI beschreibt etwas, das die Entwickler entwickeln und liefern können, um den relevanten Stakeholdern einen Mehrwert zu bieten, wenn sie fertig sind (siehe Definition von Fertig).
• Der häufigste Stakeholder ist der Markt oder sein Vertreter - der Product Owner.
• Eine PBI kann jedoch Arbeit beschreiben, die die Kosten für das Unternehmen senkt oder den Aufwand für das Entwicklungsteam verringert, oder ein Tool, das dem Product Owner Team hilft, seine Arbeit besser zu erledigen.
• Eine PBI kann alles beschreiben, was für einen Stakeholder einen potenziellen Wert hat.

Eine (Benutzer-) Story ist ein hilfreiches Standardformat für Backlog-Elemente. Das Grundprinzip dahinter lautet: "Wenn es niemanden interessiert, verschwenden Sie keine Zeit damit." Es ermöglicht der Bestellung auch, die Dringlichkeit des Artikels zu bewerten, da es definiert, für wen Sie es tun und wie schlecht es 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, verärgert sein und das Vertrauen in das Produkt verlieren

Das klingt nach Mühe.