ScrumWie Sie ein Product Backlog erstellen

Was ist ein Product Backlog?

Ein Product Backlog ist eine priorisierte Liste von Aufgaben und Anforderungen, die in einem Projekt umgesetzt werden sollen. Es ist ein zentrales Element des agilen Projektmanagements, insbesondere in Scrum. Damit können Projektteams ihre Arbeit organisieren und priorisieren.

Der Product Owner ist in der Regel verantwortlich für die Pflege und Priorisierung des Product Backlogs. Er muss:

• die Anforderungen und Wünsche der Stakeholder verstehen,
• das Backlog regelmäßig pflegen sowie priorisieren und
• sicherstellen, dass das Backlog immer aktuell und vollständig ist.

Was wird mit dem Product Backlog bezweckt?

Ein Product Backlog stellt sicher, dass das Team über eine priorisierte Liste von Aufgaben verfügt, die abgearbeitet werden muss. Dies ermöglicht:

• Fokussierung auf wichtige Aufgaben
  Indem die wichtigsten Aufgaben zuerst bearbeitet werden, steigt der Wert des Produkts, da wesentliche Features und Verbesserungen frühzeitig umgesetzt und von Kunden genutzt werden können, besonders im Software-Bereich.
• Transparenz
  Alle Teammitglieder und Stakeholder können den Fortschritt und die Prioritäten des Projekts nachvollziehen.
• Flexibilität
  Neue Anforderungen können schnell hinzugefügt und priorisiert werden.

Beispiel für ein Product Backlog

So könnte das (fiktive) Product Backlog für ein Projekt zur Entwicklung einer mobilen App zur Essenslieferung aussehen:

Benutzerregistrierung und -anmeldung

Ziel: Benutzer sollen sich registrieren und anmelden können.

• Benutzer kann sich registrieren (E-Mail, notwendige Kontaktdaten)
• Benutzer kann sich anmelden (E-Mail, Passwort)
• Benutzer kann Passwort zurücksetzen

Benutzerprofil

Ziel: Benutzer sollen ihr Profil selbst verwalten können.

• Benutzer kann Profilinformationen und Kontaktdaten bearbeiten (Name, Adresse, Telefonnummer)
• Benutzer kann ein Profilbild hochladen
• Benutzer kann bevorzugte Zahlungsmethoden speichern

Restaurantsuche und -anzeige

Ziel: Benutzer sollen nach Restaurants suchen und Informationen dazu anzeigen können.

• Benutzer kann nach Restaurants suchen (Name, Kategorie, Standort)
• Benutzer sieht detaillierte Restaurantseite (Beschreibung, Öffnungszeiten, Bewertungen)

Menü und Bestellung

Ziel: Benutzer sollen die Speisekarte eines Restaurants anzeigen und Bestellungen aufgeben können.

• Benutzer kann die Speise- und Getränkekarte eines Restaurants anzeigen
• Benutzer kann angebotene Speisen und Getränke zum Warenkorb hinzufügen
• Benutzer kann Bestellungen aufgeben
• Benutzer kann Sonderwünsche angeben (zum Beispiel: keine Zwiebeln, glutenfrei)

Bezahlung

Ziel: Benutzer sollen Bestellungen sicher und flexibel bezahlen können.

• verschiedene Zahlungsmethoden (Kreditkarte, PayPal, Apple Pay) werden unterstützt
• Zahlungsabwicklung ist sicher
• Bestellbestätigung wird angezeigt

Bestellverfolgung

Ziel: Benutzer sollen den Status ihrer Bestellung in Echtzeit verfolgen können.

• Benutzer kann den Status seiner Bestellung verfolgen (zum Beispiel in Vorbereitung, unterwegs, geliefert)
• Echtzeit-Tracking des Lieferanten ist möglich

Benachrichtigungen

Ziel: Benutzer sollen über wichtige Ereignisse und Angebote informiert werden.

• Push-Benachrichtigungen für wichtige Ereignisse (Bestellbestätigung, Statusänderungen, Sonderangebote) werden empfangen
• E-Mail-Benachrichtigungen für Bestellungen und Werbeaktionen werden empfangen

Sicherheit und Datenschutz

Ziel: Die App soll sicher und konform mit Datenschutzbestimmungen sein.

• Implementierung von SSL-Verschlüsselung
• Einhaltung der Datenschutzbestimmungen (DSGVO)
• regelmäßige Sicherheitsüberprüfungen

Beispiel einer User Story

Grundlage für das Product Backlog sind die sogenannten User Storys. Damit sind kurze, einfache Beschreibungen der Funktionalitäten oder Anforderungen aus der Perspektive des Anwenders gemeint. Eine User Story kann zum Beispiel so aussehen:

Titel:
Benutzerregistrierung

Beschreibung:
Als neuer Benutzer möchte ich mich registrieren können, damit ich auf die personalisierten Inhalte zugreifen kann.

Daraus leiten sich die Anforderungen für das Product Backlog ab:

1. Ein Registrierungsformular mit Feldern für Name, Rechnungsadresse, Lieferadresse, E-Mail und Passwort ist vorhanden.
2. Eine Bestätigungs-E-Mail wird nach erfolgreicher Registrierung versendet.
3. Fehlerhafte Eingaben werden dem Benutzer angezeigt.

Für die Realisierung dieser Anforderungen wird der Aufwand abgeschätzt:
5 Story Points

Wie erstellt man ein Product Backlog?

So gehen Sie bei der Erstellung des Product Backlogs vor:

Schritt 1: Vision und Ziele verstehen

Erstellen Sie eine klare und inspirierende Produktvision, die das langfristige Ziel des Produkts beschreibt.

Definieren Sie danach konkrete, messbare Ziele, die erreicht werden sollen, um die Vision zu verwirklichen. Halten Sie sich bei der Formulierung an die SMART-Regeln.

Schritt 2: Stakeholder identifizieren und konsultieren

Bestimmen Sie alle relevanten Stakeholder, einschließlich Kunden, Benutzer, Geschäftsführung und Entwicklungsteam.

Führen Sie Interviews, Umfragen und Workshops durch, um Anforderungen und Wünsche der Stakeholder zu sammeln.

Schritt 3: Erste Backlog-Items erstellen

Beginnen Sie mit großen Anforderungen, sogenannten Epics, und unterteilen Sie diese in Features.

Erstellen Sie aus den Features detaillierte User Stories. Jede User Story sollte folgendes Format haben: „Als [Benutzertyp] möchte ich [Ziel/Wunsch], damit [Nutzen].“

Leiten Sie aus den User Storys die Anforderungen (Features, Funktionen, Produktmerkmale) ab, die ins Product Backlog kommen. Das sind die einzelnen Backlog-Items.

Schritt 4: Backlog-Items priorisieren

Bewerten Sie jedes Backlog-Item basierend auf dem geschäftlichen Wert und dem geschätzten Aufwand.

Verwenden Sie Techniken wie MoSCoW (Must, Should, Could, Won't), die Eisenhower-Matrix oder das Kano-Modell zur Priorisierung.

Ordnen Sie die Backlog-Items nach Priorität. Die wichtigsten und wertvollsten Items kommen ganz nach oben auf Ihrem Product Backlog.

Schritt 5: Detaillierung und Aufwandsschätzung

Definieren Sie klare Akzeptanzkriterien für jedes Backlog-Item, die beschreiben, wann das Item als fertig gilt; die Definition of Done.

Lassen Sie das Entwicklungsteam jeden Eintrag auf dem Product Backlog schätzen, zum Beispiel mit Story Points oder notwendigen Arbeitsstunden.

Regelmäßige Pflege und Aktualisierung

Achten Sie darauf, dass das Product Backlog immer auf dem allerneuesten Stand ist, indem Sie:

• das Product Backlog regelmäßig überprüfen, mindestens vor jedem Sprint Planning Meeting;
• Feedback von Stakeholdern und dem Entwicklungsteam kontinuierlich in das Backlog integrieren und
• regelmäßige Backlog Refinement Meetings (auch: Grooming) abhalten, um die Backlog-Items weiter zu verfeinern und neu zu priorisieren.

Welche Tools eignen sich für ein Product Backlog?

In der Regel benötigen Sie Tools, um das Product Backlog zugänglich und nutzbar zu machen und Software, mit der Sie den Status visualisieren.

Um das Product Backlog zu pflegen und für das Team zugänglich zu machen, nutzen Sie Backlog-Management-Tools wie:

• Jira
• Trello
• Asana

Zur Visualisierung nutzen Sie Kanban-Boards oder andere Visualisierungstechniken, um den Status der Backlog-Items und deren Fortschritt sichtbar zu machen.

Wie werden Einträge im Product Backlog priorisiert?

Die Priorisierung der Einträge im Product Backlog erfolgt anhand mehrerer Kriterien:

• Geschäftswert: Wie viel Wert bringt die Umsetzung der Aufgabe für das Unternehmen?
• Dringlichkeit: Gibt es Fristen oder externe Abhängigkeiten, die die Dringlichkeit erhöhen?
• Risiko: Wie risikobehaftet ist die Aufgabe und kann sie andere Aufgaben blockieren?
• Komplexität: Wie komplex ist die Umsetzung und wie hoch ist der geschätzte Aufwand?

Wie oft sollte das Product Backlog aktualisiert werden?

Das Product Backlog wird regelmäßig aktualisiert, um sicherzustellen, dass es immer den aktuellen Prioritäten und Anforderungen entspricht.

Überprüfen Sie es mindestens einmal pro Sprint, zum Beispiel im Zuge der Sprint-Planung oder im Backlog Refinement Meeting. Das bedeutet, dass Sie etwa einmal pro Woche das Product Backlog prüfen und bei Bedarf aktualisieren. Letztlich hängt die Häufigkeit der Aktualisierung vom Umfang und von der Komplexität der jeweils bearbeiteten Aufgaben ab.

Als Product Owner sollten Sie außerdem kontinuierlich Feedback von Stakeholdern und dem Entwicklungsteam einholen und das Backlog entsprechend anpassen.

Wie bereinigen Sie ein überfrachtetes Product Backlog?

Ein überfrachtetes Product Backlog kann durch verschiedene Maßnahmen bereinigt werden. Zunächst kann die Archivierung älterer oder weniger wichtiger Einträge helfen, das Backlog zu entschlacken. Diese Einträge können entweder archiviert oder vollständig gelöscht werden, um Platz für relevantere Items zu schaffen.

Ein weiterer Schritt ist die Kategorisierung, bei der Einträge in thematische Kategorien oder größere Epics zusammengefasst werden. Dies erleichtert die Übersicht und priorisiert die Arbeit. (Epics sind große, übergeordnete User Storys im Product Backlog, die umfangreiche Funktionen oder Anforderungen beschreiben und in kleinere, detailliertere User Stories unterteilt werden können.)

Zudem sind regelmäßige Reviews durch Sie als Product Owner unerlässlich. Diese regelmäßigen Überprüfungen und Bereinigungen stellen sicher, dass das Backlog aktuell bleibt und nur die wichtigsten und relevanten Einträge enthält.

Wie misst man den Erfolg eines Product Backlogs?

Der Erfolg eines Product Backlogs wird gemessen anhand:

• der Erfüllung der Geschäftsziele,
• der Kundenzufriedenheit,
• der Produktivität des Teams und
• der Flexibilität.

Was sind die häufigsten Fehler bei der Verwaltung eines Product Backlogs?

Zu den häufigsten Problemen gehören:

• Überfrachtung: Ein zu großes Backlog kann unübersichtlich werden und die Priorisierung erschweren.
• unklare Prioritäten: Wenn die Prioritäten nicht klar sind, kann das Team nicht effizient arbeiten.
• mangelnde Pflege: Ein veraltetes Backlog spiegelt nicht die aktuellen Anforderungen und Prioritäten wider.
• Kommunikationsprobleme: Missverständnisse zwischen dem Product Owner, dem Entwicklungsteam und den Stakeholdern können zu Unstimmigkeiten führen.