Alle Augen waren auf Stephanie gerichtet, als Tom mit einem Hauch von Sarkasmus sagte:
„Wenn es jemand wissen muss, dann doch wohl du, oder?“
Dieser Frage war eine hitzige Diskussion vorausgegangen. Sie begann mit der Formulierung einer neuen User Story. Tom wollte einen zusätzlichen Testfall als Akzeptanzkriterium formulieren. Als Product Owner wollte er sicherstellen, dass das Team das liefert, was mit dem Kunden vereinbart wurde. Doch Susanne, eine Senior-Entwicklerin im Team, beharrte darauf, dies in der Definition of Done festzuhalten, da die Umsetzung der Story zusätzlichen Entwicklungsaufwand bedeuten würde. Die Diskussion wurde immer leidenschaftlicher geführt und gipfelte in der Frage, was denn eigentlich der Unterschied zwischen Akzeptanzkriterien und der Definition of Done sei. Da weder Tom noch Susanne diese Frage beantworten konnte, richtete Tom die Frage an Stephanie.
Stephanie kennt diese Situation nur zu gut. Sie weiß, wie unangenehm es ist, wenn das eigene Team einen für inkompetent hält, weil man die Begriffe nicht richtig versteht oder den Unterschied nicht erklären kann. Ihr Magen zieht sich zusammen und sie spürt den Druck, ihre Kollegen jetzt nicht zu enttäuschen.
Im Berufsleben wird man oft als Amateur abgestempelt, wenn man Fachbegriffe nicht unterscheiden kann. Wenn das Team die eigenen Erklärungen nicht mehr ernst nimmt, wie soll man dann noch helfen? Deshalb ist es so wichtig, die Unterschiede zwischen den Begriffen genau zu verstehen und erklären zu können.
Damit du nicht als Amateur abgestempelt wirst, findest du im Folgenden acht Schlüsselbegriffe, die du unbedingt unterscheiden musst. So sorgst du dafür, dass du als professioneller Scrum Master wahrgenommen wirst und dein Team dich als zuverlässigen Coach schätzt.
Schlüsselunterscheidung: Was ist der Unterschied zwischen Inkrement und Produkt?
Warum sprechen wir in Scrum von einem Inkrement und nicht nur von einem Produkt?
Die Unterscheidung ist historisch begründet und fußt auf der Tatsache, dass die Arbeit eines Product Backlogs abgeschlossen sein kann, also die Definition of Done erfüllt ist, das Ergebnis aber zugleich noch kein Bestandteil des Produkts ist. Mit „Inkrement“ bezeichnen wir in Scrum die fertigen Product-Backlog-Einträge, die noch nicht für die Verwendung durch Nutzer freigegeben wurden. Oder anders ausgedrückt:
Erst wenn das Inkrement in die Hände der Nutzer gelangt, wird es zum Produkt.
Schlüsselunterscheidung: Was ist der Unterschied zwischen einem Produktziel und einem Sprintziel?
Langfristig fokussieren sich Scrum Teams auf ein Produktziel.
Das Produktziel fungiert als Nordstern für die Arbeit des Teams und daraus leitet das Scrum Team die Einträge des Product Backlogs ab. Um Fortschritte bei der Erreichung dieses langfristigen Ziels zu machen, definieren Scrum Teams Zwischenziele. Da sich diese Ziele nur auf einen Sprint beziehen, werden sie Sprintziele genannt. Das Ziel des Sprints hilft den Entwicklern, sich zu fokussieren, zusammenzuarbeiten, den Wert ihrer Arbeit für die Stakeholder nicht außer Acht zu lassen und die langfristige Zielsetzung des Produkts weiterzuverfolgen.
Schlüsselunterscheidung: Was ist der Unterschied zwischen einem Product-Backlog-Eintrag und einer User Story?
Der Product Backlog enthält Elemente, nämlich die Product-Backlog-Einträge.
Diese Elemente definieren, „was“ in der Zukunft am Produkt verbessert werden soll. Mehr schreibt der Scrum Guide nicht vor. Die Elemente des Product Backlogs können alles Mögliche sein, solange sie das „Was“ beschreiben. Es können Featurebeschreibungen, Hypothesen, Bugs oder auch User Stories sein. User Stories sind also eine Möglichkeit, die Elemente des Backlogs festzuhalten. User Stories erzählen die Geschichten der Kunden des Produkts und helfen, ein gemeinsames Verständnis im Scrum Team und mit seinen Stakeholdern zu schaffen. Ihren Ursprung haben User Stories im Extreme Programming.
User Stories können Einträge des Product Backlogs sein und sind somit für Scrum Teams nicht verpflichtend zu verwenden.
Schlüsselunterscheidung: Was ist der Unterschied zwischen einem Akzeptanzkriterium und der Definition of Done?
Soll der Funktionsumfang oder die Qualität der Arbeit beschrieben werden?
Der Funktionsumfang kann in einem Akzeptanzkriterium festgehalten werden. Ein Akzeptanzkriterium beschreibt den Funktionsumfang, der erfüllt sein muss, damit die Arbeit von den Stakeholdern akzeptiert wird. Die Definition of Done hingegen ist eine formale Beschreibung der Qualität, die die Arbeit der Entwickler an einem Product-Backlog-Eintrag erreichen muss, bevor dieser Bestandteil des Produkts werden kann.
Das Festlegen von Qualitätsstandards an die Arbeit ist in Scrum verpflichtend. Akzeptanzkriterien sind jedoch optional.
Schlüsselunterscheidung zwischen der Größe und Schätzung eines Product-Backlog-Eintrags:
Im Scrum Guide wird das Wort „Schätzen“ nicht erwähnt!
Der Scrum Guide empfiehlt, dass jeder Eintrag im Product Backlog neben einer Beschreibung und Reihenfolge auch eine Größe zugewiesen bekommt. Dies hilft dem Scrum Team, den Sprint zu planen. Bekannte Größeneinheiten sind: Story Points, T-Shirt-Größen, Tage oder die Vergabe eines Boolean-Werts (klein genug, zu groß). Schätzen ist eine Möglichkeit, die Größe eines Eintrags im Product Backlog zu bestimmen. Bekannte Schätzverfahren für Product-Backlog-Einträge sind Magic Estimation, Planning Poker oder Right Sizing. Statt durch Schätzung kann die Größe auch durch Wahrscheinlichkeiten ausgedrückt werden. Die Wahrscheinlichkeit, wann ein Product-Backlog-Eintrag fertiggestellt wird, berechnet sich aus dem Fertigstellungszeitpunkt der bereits abgeschlossenen Einträge des Product Backlogs.
Schätzen ist also eine Möglichkeit, die Größe von Product-Backlog-Einträgen zu bestimmen, und nicht verpflichtend in Scrum.
Schlüsselunterscheidung zwischen einem priorisierten und einem geordneten Product Backlog:
Im Sprachgebrauch unterscheiden wir oft nicht zwischen Priorität und Ordnung.
Wenn wir über das Product Backlog sprechen, ist jedoch Vorsicht geboten. „Priorisiert“ bedeutet, dass etwas nach Wichtigkeit oder Dringlichkeit geordnet ist, wobei den Dingen mit höchster Priorität Vorrang gegeben wird, weil sie am dringendsten sind oder die größte Bedeutung haben. „Geordnet“ bezieht sich dagegen auf eine Anordnung von Elementen oder Dingen in einer bestimmten Reihenfolge. Somit hat ein geordnetes Product Backlog genau ein erstes Element, während ein priorisiertes Product Backlog mehrere wichtige Elemente haben kann. Die Gefahr besteht darin, dass alle Einträge als wichtig erachtet werden. Dadurch wird die Transparenz des Product Backlogs beeinträchtigt, da nicht mehr erkennbar ist, an welchem Eintrag das Scrum Team als Nächstes arbeiten sollte.
Deshalb muss das Product Backlog in Scrum geordnet sein. Die Anordnung kann jedoch auf der Grundlage einer Priorisierung erfolgen.
Schlüsselunterscheidung: Was ist der Unterschied zwischen ungetaner Arbeit und technischer Schuld?
In Scrum bezeichnen wir die Arbeit, die noch erledigt werden muss, um einen Product-Backlog-Eintrag fertigzustellen und somit die Definition of Done zu erfüllen, als ungetane Arbeit. Zum Beispiel muss die neue Software-Lizenz von der Rechtsabteilung darauf geprüft werden, ob sie den FOSS-Standard erfüllt, bevor das Produkt dem Kunden freigegeben werden kann.
Wenn beim Bearbeiten eines Product-Backlog-Eintrags auf zeitaufreibende automatisierte Tests verzichtet wird, um die Software schneller dem Kunden zur Verfügung zu stellen, bezeichnen wir dies als „technische Schulden“. Ein Eintrag ist zwar fertig, wenn das Scrum Team die Software von Hand testet, aber es wurden Schulden aufgenommen. Bei jeder neuen Version der Software muss das Team wieder alles von Hand testen, was die Entwicklungsgeschwindigkeit des Teams verringert. Diese Schulden sollten umgehend zurückgezahlt werden, da sonst die Tilgungszahlungen das Scrum Team nachhaltig ausbremsen können.
Die Schlüsselbegriffe sind auch eine Quelle vieler Mythen und Fehlinterpretationen rund um Scrum. Im besten Fall führen Fehlinterpretationen von Scrum zu Missverständnissen in der Zusammenarbeit im Team. Im schlimmsten Fall führen Mythen dazu, dass Stakeholder und Kunden frustriert sind.
Wenn du erfahren willst, welche 20 weiteren Mythen über Scrum kursieren und wie du sie widerlegen kannst, dann melde dich zu meiner Websession heute an.
Hier geht es zur Anmeldung: 20 Mythen über Scrum und wie du sie widerlegst