Scrum-Grundlagen: Agile Softwareentwicklung

Das Product Backlog

Testen Sie unsere 1924 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Nach einem kurzen Überblick, welche "handfesten" Dokumente Scrum kennt, geht's gleich mit den Details des ersten los: Eigentlich nichts weiter als eine priorisierte Liste von Kundenwünschen, muss man dabei doch alte Zöpfe abschneiden: Nichts kann gleich wichtig sein!
07:47

Transkript

Bei Scrum gibt es verschiedene, wenn auch nicht viele, Dokumente, sogenannte "Artefakte", und die werden wir uns in diesem Film genauer anschauen. "Artefakte" ist ein anderes Wort für "Greifbares", also Sachen, die man wirklich in die Hand nehmen kann. In unserem Fall sind es meistens Dokumente. Welche Dokumente wir brauchen, kann man am besten herausfiltern, indem man sich einige Fragen stellt. Zum Einen "was soll entstehen?" und "in welcher Reihenfolge soll es entstehen?" Scrum nennt das Dokument, in dem diese Informationen enthalten sind "Product Backlog". Die zweite Frage wäre, "wie wollen wir es umsetzen?", quasi die technischen Details. In der Scrum-Sprache heißt dieses Dokument "Sprint Backlog". Und die dritte Frage, die man sich stellen könnte, lautet "wo stehen wir denn? Sind wir noch auf Kurs?"  Das Team visualisiert diesen Projektstand in einem sogenannten Burn Down Chart. Lassen Sie uns in das erste Dokument, das erste Artefakt, hineinschauen: das sogenannte Product Backlog. Das Product Backlog ist nichts weiter als eine priorisierte Liste mit Features mit Funktionalität, die entstehen soll. Das Wichtige an dem Dokument ist, es ist priorisiert. Es ist wirklich streng priorisiert. Es sind keine zwei Sachen gleich wichtig. Nicht wie in früheren Projekten, wo sie 20 Features hatten, von denen hatten 18 Prio 1 und 2 Prio 1A, sondern es sind niemals zwei Sachen gleich wichtig. Das ist auch ein Lernprozess den man, ja, vor allem als Product Owner, erst ein bisschen verinnerlichen muss. Eventuell drückt man die Priorität auch noch in Business Value aus; das folgt im nächsten Filmchen. Verantwortlich für das Product Backlog ist alleinig der Product Owner. Das Team schaut zwar in das Product Backlog hinein, aber der Product Owner ist die Person, die die Prioritäten festlegt, nachdem die Funktionalitäten zusammengetragen wurden. So ein Product Backlog hat üblicherweise Inhalt, nicht nur für den aktuellen Sprint, der jetzt gerade anfängt, sondern für mehrere Sprints. Meistens sogar für mehrere Produktversionen. Es geht manchmal sogar über Jahreshorizonte hinaus. Und das funktioniert natürlich nur, wenn dieses Product Backlog ständig erweitert und gepflegt wird. Der Product Owner nimmt im Laufe der Zeit immer wieder neue Sachen mit auf, hängt die hier unten mit rein, bzw. ordnet sie in seiner Priorisierung da ein, wo er glaubt, dass es da richtig reinpasst. Regelmäßige Pflege von so einem Product Backlog ist wirklich essentiell. Scrum hat dafür den Begriff des "Groomings". Ich glaube, "Grooming" heißt "Fellpflege". Wenn Sie einer Katze das Fell bürsten, heißt es "Grooming". Stellen Sie sich vor, Sie müssten ihr Product Backlog auch pflegen und bürsten, damit es auch über längere Zeit geschmeidig und samtig glänzend bleibt. Also ohne Pflege, ohne ständige Aktualisierung wird das Dokument schnell veralten und hat dadurch keinen Mehrwert mehr für Sie. Es steht also in diesem Product Backlog eine Liste von Anforderungen. Lassen Sie uns anschauen, wie so eine Anforderungen im Product Backlog greifbar gemacht wird. Pro Anforderung gibt es mehrere Punkte, die wir aufnehmen. Zum Einen natürlich, die Priorität, wie wichtig ist das? Als Zweites müssen wir in irgendeiner Form beschreiben, was soll da entstehen? Meistens erfolgt es in Form von "User Stories", eine abstrakte Beschreibung, was entstehen soll. Neben der abstrakten Beschreibung, muss es auch noch das Kleingedruckte geben. Die sogenannten "Akzeptanz-Kriterien". Wirklich die Sachen, die ein Product Owner, später bei der Sprint-Demo, sich zeigen lässt, ob das auch wirklich alles implementiert wurde (Akzeptanz-Kriterien genannt). Und, als letzter Punkt, enthält jedes Feature, das entstehen soll, eine Grobschätzung. Die Grobschätzung macht ausschließlich das Team und diese Grobschätzung wird ganz oft in einer abstrakten Einheit namens "Story Points" durchgeführt. Je weiter unten eine Anforderung im Product Backlog steht, desto unwichtiger ist sie. Das heißt, das Team fängt mit der Abarbeitung von gewissen Häppchen oben an und arbeitet sich immer weiter nach unten. Und der Product Owner hat es im Griff. Wenn er ein Feature weiter oben einordnet, ist es wichtiger für ihn, bringt mehr Business Value. Wenn es weiter unten steht, ist es weniger wichtig. Wenn es weiter unten steht kann es auch bedeuten, ist es noch unklarer. Der Product Owner hat einfach noch nicht alle Informationen beieinander, ist aber auch nicht weiter schlimm, weil das Team fängt immer oben an. Und je weiter unten es steht, desto mehr Zeit hat auch der Product Owner, um Klärungen herbeizuführen. Lassen Sie uns mal ein Product Backlog anschauen. Wir haben dazu ein Beispiel-Projekt. Ich habe mir gedacht, es soll eine Online-Videothek entstehen. Das Projekt heißt "Online-Videothek 3000". Wir haben die Geschäftsidee, wir können einfach eine Webseite bauen, auf der man DVDs mit Spielfilmen bestellen kann. Vielleicht nicht ganz neu, die Idee, aber wir sind trotzdem der Meinung, das wird jetzt ein Bombenerfolg werden. Und wie könnten die Anforderungen ausschauen? Wie könnte ein Product Backlog für so ein imaginäres Projekt ausschauen? Es könnte einfach so ausschauen. Das ist jetzt nichts weiter als ein dummes Excel File, in der Zeile für Zeile die Features aufgelistet sind. Pro Zeile haben wir, ganz wichtig und dick gedruckt, die Priorität. Priorität 1 wäre z.B. wir brauchen eine Startseite. Ich muss auf meiner Online-Videothek surfen können, um mich über Filme zu informieren. Die User Story würde heißen: "Als potentieller Kunde möchte ich den Webauftritt der Online-Videothek 3000 ansurfen können, um mich über die Firma und über das Angebot informieren zu können. Und es gibt verschiedene Akzeptanzkriterien, was erfüllt sein muss. Da muss der Firmenname drauf stehen. Das Logo muss drauf stehen. Es muss diese und jene Information auf der Startseite verfügbar sein; und das ist es eigentlich schon. Anhand dieser Informationen würde das Team dann abschätzen, ob das eher etwas Komplexes ist oder eher was überschaubar Einfaches. Als nächste Zeile wäre dann sowas wie: "Ich brauche eine Seite mit Kontakt- informationen", oder die Prio 3 hätte "Ich brauche eine Produktübersicht für die Rubrik Actionfilme, wo schon mal die ersten fünf wichtigsten Actionfilme zu sehen sind." Und so wird es nach unten immer unwichtiger, was den Geschäftswert angeht, den dieses Feature bringt, und vielleicht auch etwas unklarer. Das Product Backlog hört jetzt auch nicht nach Prio 4 auf, wie hier, sondern es hat einfach nicht mehr auf den Bildschirm gepasst. Es geht nach unten weiter, relativ lange. Mehr ist es eigentlich nicht. Ein Product Backlog ist also nichts weiter, als eine priorisierte Liste, von allem, was in einem Projekt entstehen muss.

Scrum-Grundlagen: Agile Softwareentwicklung

Machen Sie sich mit der Softwareentwicklung mit Scrum vertraut und sehen Sie, wie Sie komplexe Projekte agiler, qualitativ besser, kundenorientierter und motivierter meistern.

3 Std. 34 min (49 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!