Bibliotheken suchen kontinuierlich nach innovativen Wegen, ihre Dienstleistungen zu verbessern und die sich ständig verändernden Bedürfnisse ihrer Nutzer zu erfüllen. Um dies zu erreichen, wenden sich viele Bibliotheken Agile-Methoden des Projektmanagements zur Steuerung der Systementwicklung an. Ein entscheidender Bestandteil jedes Agile-Projekts ist ein gut verwaltetes Produkt-Backlog, das als priorisierte Liste von Funktionen und Funktionalitäten dient, die die Bibliothek umsetzen möchte.
Dieser Artikel untersucht Best Practices für die Planung des Produkt-Backlogs speziell für Bibliotheken, einschließlich der Einbeziehung von Stakeholdern während des gesamten Prozesses, der Sicherstellung von Transparenz und Sichtbarkeit des Backlogs sowie der regelmäßigen Überprüfung und Anpassung der Prioritäten, um eine Ausrichtung an der Gesamtvision des Produkts und den geschäftlichen Zielen der Bibliothek sicherzustellen.
Durch die Einhaltung dieser Best Practices können Product Owners ein Produkt-Backlog entwickeln, das die Bedürfnisse und Erwartungen ihrer Mitarbeiter und Nutzer genau widerspiegelt, und letztendlich ein hochwertiges Produkt liefern, das deren Anforderungen erfüllt.
Was ist ein Produkt-Backlog?
Ein Produkt-Backlog ist eine priorisierte Liste von Funktionen, Verbesserungen und Fehlern, die in einem Softwareprodukt behoben werden müssen. Er ist die primäre Quelle für Anforderungen für das Entwicklungsteam und dient zur Steuerung des Entwicklungsprozesses.
Der Produkt-Backlog dient als dynamisches und ständig sich entwickelndes Dokument, das die Arbeit beschreibt, die erledigt werden muss, um das Softwareprodukt zu liefern. Er ist ein unverzichtbares Werkzeug für agile Entwicklungsteams, da er sicherstellt, dass alle Beteiligten sich auf die Ziele und Prioritäten des Projekts einigen.
Der Produkt-Backlog enthält typischerweise Elemente wie neue Funktionen, Verbesserungen bestehender Funktionen, Fehlerbehebungen, technische Schulden und andere Aufgaben, die notwendig sind, um ein hochwertiges Produkt zu liefern. Diese Elemente werden meist in Form von Nutzerstories beschrieben, die die Bedürfnisse und Anforderungen der Endnutzer erfassen.
Wer ist für den Produkt-Backlog verantwortlich?
Es ist wichtig, klarzustellen, wer für die Verwaltung des Produkt-Backlogs verantwortlich ist. In den meisten Fällen ist der Product Owner für die Erstellung und Pflege des Produkt-Backlogs verantwortlich. Allerdings können auch das Entwicklungsteam und andere Stakeholder zum Backlog beitragen.
- Das Product Ownerist in der Regel die Person, die für die Erstellung, Priorisierung und Pflege des Produkt-Backlogs verantwortlich ist. Dies bedeutet jedoch nicht, dass der Product Owner allein arbeitet. Tatsächlich ist es wichtig, dass der Product Owner mit dem Entwicklungsteam, den Stakeholdern und anderen Mitgliedern der Organisation zusammenarbeitet, um sicherzustellen, dass der Produkt-Backlog mit der Gesamtvision des Produkts und den geschäftlichen Zielen übereinstimmt.
- Das Entwicklungsteam, kann beispielsweise Beiträge zur technischen Umsetzbarkeit bestimmter Funktionen leisten oder alternative Lösungen vorschlagen, die dasselbe Ziel erreichen können. Stakeholder wie Kunden oder Endnutzer können Feedback zur Benutzerfreundlichkeit oder zum Wert bestimmter Funktionen geben. Durch die Einbeziehung dieser unterschiedlichen Perspektiven und Erkenntnisse kann der Product Owner sicherstellen, dass der Produkt-Backlog umfassend, gut informiert und den Bedürfnissen der Organisation entspricht.
Wie erstellt man einen Produkt-Backlog?
Erklären Sie die Schritte zur Erstellung eines Produkt-Backlogs, einschließlich der Erfassung von Anforderungen, der Priorisierung von Funktionen und der Aufteilung großer Funktionen in kleinere Nutzerstories. Es ist auch wichtig, zu erörtern, wie sichergestellt wird, dass der Produkt-Backlog mit der Gesamtvision des Produkts und den geschäftlichen Zielen übereinstimmt.
Hier sind die Schritte zur Erstellung eines Produkt-Backlogs:
- Anforderungen sammeln:Der erste Schritt bei der Erstellung eines Produkt-Backlogs besteht darin, Anforderungen von Stakeholdern, Kunden und anderen Quellen zu sammeln. Dazu gehört das Verständnis der Bedürfnisse und Ziele des Produkts sowie möglicher Einschränkungen oder Beschränkungen, die die Entwicklung beeinflussen könnten. Anforderungen können durch verschiedene Techniken wie Interviews, Umfragen, Fokusgruppen oder Nutzer-Tests gesammelt werden.
- Funktionen priorisieren:Sobald die Anforderungen gesammelt wurden, folgt der nächste Schritt: die Priorisierung der Funktionen basierend auf ihrer Bedeutung für die Produktvision und die geschäftlichen Ziele. Der Product Owner sollte eng mit den Stakeholdern zusammenarbeiten, um festzustellen, welche Funktionen für den Erfolg des Produkts entscheidend sind und welche verschoben oder weggelassen werden können. Verschiedene Priorisierungstechniken wie MoSCoW, Kano oder ROI-basierte Priorisierung können bei diesem Prozess hilfreich sein.
- Große Funktionen in kleinere Nutzerstories aufteilen:Sobald die Funktionen priorisiert wurden, sollte der Product Owner die größeren Funktionen in kleinere, besser handhabbare Nutzerstories aufteilen. Nutzerstories sind kurze, einfache Beschreibungen einer Funktion oder Funktionalität, die die Perspektive des Nutzers widerspiegeln. Die Aufteilung von Funktionen in Nutzerstories macht sie greifbarer und leichter umsetzbar und stellt sicher, dass sie den Bedürfnissen der Endnutzer entsprechen.
- Orientieren Sie den Produkt-Backlog an der Gesamtvision des Produkts und den geschäftlichen Zielen:Es ist wichtig sicherzustellen, dass der Produkt-Backlog mit der Gesamtvision des Produkts und den geschäftlichen Zielen übereinstimmt. Der Product Owner sollte den Produkt-Backlog regelmäßig überprüfen und aktualisieren, um sicherzustellen, dass er weiterhin relevant ist und darauf abzielt, Wert für den Kunden zu liefern. Der Product Owner sollte außerdem eng mit den Stakeholdern und dem Entwicklungsteam zusammenarbeiten, um sicherzustellen, dass alle sich auf die Produktvision einigen und der Produkt-Backlog dazu beiträgt, diese Vision zu verwirklichen.
- Wie man den Produkt-Backlog pflegt:Die Erstellung eines Produkt-Backlogs ist erst der Anfang. Es ist wichtig, den Backlog regelmäßig zu überprüfen und zu aktualisieren, um sicherzustellen, dass er weiterhin relevant und an der Produktvision ausgerichtet ist. Diskutieren Sie Strategien zur Durchführung von Backlog-Grooming-Sitzungen, zur Behandlung von Änderungen der Prioritäten und zur Bewältigung technischer Schulden.
- Best Practices für die Planung des Produkt-Backlogs:Schließen Sie den Artikel ab, indem Sie einige Best Practices für die Planung des Produkt-Backlogs zusammenfassen, wie beispielsweise die Einbeziehung von Stakeholdern in den Prozess, die Sichtbarkeit und Transparenz des Backlogs sowie die regelmäßige Überprüfung und Anpassung der Prioritäten.
Die Planung des Produkt-Backlogs liefert wertvolle Erkenntnisse und Anleitungen für agile Teams, die daran arbeiten, ihren Entwicklungsprozess zu verbessern. Durch die Einhaltung dieser Schritte kann der Product Owner ein umfassendes und gut priorisiertes Produkt-Backlog erstellen, das mit der Gesamtvision des Produkts und den Geschäftszielen übereinstimmt. Dies kann dazu beitragen, dass das Entwicklungsteam sich auf die Lieferung der wertvollsten Funktionen und Features konzentriert und dass das Produkt die Bedürfnisse und Erwartungen der Kunden erfüllt.
Beispiel – Bibliotheks-System
Problembeschreibung
Die örtliche öffentliche Bibliothek steht vor mehreren Herausforderungen bei der Verwaltung ihrer Sammlung an Büchern und anderen Materialien. Die Bibliothek verwendet derzeit ein manuelles System, um ihre Bestände zu verfolgen, was zeitaufwendig und fehleranfällig ist. Bibliotheksmitarbeiter verbringen eine erhebliche Zeit damit, Bücher manuell auszuleihen und zurückzunehmen, und es gibt keine Möglichkeit, einfach zu verfolgen, welche Bücher verfügbar oder überfällig sind.
Zusätzlich hat die Bibliothek Mühe, den sich verändernden Bedürfnissen und Erwartungen der Nutzer gerecht zu werden. Viele Kunden erwarten heute, Bibliotheksressourcen online zugänglich zu haben, und das aktuelle System unterstützt keine Online-Buchungen, Verlängerungen oder andere Funktionen, die für Bibliotheksbenutzer zunehmend wichtig werden.
1. Anforderungen sammeln
Um Anforderungen für das Bibliotheks-System zu sammeln, könnte das Entwicklungsteam zunächst Interviews mit Bibliotheksmitarbeitern, einschließlich Bibliothekarinnen und Bibliothekare, Bedienungspersonal und IT-Mitarbeitern, durchführen. In diesen Gesprächen kann das Team Fragen zum aktuellen System, dessen Stärken und Schwächen sowie zu den täglichen Problemen, mit denen das Personal konfrontiert ist, stellen. Außerdem kann das Team nach den Zielen und Zielen der Bibliothek sowie nach möglichen Einschränkungen oder Beschränkungen fragen, die die Entwicklung des neuen Systems beeinflussen könnten.
Das Team könnte auch Umfragen oder Fokusgruppen mit Bibliotheksbenutzern durchführen, um deren Bedürfnisse und Erwartungen besser zu verstehen. Die Umfragen könnten Fragen zum aktuellen System, dessen Nützlichkeit und Grenzen sowie zu den Vorlieben der Nutzer hinsichtlich neuer Funktionen und Features enthalten. Die Fokusgruppen könnten ein tieferes Verständnis für die Bedürfnisse und Probleme der Nutzer sowie die Benutzererfahrung beim Einsatz des Bibliotheks-Systems liefern.
Schließlich könnte das Team Benutzer-Tests durchführen, um Erkenntnisse über die Benutzerfreundlichkeit und Funktionalität des aktuellen Systems zu gewinnen und Bereiche zur Verbesserung zu identifizieren. Die Benutzer-Tests könnten das Beobachten der Benutzer während ihrer Interaktion mit dem System, die Durchführung von Umfragen oder Interviews nach dem Test und die Sammlung von Feedback zu bestimmten Funktionen oder Funktionen beinhalten.
Durch die Sammlung von Anforderungen mit diesen verschiedenen Techniken kann das Entwicklungsteam ein umfassendes Verständnis der Bedürfnisse und Ziele des Bibliotheks-Systems sowie der Bedürfnisse und Erwartungen seiner Nutzer erlangen. Diese Informationen können genutzt werden, um ein Produkt-Backlog zu erstellen, das die wichtigsten Funktionen und Funktionen priorisiert und mit den Gesamtzielen und Zielen der Bibliothek übereinstimmt.
2. Funktionen priorisieren
Aufgrund der für das Bibliotheks-System gesammelten Anforderungen kann das Entwicklungsteam und der Product Owner mit der Priorisierung der Funktionen beginnen, die im Produkt-Backlog enthalten sein sollen. Hier sind einige mögliche Funktionen und ihre Priorisierung:
- Automatisierte Ein- und Ausgabe von Büchern – Hohe Priorität. Diese Funktion kann die Bibliotheksoperationen vereinfachen und die Arbeitsbelastung der Bibliotheksmitarbeiter reduzieren.
- Echtzeit-Verfügbarkeitsinformationen für Bücher und andere Materialien – Hohe Priorität. Diese Funktion kann die Benutzererfahrung verbessern, indem sie genaue und aktuelle Informationen über die Verfügbarkeit von Materialien bereitstellt.
- Online-Buchungen, Verlängerungen und Reservierungen – Hohe Priorität. Diese Funktion kann den Nutzern einen bequemeren Zugang zu Bibliotheksressourcen ermöglichen und die Notwendigkeit von persönlichen Besuchen in der Bibliothek reduzieren.
- Integration mit der Bibliotheks-Website und der mobilen App – Hohe Priorität. Diese Funktion kann eine nahtlose Benutzererfahrung bieten, indem sie Nutzern ermöglicht, über ihre bevorzugten Geräte auf Bibliotheksressourcen zuzugreifen.
- Detaillierte Berichte und Analysen – Mittlere Priorität. Diese Funktion kann den Bibliotheksmitarbeitern helfen, die Bibliotheksbestände besser zu verwalten und Ressourcen effizienter zu verteilen.
- Anpassbare Benutzerprofile – Niedrige Priorität. Obwohl diese Funktion eine persönlichere Benutzererfahrung ermöglichen kann, ist sie möglicherweise nicht entscheidend für den Erfolg des Produkts.
Die Priorisierung dieser Funktionen kann mit verschiedenen Techniken wie MoSCoW oder Kano erfolgen. Zum Beispiel könnte das Team die MoSCoW-Priorisierung verwenden, um Funktionen als „Muss-haben“, „Soll-haben“, „Könnte-haben“ oder „Wird-nicht-haben“ zu kategorisieren.
Alternativ könnte das Team die Kano-Priorisierung verwenden, um Funktionen als „Muss-sein“, „Leistung“, „Anziehend“, „Gleichgültig“ oder „Umgekehrt“ zu kategorisieren. Der Product Owner kann eng mit den Stakeholdern zusammenarbeiten, um die am besten geeignete Priorisierungstechnik zu bestimmen und sicherzustellen, dass die Priorisierung mit der Gesamtvision des Produkts und den Geschäftszielen übereinstimmt.
Zusammenfassung Ihrer Erkenntnisse
Hier ist ein Beispiel für eine Tabelle, um die priorisierten Funktionen für das Bibliotheks-System darzustellen:
| Funktion | Priorität |
|---|---|
| Automatisierter Ein- und Auscheck von Büchern | Hoch |
| Echtzeit-Verfügbarkeitsinformationen für Materialien | Hoch |
| Online-Buchungen, Verlängerungen und Reservierungen | Hoch |
| Integration mit der Bibliotheks-Website und der mobilen App | Hoch |
| Detaillierte Berichterstattung und Analyse | Mittel |
| Anpassbare Benutzerprofile | Niedrig |
Priorisieren und Aufwand schätzen
In dieser Tabelle sind die Funktionen in der ersten Spalte aufgelistet, und ihre Priorität in der zweiten Spalte. Die Priorität wird als hoch, mittel oder niedrig kategorisiert, abhängig von ihrer Bedeutung für die Gesamtvision des Produkts und die Geschäftsziele. Die Tabelle bietet eine klare und präzise Möglichkeit, die priorisierten Funktionen für das Bibliothekssystem darzustellen, sodass Stakeholder und das Entwicklungsteam leicht verstehen können, welche Funktionen am wichtigsten sind, um sie in das Produkt-Backlog aufzunehmen.
Hier ist ein Beispiel für eine Tabelle, um die priorisierten Funktionen für das Bibliothekssystem mit einer zusätzlichen Spalte für Story Points darzustellen:
| Funktion | Priorität | Story Point |
|---|---|---|
| Automatisierter Ein- und Auscheck von Büchern | Hoch | 3 |
| Echtzeit-Verfügbarkeitsinformationen für Materialien | Hoch | 5 |
| Online-Buchungen, Verlängerungen und Reservierungen | Hoch | 8 |
| Integration mit der Bibliotheks-Website und der mobilen App | Hoch | 13 |
| Detaillierte Berichterstattung und Analytik | Mittel | 5 |
| Anpassbare Benutzerprofile | Niedrig | 2 |
In dieser Tabelle wurde die Spalte „Story Points“ hinzugefügt, um das Aufwandniveau für die Umsetzung jeder Funktion zu quantifizieren. Story Points werden im agilen Entwicklungsprozess verwendet, um die Arbeitsmenge abzuschätzen, die erforderlich ist, um eine Benutzerstory abzuschließen. Die Schätzung der Story Points basiert auf Faktoren wie Komplexität, Aufwand und Risiko. In diesem Beispiel basieren die Story Point-Schätzungen auf der Erfahrung und dem Wissen des Teams bezüglich des Bibliothekssystems.
Was ist eine Story Point
Die Schätzungen der Story Points können helfen, die Arbeit des Entwicklungsteams zu planen und festzustellen, was in jedem Sprint oder jeder Iteration erreicht werden kann. Je höher die Schätzung der Story Points, desto mehr Aufwand und Zeit sind erforderlich, um die entsprechende Funktion abzuschließen. Durch die Aufnahme der Story Point-Schätzungen in die Tabelle können Stakeholder und das Entwicklungsteam ein besseres Verständnis für das erforderliche Aufwandniveau bei der Umsetzung jeder Funktion erlangen und fundiertere Entscheidungen über die Prioritäten des Produkt-Backlogs treffen.
3. Zerlegen großer Features in kleinere Benutzerstories
Aufgrund der priorisierten Features für das Bibliothekssystem kann der Product Owner jedes Feature in kleinere Benutzerstories aufteilen. Hier sind einige mögliche Benutzerstories für jedes Feature:
- Automatisierter Ein- und Ausgabevorgang für Bücher:
- Als Bibliotheksmitarbeiter möchte ich in der Lage sein, den Barcode eines Buches zu scannen, um es auszuleihen oder zurückzugeben, damit ich Zeit spare und Fehler vermeide.
- Als Bibliotheksbenutzer möchte ich in der Lage sein, ein Buch über einen Selbstbedienungskiosk auszuleihen, damit ich Zeit spare und nicht in der Schlange warten muss.
- Echtzeit-Verfügbarkeitsinformationen für Materialien:
- Als Bibliotheksbenutzer möchte ich in der Lage sein, die Verfügbarkeit eines Buches oder anderen Materials in Echtzeit zu sehen, damit ich meinen Besuch in der Bibliothek effizienter planen kann.
- Als Bibliotheksmitarbeiter möchte ich in der Lage sein, die Verfügbarkeit eines Buches oder anderen Materials in Echtzeit zu aktualisieren, damit Benutzer über die genaue Verfügbarkeit informiert sind.
- Online-Buchungen, Verlängerungen und Reservierungen:
- Als Bibliotheksbenutzer möchte ich in der Lage sein, ein Buch online zu reservieren, damit ich sicherstellen kann, dass es bei meinem Besuch in der Bibliothek verfügbar ist.
- Als Bibliotheksbenutzer möchte ich in der Lage sein, ein Buch online zu verlängern, damit ich Strafgebühren vermeide und das Buch länger behalten kann.
- Als Bibliotheksbenutzer möchte ich in der Lage sein, eine Reservierung für ein Buch zu platzieren, das derzeit ausgeliehen ist, damit ich benachrichtigt werde, sobald es verfügbar ist.
- Integration mit der Bibliotheks-Website und der mobilen App:
- Als Bibliotheksbenutzer möchte ich in der Lage sein, über die Bibliotheks-Website oder die mobile App auf meine Kontoinformationen (z. B. ausgeliehene Artikel, Fälligkeitsdaten) zuzugreifen, damit ich mein Bibliotheks-Konto einfacher verwalten kann.
- Als Bibliotheksbenutzer möchte ich in der Lage sein, über die Bibliotheks-Website oder die mobile App nach Büchern zu suchen und sie zu reservieren, damit ich dies bequem von zu Hause aus tun kann.
- Detaillierte Berichterstattung und Analytik:
- Als Bibliotheksmitarbeiter möchte ich in der Lage sein, Berichte über die Bibliotheksbestände zu erstellen (z. B. beliebteste Bücher, ausgeliehene Artikel nach Abteilung), damit ich fundierte Entscheidungen über die Ressourcenallokation und die Bestandsverwaltung treffen kann.
- Anpassbare Benutzerprofile:
- Als Bibliotheksbenutzer möchte ich in der Lage sein, mein Bibliotheks-Konto anzupassen (z. B. bevorzugte Benachrichtigungsmethoden), damit ich eine persönlichere Erfahrung habe.
Durch die Aufteilung der Features in kleinere Benutzerstories kann der Product Owner ein detaillierteres und umsetzbares Produkt-Backlog erstellen, das den Bedürfnissen und Erwartungen der Endbenutzer entspricht. Die Benutzerstories können als Grundlage für Entwicklungsaufgaben dienen und dazu beitragen, dass das Entwicklungsteam Funktionen erstellt, die die Bedürfnisse der Benutzer auf greifbare und konkrete Weise erfüllen.
Fassen Sie die Funde in einer Tabelle zusammen
Hier ist ein Beispiel für eine Tabelle, die die Priorität und Story Points für die Benutzerstories enthält:
| Funktion | Priorität | Story Point |
|---|---|---|
| Automatisierter Ein- und Ausgabevorgang von Büchern – Personal | Hoch | 3 |
| Automatisierter Ein- und Ausgabevorgang von Büchern – Selbstbedienung | Hoch | 5 |
| Echtzeit-Verfügbarkeitsinformationen für Materialien | Hoch | 8 |
| Online-Buchungen | Hoch | 8 |
| Online-Verlängerungen | Hoch | 5 |
| Legen Sie eine Sperrung für ein ausgeliehenes Buch an | Hoch | 5 |
| Kontoinformationen auf der Bibliotheks-Website/App | Hoch | 5 |
| Suchen und reservieren Sie Bücher auf der Website/App | Hoch | 8 |
| Berichte über die Bibliotheksbestände | Mittel | 13 |
| Anpassbare Benutzerprofile | Niedrig | 3 |
Diese Tabelle listet die Benutzerstories auf, die für jedes Feature erstellt wurden, zusammen mit ihrer Priorität und den Story-Point-Schätzungen. Die Feature-Prioritäten basieren auf der Priorisierung der Features durch den Product Owner, während die Story-Point-Schätzungen auf dem geschätzten Aufwand basieren, der für die Umsetzung jedes Benutzerstorys erforderlich ist.
Das Entwicklungsteam kann diese Tabelle nutzen, um seine Arbeit zu planen und festzustellen, was in jedem Sprint oder jeder Iteration erreicht werden kann. Je höher die Story-Point-Schätzung ist, desto mehr Aufwand und Zeit sind erforderlich, um die entsprechende Benutzerstory abzuschließen. Die Tabelle kann auch zur Verfolgung des Fortschritts verwendet werden, um sicherzustellen, dass das Entwicklungsteam kontinuierlich Fortschritte bei der Abwicklung jedes Benutzerstories und jedes Features macht.
Wie man die Story Points überarbeitet: Was sind die Kriterien?
Die Story-Point-Schätzungen für die Features können sich nach dem Break-Down-Prozess verändert haben, da die Benutzerstories eine detailliertere und feinere Sicht auf die Arbeit bieten, die zur Umsetzung jedes Features erforderlich ist. Hier sind einige Faktoren, die die Änderung der Story-Point-Schätzungen beeinflussen könnten:
- Komplexität: Die Benutzerstories könnten zusätzliche Komplexitäten aufgedeckt haben, die bei der ursprünglichen Priorisierung der Features nicht erkennbar waren. Zum Beispiel könnte die Benutzerstory für Online-Buchungen die Notwendigkeit eines E-Mail-Benachrichtigungssystems aufgedeckt haben, die ursprünglich bei der Feature-Priorisierung nicht berücksichtigt wurde. Diese zusätzliche Komplexität könnte die Story-Point-Schätzung erhöht haben.
- Aufwand: Die Benutzerstories bieten eine detailliertere Sicht auf den Aufwand, der zur Umsetzung jedes Features erforderlich ist. Zum Beispiel könnte die Benutzerstory für Echtzeit-Verfügbarkeitsinformationen die Notwendigkeit einer neuen Datenbank oder eines API zur Verfolgung der Verfügbarkeit von Materialien aufgedeckt haben. Dieser zusätzliche Aufwand könnte die Story-Point-Schätzung erhöht haben.
- Risiko: Die Benutzerstories könnten zusätzliche Risiken identifiziert haben, die bei der ursprünglichen Priorisierung der Features nicht erkennbar waren. Zum Beispiel könnte die Benutzerstory für die automatisierte Ein- und Ausgabe von Büchern die Notwendigkeit umfangreicher Tests aufgedeckt haben, um sicherzustellen, dass das neue System keine Fehler oder Ungenauigkeiten verursacht. Dieses zusätzliche Risiko könnte die Story-Point-Schätzung erhöht haben.
Der Break-Down-Prozess bietet eine detailliertere und nuanciertere Sicht auf die Arbeit, die zur Umsetzung jedes Features erforderlich ist. Die Story-Point-Schätzungen können sich ändern, je besser das Entwicklungsteam das Verständnis für die Komplexitäten, den Aufwand und die Risiken jedes Benutzerstories gewinnt. Durch die kontinuierliche Verbesserung der Story-Point-Schätzungen auf Basis der Erfahrung und des Wissens des Entwicklungsteams kann der Product Owner sicherstellen, dass das Product Backlog die tatsächlich erforderliche Arbeitsmenge für die Lieferung der gewünschten Features und Funktionen genau widerspiegelt.
4. Das Product Backlog mit Vision und Zielen ausrichten
Um das Product Backlog mit der Gesamtvision und den Geschäftszielen für das Bibliotheks-System auszurichten, kann der Product Owner die folgenden Schritte unternehmen:
- Überprüfen und Aktualisieren des Product Backlogs: Der Product Owner sollte das Product Backlog regelmäßig überprüfen und aktualisieren, um sicherzustellen, dass es weiterhin relevant und mit der Produktvision und den Geschäftszielen ausgerichtet ist. Dazu gehören das Entfernen von Benutzerstories, die nicht mehr relevant oder notwendig sind, das Hinzufügen neuer Benutzerstories, die der Produktvision dienen, und das Neu-Priorisieren des Backlogs bei Bedarf.
- Fokus auf die Lieferung von Wert für den Kunden: Der Product Owner sollte sicherstellen, dass das Product Backlog auf die Lieferung von Wert für den Kunden ausgerichtet ist. Das bedeutet, Benutzerstories zu priorisieren, die direkt zur Erfahrung und Zufriedenheit des Kunden beitragen, und Benutzerstories, die keinen signifikanten Wert liefern, zu de-priorisieren oder zu entfernen.
- Eng mit den Stakeholdern zusammenarbeiten: Der Product Owner sollte eng mit den Stakeholdern, einschließlich des Bibliotheks-Personals und der Nutzer, zusammenarbeiten, um sicherzustellen, dass das Product Backlog ihren Bedürfnissen und Erwartungen entspricht. Dazu gehört das regelmäßige Einholen von Feedback und dessen Einbeziehung in das Product Backlog.
- Die Produktvision kommunizieren: Der Product Owner sollte die Produktvision und die Geschäftsziele dem Entwicklungsteam und den Stakeholdern kommunizieren, um sicherzustellen, dass alle sich an der Vision ausrichten und verstehen, wie ihre Arbeit dazu beiträgt. Dazu gehören regelmäßige Updates und Fortschrittsberichte sowie die Sicherstellung, dass alle über Änderungen oder Aktualisierungen im Product Backlog informiert sind.
Durch die Umsetzung dieser Schritte kann der Product Owner sicherstellen, dass das Product Backlog mit der Gesamtvision und den Geschäftszielen ausgerichtet ist und darauf fokussiert ist, Wert für den Kunden zu liefern. Dies hilft sicherzustellen, dass das Entwicklungsteam Funktionen und Features entwickelt, die den Bedürfnissen und Erwartungen des Bibliotheks-Personals und der Nutzer entsprechen, und dass das Produkt erfolgreich seine vorgesehene Aufgabe erfüllt.
5. Wie man das Product Backlog pflegt
Um das Produkt-Backlog für das Bibliothekssystem aufrechtzuerhalten, kann der Product Owner die folgenden Schritte unternehmen:
- Planen Sie regelmäßige Backlog-Pflegesitzungen:Der Product Owner sollte regelmäßige Backlog-Pflegesitzungen mit dem Entwicklerteam planen, um das Produkt-Backlog zu überprüfen und zu aktualisieren. Dazu gehören die Priorisierung von Benutzerstories basierend auf ihrer Bedeutung, die Aufteilung größerer Benutzerstories in kleinere, besser handhabbare, sowie das Entfernen oder Herabstufen von Benutzerstories, die nicht mehr notwendig sind.
- Umgang mit Änderungen der Prioritäten:Der Product Owner sollte bereit sein, Änderungen der Prioritäten entgegenzunehmen, sobald sie auftreten. Dazu gehört, offen für Feedback von Stakeholdern zu sein und das Produkt-Backlog entsprechend anzupassen, sowie Benutzerstories basierend auf sich verändernden geschäftlichen Bedürfnissen und Zielen neu zu priorisieren.
- Behandlung von technischem Schuldenstand:Technischer Schuldenstand bezeichnet die Ansammlung technischer Probleme, die die Entwicklung verlangsamen und die Qualität des Produkts beeinträchtigen können. Der Product Owner sollte die Behandlung technischer Schulden als Teil des Backlog-Pflegeprozesses priorisieren und eng mit dem Entwicklerteam zusammenarbeiten, um technische Probleme zu identifizieren und zu beheben, sobald sie auftreten.
- Verfolgung des Fortschritts und Kommunikation von Aktualisierungen:Der Product Owner sollte den Fortschritt im Produkt-Backlog verfolgen und Aktualisierungen an Stakeholder und das Entwicklerteam kommunizieren. Dazu gehören die regelmäßige Bereitstellung von Fortschrittsberichten, die Aktualisierung des Backlogs bei Bedarf und die Sicherstellung, dass alle über Änderungen oder Aktualisierungen in der Produktvision oder den Geschäftszielen informiert sind.
Durch die Umsetzung dieser Strategien kann der Product Owner sicherstellen, dass das Produkt-Backlog relevant bleibt und mit der Produktvision und den Geschäftszielen übereinstimmt. Regelmäßige Backlog-Pflegesitzungen helfen sicherzustellen, dass das Backlog ordnungsgemäß priorisiert und verwaltet wird, während die Behandlung technischer Schulden dafür sorgt, dass das Produkt von hoher Qualität ist und effizient entwickelt werden kann. Die Verfolgung des Fortschritts und die Kommunikation von Aktualisierungen helfen sicherzustellen, dass alle sich auf der Produktvision ausrichten und verstehen, wie ihre Arbeit dazu beiträgt.
6. Best Practices für die Planung des Produkt-Backlogs
Hier sind einige Best Practices für die Planung des Produkt-Backlogs für das Bibliothekssystem:
- Einbeziehung von Stakeholdern in den Prozess:Es ist wichtig, Stakeholder, einschließlich des Bibliothekspersonals und der Nutzer, in den Prozess der Planung des Produkt-Backlogs einzubeziehen. Dies hilft sicherzustellen, dass das Backlog ihren Bedürfnissen und Erwartungen entspricht und dass das Produkt erfolgreich seine vorgesehene Aufgabe erfüllt.
- Halten Sie das Backlog sichtbar und transparent:Das Produkt-Backlog sollte für alle Stakeholder und das Entwicklerteam sichtbar und transparent sein. Dies hilft sicherzustellen, dass alle sich auf der Produktvision ausrichten und Fortschritte in Richtung der Erreichung der Geschäftsziele gemacht werden.
- Priorisierung basierend auf Wert:Priorisieren Sie Benutzerstories basierend auf ihrem Wert für den Kunden und das Unternehmen. Dies hilft sicherzustellen, dass das Entwicklerteam Funktionen und Features entwickelt, die dem Bibliothekspersonal und den Nutzern den größtmöglichen Wert bringen.
- Regelmäßige Überprüfung und Anpassung der Prioritäten:Der Product Owner sollte die Backlog-Prioritäten regelmäßig überprüfen und anpassen, basierend auf sich verändernden geschäftlichen Bedürfnissen und Zielen. Dies hilft sicherzustellen, dass das Backlog relevant bleibt und mit der Produktvision übereinstimmt.
- Große Benutzerstories in kleinere aufteilen:Die Aufteilung größerer Benutzerstories in kleinere, besser handhabbare hilft, sie greifbarer und einfacher umzusetzen. Dies hilft sicherzustellen, dass das Entwicklerteam Funktionen entwickelt, die die Bedürfnisse der Nutzer konkret erfüllen.
- Behandlung von technischem Schuldenstand:Priorisieren Sie die Behandlung technischer Schulden als Teil des Backlog-Pflegeprozesses. Dies hilft sicherzustellen, dass das Produkt von hoher Qualität ist und effizient entwickelt werden kann.
Durch die Einhaltung dieser Best Practices kann der Product Owner sicherstellen, dass das Produkt-Backlog ordnungsgemäß priorisiert und verwaltet wird und dass das Entwicklerteam Funktionen und Features entwickelt, die den Bedürfnissen und Erwartungen des Bibliothekspersonals und der Nutzer entsprechen.
Zusammenfassung
Die Planung des Produkt-Backlogs ist ein entscheidender Prozess für Bibliotheken, um die Produktentwicklung zu priorisierenEntwicklungsbemühungen für Produkteund sicherzustellen, dass Produkte die Bedürfnisse des Personals und der Nutzer erfüllen. Im Kontext der Entwicklung eines Bibliotheksverwaltungssystems beinhaltet die Planung des Produkt-Backlogs die Einbeziehung von Stakeholdern, die Aufrechterhaltung von Transparenz und Sichtbarkeit des Backlogs sowie die regelmäßige Überprüfung der Prioritäten, um eine Ausrichtung an der Gesamtvision und den Geschäftszielen der Bibliothek sicherzustellen.
Der Artikel hebt hervor, dassBest Practices für die Planung des Produkt-Backlogs und liefert ein Beispiel für die Entwicklung eines Bibliotheks-Verwaltungssystems. Durch die Einhaltung dieser Best Practices können Bibliotheken einen Produkt-Backlog erstellen, der die Bedürfnisse und Erwartungen von Mitarbeitern und Besuchern genau widerspiegelt, was zu hochwertigen Produkten führt, die ihren Bedürfnissen entsprechen.