„Das machen wir dann im nächsten Grooming!“… Das heißt Product Backlog Refinement denkt sich Veit, schluckt es runter und hört weiter zu.
Gerade in neuen Projekten/Aufträgen werde ich oft konfrontiert mit Begriffen, welche leicht falsch bis komplett missverstanden benutzt werden. Selbst nach all den Jahren in meiner Rolle fiel es mir (bis vor kurzem) schwer, diese fehlinterpretierten Begriffe aufzuklären. Man möchte ja auch nicht als Besserwisser oder „Der, der mit der Scrum Bibel fuchtelt“ wahrgenommen werden.
In einem meiner letzten Projekte jedoch habe ich das letzte fehlende Puzzleteil gefunden, welches mir diese Scheu vor der Konfrontation genommen hat:
Backlog, Backlog und Backlog (und Backlog)
Bei einem Projekt in einem Unternehmen durfte ich über einen längeren Zeitraum in vielen verschiedenen Teams wirken. Dabei gab es Teams, welche schon lange agil arbeiteten und konkrete Fragen hatten. Andere Teams waren noch frisch in der neuen Arbeitsmethodik und wünschten sich Unterstützung in ihren ersten agilen Schritten. Was mir hier auffiel, war das Wörtchen „Backlog“.
Backlog wie in Product Backlog
Wenn in einem Team jemand sagte: Das müssen wir noch ins Backlog packen, war für den Rest des Teams klar, es geht um ein PBI (Product Backlog Item) bzw. eine Anforderung, welche ins Product Backlog aufgenommen werden sollte.
Backlog wie in Product Backlog Item
Parallel, hörte ich in einem nahen Team „Aber in diesem Backlog steht etwas ganz anderes als besprochen“. Jedem im Team war klar, ein „Backlog“ ist eine Anforderung in unserem Product Backlog
Backlog wie in Sprint Backlog Item
„Ich häng noch an meinem Backlog und arbeite morgen weiter daran“, war der Ausruf im Daily eines dritten Teams. Hier handelte es sich nicht um einen überarbeiteten PO, sondern um einen Entwickler und mit Backlog meinte er ein Sprint Backlog Item am Scrum Board
Backlog wie in Product Backlog Refinement
Zur gleichen Zeit bei einem anderen Kunden viel der Satz: „Stimmt das brauchen wir auch… Darüber sprechen wir im nächsten Backlog.“ Während in meinem Kopf die Vermutung ablief, dass damit das nächste Produkt in ferner Zukunft gemeint war, war stattdessen das Event der kommenden Woche gemeint.
… ja und?
Das gleiche Verständnis in allen Köpfen ist ein wichtiger Bestandteil, um sich im Team und über dessen Teamgrenzen hinweg gut miteinander zu verstehen. Ein gemeinsamer „Duden“ für Agilität wie das Manifest für Agile Softwareentwicklung oder der aktuellste Scrum GuideTM können hierbei sehr helfen. Ich denke jeder hat den Satz „Das Wort (hier beliebiges Wort einsetzen) darfst du hier nicht verwenden! Das ist verbrannt!“ hat sicher jeder schon einmal gehört.
Während es innerhalb eines Teams oder einer Organisationskultur gut funktionieren kann Begriffe „falsch“ einzubürgern, sind Konflikte früher oder später unvermeidbar. Sie frühzeitig anzusprechen und eine falsche Verinnerlichung zu verhindern ermöglicht Freiheiten und Offenheit in der Zukunft.
Meine Top 5 der missverständlich verwendeten Begriffe im agilen Produktentwicklungskontext
6. MVP
Ein MVP beschreibt ein „Minimal Viable Product“ also ein minimal lebensfähiges Produkt. Es als ersten Slice eines Elefanten zu sehen, welcher umsetzbar ist aber kein Feedback oder direkten Nutzen abwirft, wird nur einem Teil des MVP Gedankens gerecht.
5. TDD
TDD steht für Test Driven Development und beschreibt ein ganz bestimmtes Vorgehen ERST Tests und DANACH den Code zu schreiben. TDD mit reinem Unit Testing gleichzusetzen beschneidet dieses Vorgehen von dessen Grundidee.
4. Task
Weder das Manifest für agile Softwareentwicklung noch der Scrum Guide kennen den Begriff „Task“ dennoch hat sich eingebürgert, die Aufgaben klein geschnittener Sprint Backlog Items am Sprint Board als Tasks zu bezeichnen. Sämtliche Anforderungen des Produkts als Tasks zu bezeichnen könnte Verwirrung stiften.
3. Product Owner
Ich versuche mich kurz zu fassen… Nicht jeder, der Anforderungen schreibt, ist ein PO. Heiko Stapf fragt in seinen Trainings gern: „Wer von euch hat die Entscheidungsbefugnis, die Entwicklung eures Produktes von heute auf morgen einzustellen? Niemand? Dann haben wir hier wohl keinen PO“. Was man dagegen tun kann? Fragt am besten Heiko selbst in einem CSPO Training!
2. Grooming
2013 wurde der Begriff „Grooming“ aus dem Scrum Guide geworfen, da das Wort vor allem in Großbritannien anders verwendet wird (Klicken auf eigene Gefahr). Das Wort selbst ist vom Grundgedanken „Vorbereiten/Pflegen“ nicht falsch, sorgt aber bei ScrumMastern für ein unangenehmes Schmunzeln.
1. User Story
So sehr ich Jira als Product Backlog Verwaltungstool auch schätze, es hat den Begriff „User Story“ kaputt gemacht. Eine Standardimplementation kennt keine PBIs, sondern gibt jeder Anforderung den Status „User Story“. Das hinter dem Konzept User Story viel mehr steckt lernen Anwender leider erst deutlich später.
Ihr wollt euer Wissen rund um Scrum Begriffe, Scrum Master Know How und Kommunikation ausbauen? Dann besucht uns doch zu einem kostenlosen Schnuppermonat bei der ScrumMaster Workout Community!
