On Lean and Agility: User Stories und Anforderungen

Posts mit dem Label User Stories und Anforderungen werden angezeigt. Alle Posts anzeigen

Donnerstag, 16. Februar 2023

Youtube ist und bleibt eine Fundgrube für die bemerkenswertesten Dinge. Das heutige Fundstück ist ein Video eines weitgehend unbekannten E-Learning-Anbieters namens Bean Stalk, der auf wunderbar nachvollziehbare Art und Weise das Konzept des User Story Mappings erklärt.

Was mir beim Ansehen auffällt - ich muss unbedingt wieder meine Visualisierungs-Fähigkeiten trainieren. Vor Corona hätte ich ein ähnliches wachsendes Gemälde wie das im Video auch hinbekommen, nach drei Jahren Miro-Nutzung ist dieses Talent aber etwas eingerostet.

Montag, 11. April 2022

Bild: Wikimedia Commons / Rainer Flassig - CC BY-SA 2.0

Stellen wir uns folgende Situation vor: ein Product Owner (oder ein Mensch in vergleichbarer Rolle) kommt zu seinem Team. Er stellt ihm die neueste User Story vor, die auch von allen sofort verstanden wird. Als es dazu kommt eine Aufwandsschätzung abzugeben sind die Entwickler aber ratlos - die Umsetzung müsste in einer Technologie oder in einem System erfolgen mit denen sie noch nie gearbeitet haben. Ohne diese Erfahrungswerte können sie den Aufwand nur raten.

Im klassischen Projektmanagement würde man versuchen dieses Problem zu lösen inden man einem team-externen Experten die Aufwandsschätzung überlässt, z.B. einem Architekten, Lead Developer oder Business Analysten. In einem agilen Vorgehen wäre das aber keine gute Lösung, schliesslich soll die Aufwandsschätzung hier nach Möglichkeit von den Mitgliedern des umsetzenden Teams selbst kommen.¹ Wie versetzt man die also in die Lage das zu tun?

Eine Lösung dafür kommt aus dem Extreme Programming, dem Framework dem wir auch die User Story verdanken, und nennt sich Spike Solution (oft abgekürzt zu Spike). Sie besteht in Abgrenzung zur Perfect Solution oder Possible Solution, bei denen zumindest grundlegend klar ist wie gross der Aufwand ist und die direkt neue Funtionen erzeugen sollen.² Die Spike Solution soll das nicht, ihr Ziel ist es lediglich, die Entwickler mit der Technik vertraut zu machen.

But what if you haven't done anything like this story before? What if it's the beginning of the project and you haven't done anything at all? The answer is simple: do some experimenting. We call such an experiment a "Spike Solution" to remind us that the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out. You need to know how long it will take you to do something.

Ron Jeffries and Chet Hendrickson, Extreme Programming Installed, S.55

Was Ron Jeffries und Chet Hendrickson, zwei der drei Erfinder von Extreme Programming, hier sagen streicht die entscheidenden Punkte heraus: wenn die Erfahrungswerte für eine Aufwandsschätzung zu gering sind können diese dadurch hergestellt werden, dass so lange Experimente mit der Anwendung durchgeführt werden bis die Vertrautheit gross genug für eine Schätzung ist. Um möglichst schnell an diesen Punkt zu kommen sollten diese Experimente, bzw. Spikes, möglichst klein sein.

In dem Buch aus dem sein Zitat stammt nennen die beiden auch Beispiele dafür. Eines besteht darin einem System einfache Rechenoperationen hinzuzufügen, ein anderes in der Änderung der Formatierung einer Zahl. Derartige Experimente sind in wkurzer Zeit abschliessbar, geben dem der sie durchführt aber trotzdem ein Gefühl davon wie aufwändig die Arbeit in diesem System ist. Falls das noch nicht reicht kann ein zweites oder drittes folgen, bis ein Grundverständnis da ist.

Wichtig ist dabei, dass der im Rahmen der Spikes erzeugte Code im Anschluss nicht weiterverwendet wird und stattdessen gelöscht werden kann. Nur so kann sichergestellt werden, dass nicht versehentlich etwas beschädigt wird und dass das Experiment dort stattfinden kann wo die Unklarheit am grössten ist. Den bereits erzeugten Code irgendwie weiterverwenden zu wollen ist zwar ein verständlicher Reflex, allerdings ist davon aus den genannten Gründen abzuraten.

Soviel zu den Warum und Wie einer Spike Solution, es bleibt aber noch eine Frage - warum eigentlich der Name? Er leitet sich ab von einem einfachen Stech-Werkzeug mit dem Löcher gebohrt werden können. In Analogie dazu ist es durch den Spike möglich in die "Black Box" des unbekannten Systems Löcher zu bohren, wodurch Licht in das Innere fällt, das dadurch sichtbar und begreifbar wird.

¹Schätzungen durch externe Experten machen diese zum Flaschenhals, werden oft ohne Kenntnise des tatsächlichen Leistungsvermögens des Teams vorgenommen und können politisch beeinflusst werden
²Perfect Solution und Possible Solution sind keine Fachbegriffe sondern Audrücke der normalen Alltagssprache

Donnerstag, 26. November 2020

Bild: Pixabay / Larisa K. - Lizenz

Seit November 2020 muss die agile Community mit einer Begriffsverwirrung leben. Das in diesem Monat veröffentlichte Update des Scrum Guide führte einen neuen, bis dahin kaum bekannten Begriff ein: das Produktziel (Product Goal). Verwirrend ist das deshalb, weil es (ausserhalb von Scrum) einen sehr ähnlichen und bereits etablierten Begriff gibt, die Produktvision (Product Vision). Ist das jetzt das Gleiche? Gibt es Unterschiede? Wenn ja welche? Schauen wir uns die Begriffe an.

Die Ursprünge der Produktvision verlieren sich irgendwo im Dunkel der Geschichte, bereits in rückwirkend digitalisierten Fachartikeln findet man sie aber wieder, z.B. 1984 im Harvard Business Review als "Vision for the Product". Konkretisiert wurde sie später in verschiedenen Formen, unter anderem 1991 von Geoffrey Moore in Crossing the Chasm (als "Product Elevator Pitch") und 1995 von Michael McGrath in Product Strategy for High Technology Companies (als "Strategic Vision").

Die Gemeinsamkeit dieser Ansätze ist, dass sie die Produktvision im Sinn eines Leitsterns, Fernziels oder Idealtypus definieren, also als etwas was in der Realität kaum zu erreichen ist. Der damit verbundene Zweck ist, dass durch eine Ausrichtung an dieser Vision kontinuierlich in eine gleichbleibende Richtung gearbeitet werden kann, was sowohl durch Abarbeiten eines langfristigen Plans möglich ist (im Wasserfall-Vorgehen) als auch durch kurzfristiges Optimieren der jeweils nächsten Schritte in Richtung des Langfristziels (agiles Vorgehen).

Im Unterschied dazu kann das im Scrum Guide beschriebene Produktziel explizit erreicht werden. Der in diesem Zusammenhang entscheidende Absatz lautet "The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.", wodurch klar wird, dass eine Beendigung der Arbeit am Produktziel möglich ist. Eine Zwangsläufigkeit dass das in absehbarer Zeit geschieht ist das zwar nicht (theoretisch sind Produktziele möglich die erst in Jahrzehnten erreichbar sein werden) grundsätzliche Abschliessbarkeit sollte aber gegeben sein.

Der Differenzierung sollte damit klar sein: die Produktvision ist der führende, aber letztendlich unerreichbare Leitstern, das Produktziel der ferne aber (theoretisch) erreichbare Abschluss aller Arbeiten die für ein Produkt nötig sein werden.

Absehbar ist aber auch: So hilfreich diese begriffliche Unterscheidung für das Verständnis auch sein mag, in der Realität dürfte sie nur selten vorgenommen werden. Es werden wohl nur die methodenbegeisterten Teams sein die in ihrem Backlog eine Differenzierung zwischen Produktvision und Produktziel vornehmen, die meisten werden nur einen der Begriffe verwenden oder sie synonym gebrauchen - was angesichts der grossen Schnittmengen auch unproblematisch sein sollte. Wichtig ist nur, die Unterscheidung zu kennen, um bei Bedarf beides einsetzen (oder den Unterschied erklären) zu können.

Montag, 23. November 2020

Bild: Unsplash / Lukas Eggers - Lizenz

Eine der Gemeinsamkeiten praktisch aller agil aufgestellten Organisationen ist die Nutzerzentrierung. Die Anforderungen sind in der Regel aus der Sicht des Nutzers formuliert (so genannte User Stories), und die fertigen Ergebnisse werden zusammen mit ihm getestet und besprochen. Was bei all dem aber zu bedenken ist - manchmal lassen Benutzer sich zu Aktionen hinreissen die sie besser unterlassen hätten, und von denen das System sie abhalten sollte. Lassen sich auch derartige "verhindernde Funktionen" als User Story formulieren?

Bevor wir darauf eingehen eine kurze Sinnfrage: wenn ein Nutzer eine bestimmte Aktion nunmal durchführen will, warum sollte man ihn davon abhalten? Weiss er nicht am besten was richtig für ihn ist? Die Antwort darauf: leider nicht immer, und ein wie es der Zufall will gibt es auch ein aktuelles Beispiel dafür. Um zu zeigen wie produktiv sie im Home Office war veröffentlichte eine niederländische Ministerin auf Twitter einen Screenshot von einer EU-Ministerrunde an der sie gerade teilnahm. Da dieser in seiner URL den Konferenzdienst und den Zugangscode anzeigte war es für jeden ihrer Twitter-Follower möglich ebenfalls an dem Meeting teilzunehmen. Und ein Journalist gönnte sich den Spass und machte genau das.

Dit was de oorspronkelijke foto die vanaf het account van minister Bijleveld werd gedeeld, met daarin de meeting-ID en vijf cijfers van de pincode.

Het was een zescijferige pincode. Ik joinde met de naam 'admin'. pic.twitter.com/Fztrbqm5FR
— Daniël Verlaan (@danielverlaan) November 20, 2020

Zurück zur Ausgangsfrage. Lassen sich User Story formulieren die zwar aus Nutzerperspektive geschrieben sind aber ein fahrlässiges Verhalten wie das der niederländischen Ministerin verhindern sollen? Natürlich geht das, es fühlt sich aber künstlich an. "Ich als Videokonferenz-Teilnehmer möchte daran gehindert werden Zugangsdaten zu veröffentlichen, damit kein Unbefugter teilnehmen kann" ist kein Satz oder Wunsch den ein echter Mensch jemals äussern würde.

Ein besserer Ansatz wäre es sich den Benutzer/User aus einer anderen Perspektive vorzustellen. In UX-Design und Software-Test gibt es den Typus des "Evil User", der sich dadurch auszeichnet, dass er Funktionen immer wieder so benutzt wie sie nicht gedacht sind und dadurch Fehlfunktionen und falsche Ergebnisse erzeugt. Wichtig ist dabei, dass er das (meistens) nicht aus bösem Willen tut sondern aus Unkenntnis und ohne zu wissen was er anrichtet - wie im Fall der oben genannten Ministerin.

Vom Evil User zur User Story ist es jetzt nur noch ein kurzer Sprung. "Ich als Videokonferenz-Teilnehmer möchte Screenshots mit allen sichtbaren Informationen veröffentlichen, damit jeder sehen kann was ich mache". Mit solchen Anforderungen in ein Refinement zu gehen kann wertvolle Diskussionen ermöglichen. Für den Fall dass jemand etwas Derartiges tut (verhindern kann man es nicht) welche Informationen sind dann öffentlich sichtbar? Welche davon sind sicherheitsrelevant? Und wie könnte man sie unkenntlich machen?

Aus derartigen Diskussionen können sich dann die Akzeptanzkriterien der Evil User Story ergeben, die in diesem Fall negativ formuliert sind, da sie ja das "bösartige" Nutzerverhalten eindämmen sollen. Angelehnt an den oben genannten Fall könnte etwa eines sein, dass weder auf der Website des Video-Calls noch in der URL Zugangsdaten sichtbar sein dürfen.

Als letztes noch ein Tip aus der Praxis: es macht Sinn die Evil User Stories im Backlog mit einer besonderen Kennzeichnung zu versehen. Wenn das nicht passiert besteht das Risiko, dass das Team vergessen hat, dass es sich bei einer älteren Story um eine zu verhindernde Aktion handelt und diese dann in der Weiterentwicklung nicht verhindert sondern erleichtert oder sogar erst ermöglicht. In solchen Fällen steckt eine feine Ironie: das Team ist dann der Evil User seines eigenen Prozesses.

Montag, 26. August 2019

Bild: Wikimedia Commons / Sarah Welch - CC BY-SA 4.0

Zu den Begriffen aus dem agilen Umfeld die immer wieder kontrovers diskutiert werden gehört das Epic. Es gibt zwar in den meisten Fällen die Übereinstimmung, dass es sich dabei um eine grössere Anforderungs- oder Planungseinheit handelt, alles was darüber hinausgeht wird aber sehr unterschiedlich verstanden. Zeit um Klarheit zu schaffen.

Ein Epic ist zunächst nichts anderes als eine User Story die zu gross ist um umgesetzt zu werden ohne vorher aufgeteilt worden zu sein. Wann, wo und in welchem Kontext diese Verwendung entstanden ist lässt sich vermutlich nicht mehr genau klären, bereits 2004 wird diese Verwendung vom Scrum-Pionier Mike Cohn in seinem Buch User Stories Applied aber schon mit grosser Selbstverständlichkeit vorgetragen¹. Aber was ergibt sich aus dieser Bedeutung?

Zunächst, dass Epics genau wie normale User Stories verschiedene Voraussetzungen erfüllen müssen. Sie sollten einen End-to-End-Ansatz verfolgen², in einfacher, verständlicher Sprache geschrieben sein, einen Anwender nennen³, den gewünschten Use Case, bzw. das zu lösende Problem beschreiben und auch nachvollziehbar darstellen welcher Mehrwert neu geschaffen werden soll. Die Gleichartigkeit von User Story und Epic lässt sich bereits daran erkennen, dass die Begriffe sich alleine durch eine Neuschätzung des Aufwandes vertauschen können.

Genau wie im Fall von User Stories ist es auch bei Epics möglich sie durch Zusatzinformationen anzureichern. Das können Akzeptanzkriterien sein, Personas oder Kundenfeedbacks, es gibt aber auch eine Form der Zusatzinformation die Epic-spezifisch ist: die Benennung der an der Umsetzung beteiligten Teams. Wenn das mehrere sind (wofür es verschiedene Gründe geben kann) erleichtert das die Nachverfolgung und Koordination des Arbeitsfortschritts.

Zuletzt ist es noch wichtig, dass Epics in überschaubarer Zeit abschliessbar sein müssen. Ohne die Begrenzung des Scrum-Sprints oder der XP-Iteration ist es ein verlockender Fehler den Rahmen so weit zu ziehen, dass am Ende eher ein Anforderungs-Kategorie als eine Anforderung steht (z.B. "Benutzerverwaltung" oder "Shop". Das ist nicht im Sinn der Idee und sollte vermieden werden.

¹Danke für die Hinweise auf Mike Cohns Buch, allerdings wurde der Begriff dort nicht erfunden oder eingeführt. Auf Seite 6 heisst es "When a story is too large it is sometimes referred to as an epic." Die Verwendung gab es also auch schon früher.
²D.h. es sollte keine ausgelagerten Konzeptions-, Umsetzungs-, (Regressions)Test-, Dokumentations- oder Release-Epics geben
³Anwender ≠ Auftraggeber

Donnerstag, 4. Juli 2019

Bild: Pexels / Rawpixel - Lizenz

Draussen in der Welt gibt es die Inspirationen. Letzte Woche durfte ich den Vortrag eines Amazon-Mitarbeiters hören, in dem vorgestellt wurde wie in diesem Unternehmen gearbeitet wird. Einiges davon war bereits bekannt, etwa die Micoservice-Architektur oder die 2 Pizza-Teams, anderes noch nicht. Zu den eher unbekannten Aspekten gehörte die Formulierung von Produktbeschreibungen, die bei Amazon in einer ungewöhnlichen Variante existieren: als Pressemitteilung.

Natürlich handelt es sich dabei nicht um Pressemitteilung im eigentlichen Sinn, sie sind nur für die interne Kommunikation gedacht. Ihr Inhalt ist immer so formuliert, dass er den in der Zukunft liegenden Produktions-, bzw. Vermarktungsstart beschreibt. Ob jemals eine dieser Pressemitteilungen wirklich an die Medien verschickt wurde ist unklar, es ist aber auch nicht weiter von Relevanz. Wichtig sind die Inhalte, die durch das Format erzwungen werden.

Pressemitteilungen sind kurz. Die (bei Amazon) übliche Länge ist eine Seite. Der Verfasser ist also gezwungen längliche Ausführungen zu unterlassen und sich auf das Wesentliche zu konzentrieren. Sie haben ein Datum. Dafür muss eine Idee existieren bis wann eine Fertigstellung einer ersten Version realistisch wäre. Und ganz wichtig: sie erfordern bestimmte Arten der Formulierung und des inhaltlichen Aufbaus.

Da Pressemitteilungen sich an eine breite Öffentlichkeit richten müssen sie einfach und verständlich formuliert sein, es darf kein Fachchinesisch geben. Auch inhaltlich gibt es klare Vorgaben: von oben nach unten müssen sie abnehmend relevant und zunehmend detailliert werden. Das klingt zwar abstrakt, wird bei genauerer Betrachtung aber schnell konkret.

Oben (direkt nach dem Datum) steht die Überschrift. Die sollte nicht länger als eine Zeile sein und einen ersten Eindruck geben worum es geht (z.B. "Stadt Bonn stattet Parkautomaten mit Chatbots aus"). Ggf. kann ergänzend noch eine Unter- oder Dachzeile dazukommen die weiteren Kontext gibt (z.B. "Diskussionen mit Politessen werden unnötig"). Darunter steht der so genannte Teaser, ein hervorgehobener Textblock in dem Produkt und Produktmehrwert zusammengefasst werden.

Eilige Leser sollten an dieser Stelle abbrechen können und trotzdem alle wesentlichen Informationen haben. Für alle anderen folgen in den nächsten Absätzen weitere Hintergründe. Was war das initiale Problem, bzw. der ursprüngliche Marktbedarf? Wie sah die erste Lösungsidee aus? Wie erfolgte die Konkretisierung? Was waren die ersten Schritte? Was war der Umfang der ersten Version? (zur Erinnerung, die Pressemitteilung ist aus Sicht eines in der Zukunft liegenden Release formuliert)

Neben diesen Kerninformationen können noch weitere Elemente von Pressemitteilungen genutzt werden, zum Beispiel (fiktive) Zitate des Produktverantwortlichen oder begeisterter Kunden, Infografiken oder FAQ-Boxen. Durch deren Freistellung vom Fliesstext wird das Dokument zwar länger, auch jetzt sollte es aber anderthalb Seiten nicht überschreiten um nicht unübersichtlich zu werden.

Das fertige Ergebnis kann dann in der für Produktbeschreibungen üblichen Form genutzt werden: als Unterlage für einen Pitch oder eine Genehmigung, als Ausgangslage für Workshops oder als Fokussierungshilfe für das Umsetzungsteam. In späteren Umsetzungsphasen können auch weitere Dokumente dazukommen, sie sollten aber immer auf die Pressemitteilung verweisen und ihr nicht widersprechen.

Freitag, 8. März 2019

Bild: Pixabay / Tero Vesalainen - Lizenz

Zu den vielen Dingen die in den gängigen agilen Frameworks nicht geregelt werden gehören die Abnahmen eines fertigen Produktincrements. Dass sie stattfinden sollten ist naheliegend, zumindest so lange wie es einen Product Manager, Onsite Customer oder Product Owner gibt, der die Anforderung ursprünglich verfasst hat. Wann sie stattfinden soll ist weniger klar.

Was in vielen Teams stattfindet ist scheinbar naheliegend - eine Abnahme in den Review- oder Demonstrations-Meetings, die es nicht nur in Scrum gibt sondern überall dort wo Kunden, Auftraggebern oder Benutzern die Ergebnisse umgesetzter Anforderungen vorgeführt werden. Doch so naheliegend das auch erscheinen mag, eine gute Idee ist es nicht.

Zum einen ist eine Abnahme vor den Augen von Leuten ausserhalb des Teams eine zweischneidige Angelegenheit. Bestenfalls werden sie durch intern wichtige aber für Aussenstehende irrelevante Details gelangweilt (Wurden die Regressionstests aktualisiert? Entspricht die Schriftart dem Corporate Design? Etc.), schlimmstenfalls wird die Abnahme verweigert und sie haben sich umsonst in das Meeting begeben.

Zum anderen nimmt sich ein Team das Abnahmen zu einem so späten Zeitpunkt durchführt ohne Notwendigkeit selbst einen Teil der eigenen Flexibilität. Zur Verdeutlichung: wird ein Ergebnis erst am Ende eines Sprints oder Produktionsszyklus überprüft ist es im Regelfall zu spät um einen festgestellten Änderungsbedarf ohne Planänderungen umzusetzen. Der nächste Sprint, bzw. Zyklus steht ja unmittelbar bevor und muss kurzfristig noch die Nacharbeiten aufnehmen.

Eine bessere Vorgehensweise wäre eine Abnahme sofort nach der Fertigstellung der letzten Arbeit am jeweiligen Increment. Wenn dann unmittelbar eine Vorführung und Überprüfung stattfindet bleibt auch bei entdeckten Fehlern noch genug Zeit für Korrekturmassnahmen, so dass der Zeitplan eingehalten wird und im Review, bzw. Demo-Meeting der Focus da liegen kann wo er hingehört - beim Einsammeln und Diskutieren von Feedback zum fertigen Ergebnis.

Ein häufiger Hinweis an dieser Stelle ist übrigens, dass man Abnahmen doch nicht einfach irgendwann und ohne Meeting durchführen könnte, nur weil es da gerade passt. Die Antwort darauf: doch, das geht auch ohne offizielles Meeting, und ja, gerade dann wenn es passt ist der richtige Zeitpunkt. Ganz ehrlich - wann denn sonst?

Donnerstag, 24. Januar 2019

Bild: Pixabay / DCG:MAK - Lizenz

Scrum wird in Workshops häufig als Schleife (Loop) visualisiert, mit den Rollen in der Mitte, den Meetings und Artefakten am Rand und jeweils einem Quality Gate am Anfang und am Ende. Das am Ende ist hier bereits thematisiert worden, die Definition of Done (DoD), was noch fehlt ist das Gate am Anfang, die so genannte Definition of Ready (DoR).

Unter ihr versteht man üblicherweise eine Liste von Kriterien die erfüllt sein müssen bevor eine Anforderung zur Umsetzung in einen Sprint übernommen wird. Häufig anzutreffen sind z.B. "Alle Teammitglieder müssen die Anforderung verstanden haben", "Es müssen validierbare Akzeptanzkriterien formuliert sein" oder "Die Umsetzung dieser Anforderung muss einen erkennbaren Mehrwert erzeugen".

Der Hintergrund der DoR ist schnell erkennbar. Mit ihr lässt sich verhindern, dass unklare, nicht testbare oder betriebswirtschaftlich unsinnige Ideen in die Umsetzung geraten. Die in diesen Fällen unausweichlichen (und oft unschönen) Diskussionen können so unterbunden werden noch bevor es einen Anlass für sie gibt. Das Team kann sich stattdessen auf seine eigentliche, wertschöpfende Arbeit konzentrieren.

Für viele überraschend: trotz dieser Vorzüge ist die Definition of Ready kein offizieller Teil von Scrum sondern gehört zu den vielen good Practices, die man zwar befolgen, genau so gut aber auch weglassen kann. Da sie weit verbreitet ist kann das nicht an fehlender Bekanntheit liegen sondern ist von Schwaber und Sutherland bewusst beabsichtigt worden. Warum das?

Das mit der DoR verbundene Risiko ist, dass Teams sich dadurch versehentlich Wasserfall-artige Strukturen aufbauen können. Ein zu restriktives Beharren auf von allen Teammitgliedern verstandene Anforderungen wird zwangsläufig einen solchen Beschreibungsumfang zur Folge haben, dass wieder eine vorgelagerte Konzeptionsphase entsteht in der Detailspezifikationen erzeugt werden. Das wäre nicht mehr im ursprünglichen Sinn der Agilität.

Darüber hinaus ist eine zu detaillierte Definition of Ready ein Indikator für gleich zwei Antipattern: für unzureichende Backlog Refinements und für ein Misstrauen eines Entwicklungsteams gegenüber seinem Product Owner. Würden zur Umsetzung vorgesehene Anforderungen ausreichend besprochen (nicht beschrieben!) und würde das Team darauf vertrauen, vom PO nur umsetzbare Aufgaben zu erhalten - ein zusätzliches Quality Gate wäre unnötig.

Eine DoR ist aus diesen Gründen ein zweischneidiges Schwert. Sie kann unerfahrenen Teams bei der Umsetzung von Scrum helfen, kann aber auch versehentlich dazu führen, dass die Methodik sich selber aushebelt. Von vielen Teams wird sie daher gar nicht erst eingeführt oder irgendwann wieder abgeschafft.

Montag, 14. Januar 2019

Bild: Pixabay / 123nurik123 - Lizenz

Wegen irgendeiner Fernsehsendung hört man gerade viel von einer Japanerin mit dem (Künstler?)Namen Marie Kondo. Bekannt geworden ist sie durch die von ihr entwickelte Konmari-Methode zum Aufräumen von Wohnungen und Garderoben, die mittlerweile aber auch für Büros, Werkstätten, Schreibtische, etc. angewandt wird. Das Ganze lässt sich aber noch weiter treiben - warum sollte man Konmari nicht auch für Product Backlogs anwenden? Auch die sind ja oft hoffnungslos überladen und zugemüllt.

Als ersten Schritt definiert Kono das Commitment. Dieses geht bei ihr über die engere Bedeutung des sich verpflichtet Fühlens hinaus und enthält auch einen Zeitplan. Es sollte ein Zieldatum geben bis zu dem die Aufräumarbeiten abgeschlossen sein müssen, es sollte Zwischenziele geben und es sollte einen oder mehrere Zeiträume geben die für diese Arbeit reserviert sind, z.B. jeden Werktag von 10 bis 11 bis zum Ende des Monats.

Als nächstes sollte Klarheit über das angestrebte Zielbild herrschen. Dazu sollte dieses in seinem Idealzustand beschrieben werden. Für ein Backlog bedeutet das: geordnet (z.B. nach Business Value, MVPs, Sprintzielen, oder Roadmap) und mit einer absteigend geringer werdenden Granularität. Basierend darauf lassen sich die Einträge später neuordnen, teilen oder zusammenlegen.

Das eigentliche Aufräumen beginnt dann mit dem Ausmisten. Orientiert am vorher verfassten Zielbild kann alles weg was nicht dazu passt. Für viele Teams dürfte das der schwerste Teil dieser Übung sein, gleichzeitig ist es auch der wichtigste. Ist die Gesamtmenge übersichtlicher geworden fällt das Sortieren leichter und geht schneller voran. Eine weitere Hilfe besteht darin, sich um Nostalgie und Emotionen weckende Anforderungen als letztes zu kümmern, um nicht abgelenkt zu werden.

Auch bei der Aufteilung der Arbeitsschritte empfiehlt Konmari ein anderes Vorgehen als das meistens anzutreffende. Statt sich von einem Ort zum nächsten vorzuarbeiten entsprechen die Arbeitsphasen verschiedenen Kategorien. Bezogen auf das Produktmanagement bedeutet das, dass nicht zuerst Jira, dann Salesforce und dann HP-ALM abgearbeitet werden sondern z.B. erst toolübergreifend alle Innovationsvorhaben, dann die Servicetasks und dann die Bug-Tickets.

Während des Aufräumens sollte Ordnung unmittelbar entstehen. Statt neue Haufen zu bilden, die dann (hoffentlich) später sortiert werden sollte alles sofort an den (nach aktuellem Kenntnisstand) finalen Ort wandern. Um Agile-Buzzwords zu benutzen: jedes Aufräum-Incement sollte eine Definition of Done erfüllen und unmittelbaren Mehrwert stiften.

Über dem gesamten Prozess sollte im klassischen Konmari das Leitmotiv des Erzeugens von "Sparking Joy" stehen, also des Verstrahlens von Freude. Als Gegenstück im Produktmanagement würde sich das weit verbreitete "Delighting Customers" anbieten. Im Hinterkopf sollte demnach während des ganzen Aufräumvorganges stehen, dass das Endergebnis den höchstmöglichen Kundennutzen zum Ziel haben sollte.

In diesem Sinne - ab zum Aufräumen.

Nachtrag 04.02.:

Marie Kondo: What is it?
Me: It's a feature suggestion that isn't validated by any insight what so ever.
Marie kondo: Does it spark joy
Me: Woudn't know as it's we haven't asked any customers about it.
Marie kondo: Thank it, then discard it.
— Seb Sabouné (@SebSab) 4. Februar 2019

Dienstag, 12. Juni 2018

Bild: Pexels / Simon Migaj - Lizenz

Aller Anfang ist hart, aber wenn es eine Organisation einmal geschafft hat agile Strukturen bei sich einzuführen ist sie zu Erstaunlichem in der Lage. In kurzen Abständen kann sie ihren Kurs anpassen, neue Wege in Technik und Fachlichkeit gehen, neue Kunden ansprechen und mit neuen Partnern kooperieren. Das alles vermag sie nicht nur einmal zu tun sondern beliebig oft, immer wieder und wieder. Und wenn sie Pech hat wird es dann genau so kommen.

So schön die mit Agilität einhergehende Reaktionsgeschwindigkeit auch ist, sie kommt mit einem Preis. Fertige Features wieder auszubauen oder bereits beschlossene Pläne zu verwerfen wird immer dazu führen, dass gewisse Aufwände umsonst gewesen sind und ggf. sogar mit Zusatzaufwänden rückgängig gemacht werden müssen. Wo das regelmässig passiert (und das ist an mehr Stellen als man denken sollte) führt es zu hohem Ressourcenverbrauch und zu zurückgehender Motivation der Mitarbeiter, die das Gefühl bekommen umsonst zu arbeiten. Ein solcher Zickzack-Kurs sollte also möglichst vermieden werden.

Eine gute Möglichkeit dem entgegenzuwirken ist die Schaffung einer übergreifenden Produktvision für die beteiligten Teams, z.B. "Wir wollen für unsere Kunden alle Bankdienstleistungen auf dem Handy verfügbar machen". Die hilft zum einem dabei unnötige Features zu identifizieren und gar nicht erst zu bauen (etwa eine nur auf dem Desktop verfügbare Anwendung), zum anderen kann dadurch erkennbar werden wo noch zu füllende Lücken in der Anwendungslandschaft sind die die Teams noch unter sich aufteilen müssen (z.B. wenn auf dem Handy noch keine Kontoauszüge einsehbar sind).

Um die Teams nicht zu sehr einzuengen (was Agilität und Reaktionsgeschwindigkeit reduzieren würde) sollte eine Produktvision nicht zu stark ausformuliert sein. Zwar sind unter dem einen, plakativen Satz häufig noch einige erklärende Zeilen zu finden, sobald diese aber mehrere Absätze (oder noch schlimmer: Seiten oder Kapitel) umfassen ist das ein klares Zeichen für einen zu hohen Detaillierungsgrad. Wenn sie es wollen können Teams sich aus der grossen Vision kleinere Teilvsionen ableiten, aber wenn das geschieht sollten sie es selbst tun, nicht ein Manager oder Koordinator. Das würde die Selbstorganisation untergraben.

Wer die übergreifende Produktvision formuliert kann übrigens von Produkt zu Produkt und von Firma zu Firma unterschiedlich sein, vom Firmeninhaber bis zu einer PO-Community ist alles denkbar. Demjenigen oder denjenigen sollte nur klar sein, dass es ein Balanceakt ist. Wie oben erwähnt: ohne klare Vision droht Beliebigkeit, bei zu viel Details erstarren die Strukturen. Der anzustrebende Punkt liegt irgendwo in der Mitte dazwischen.

Dienstag, 22. Mai 2018

Bild: Pexels / Daria Shevtsova - Lizenz

Praktisch jeder der jemals an der Erstellung eines komplizierten oder komplexen Produkts mitgewirkt hat dürfte sie kennen - die Diskussionen um die Rand-, Umgebungs- und Kontextfaktoren der Produktentwicklung und darum ob diese abnahmerelevant sind. Die Kompatibilität mit bestimmten (Produktions-)Daten gehört dazu, Schnittstellen-Anbindungen, Dokumentation, Absicherung durch Tests und vieles mehr. "Das hätte man sich doch denken können.", "Das ergibt sich aus dem gesunden Menschenverstand" und ähnliche Argumente tauchen immer wieder auf und belegen, dass die Verständnisse an diesen Stellen weit auseinandergehen.

Um dem entgegenzuwirken gibt es in Scrum (und auch in vielen Teams die andere agile Vorgehensweisen bevorzugen) die Definition of Done (DoD), eine verbindliche Regelung, die definiert was alles gegeben sein muss damit eine Abnahme stattfinden kann. Wichtig ist dabei nicht etwa, dass die DoD umfassend alle Eventualitäten regelt. Das würde zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen wären. Besser sollten dort nur die Bereiche geregelt werden bei denen die Teammitglieder ein unterschiedliches Verständnis haben. Dieses durch gemeinsame Entscheidungen des gesamten (Scrum) Teams zu vereinheitlichen ist der eigentliche Mehrwert.

Ich würde immer empfehlen mit einer sehr schlanken Definition of Done zu beginnen, die z.B. nur definiert auf welcher Umgebung eine Abnahme stattfindet und dass mindestens zwei Personen an jeder Anforderung gearbeitet haben müssen (Vier Augen-Prinzip). Mit der Zeit können dann weitere Kriterien dazukommen, etwa das notwendige Ausmass von Testautomatisierung und Dokumentation oder die Sprachen in denen das Produkt verfügbar sein muss. Es ist erfahrungsgemäss immer einfacher einen geringen Umfang zu erweitern als einen grossen zurückzuschneiden, zumindest gilt das für neue oder noch unerfahrene Teams. Bei ihnen nimmt der Umfang der DoD häufig über einige Monate immer weiter zu.

Erfahrene Teams tun sich mit der Reduzierung auf das Wesentliche leichter. Viele Teams mit denen ich gearbeitet habe haben ihre DoD früher oder später auf wenige Sätze zusammengestrichen, die dann eher einen Sinn reflektiert haben als konkrete Vorgaben zu machen. Eines meiner Lieblingsbeispiele ist ein Team dessen DoD aus nur einem Satz bestand: "Eine Anforderung ist abgenommen wenn der Product Owner Kuchen mitbringt". Das ganze Team hatte ein einheitliches und sehr hohes Qualitätsverständnis, und der PO war bekannt dafür, den "Abnahme-Kuchen" nur dann mitzubringen wenn das neue Feature diesem Verständnis zur Gänze entsprach und niemand mehr Widerspruch einlegte. In diesem Zusammenhang reichte dieser eine, zunächst wunderlich klingende Satz als DoD völlig aus.

Bleibt noch die Frage: was ist wenn mehrere Teams an einem gemeinsamen Produkt arbeiten, sollte man die Definition of Done in einem solchen Fall nicht vereinheitlichen? Die Antwort darauf ist ein klares Ja. Aber: der Knackpunkt ist das Wort "man". Mit ihm ist nicht etwa ein Manager, eine QA-Abteilung oder eine sonstige übergeordnete Person oder Struktur gemeint. Die gemeinsame DoD muss gemeinsam von den beteiligten (Scrum) Teams entwickelt werden. Nur so kann sichergestellt werden, dass sie bedarfsgerecht, unbürokratisch und von den Beteiligten nicht als Fremdkörper empfunden ist (das sieht auch der Scrum Guide so). Alles andere wäre ein Antipattern.

Donnerstag, 26. April 2018

Bild: Wikimedia Commons / Santeri Viimäki - CC BY 4.0

Kurze Frage: welcher Begriff wird im Scrum Guide ganze 26 mal erwähnt [Edit: seit 2020 18 mal], findet sich aber in sehr vielen Scrum Teams nicht wieder? Die Antwort: das Sprintziel, bzw. Sprint Goal. Obwohl Sprintziele von offensichtlich so großer Bedeutung sind würde ich sagen, dass sie bestenfalls in der Hälfte der über 100 Teams mit denen ich über die Jahre zusammengearbeitet habe verwendet wurden. Die anderen haben einfach nur mehr oder weniger zusammenhängende Arbeit in ihre Sprints gezogen, im Normalfall die obersten User Stories / Anforderungen ihres Product Backlogs. Und das ist ein Problem, denn ohne diese Ziele sind einige Vorteile schwerer erreichbar.

Ein Sprintziel hilft dem Product Owner bei der Planung. Wie in anderen Vorgehensweisen lassen sich auch in Scrum Aufgaben vom Grossen ins Kleine herunterbrechen. Aus der Produktvision wird z.B. eine Teilvision, daraus einige Meilensteine und daraus mehrere Sprintziele. Auch die können und sollen einem Inspect & Adapt unterliegen, trotzdem (oder gerade deswegen) können sie ein gutes Werkzeug sein um Arbeit in Etappen einzuteilen, die man nach und nach planen und angehen kann.

Ein Sprintziel hilft dem Product Owner bei der Priorisierung. Was im Backlog weiter oben stehen sollte und was nicht ist oft nur schwer zu bestimmen. Ist z.B. eine bessere Exportierbarkeit von Kundendaten wichtiger als eine bessere Importierbarkeit von Stammdaten? Wer kann das sagen? Werden die einzelnen Anforderungen zu Sprintzielen gruppiert kann das einfacher sein. Wenn das nächste Sprintziel z.B. lautet, bis zum bald bevorstehenden Stichtag DSGVO-kompatibel zu sein, dann ist klarer was dazugehören sollte (Kundendaten exportieren) und was nicht (Stammdaten-Import).

Ein Sprintziel hilft einem Team dabei fokussierter und konzentrierter zu arbeiten. Gerade bei komplexen und komplizierten Themen gibt es kaum einen größeren Produktivitäts-Hemmer als häufiges Kontext Switching. Sich in kurzen Abständen in immer neue Themen eindenken und immer neue Schnittstellen und Abhängigkeiten klären zu müssen kann in absurdem Ausmass Zeit fressen. Umgekehrt kann das fokussierte Arbeiten an einem Themenkomplex für Synergieeffekte im Denken und Umsetzen sorgen, die vieles beschleunigen.

Ausserdem hilft ein Sprintziel auch bei der Erfolgsmessung, und zwar in der denkbar einfachsten Weise. Man muss sich nur fragen: Haben wir das Sprintziel erreicht, ja oder nein? Damit das möglich ist müssen die Formulierungen natürlich klar und überprüfbar sein, also nicht "Wir wollen ein besseres Nutzungserlebnis bieten" sondern "Wir wollen die Anzahl der bis zum Geschäftsabschluss notwendigen Mouseclicks unter 20 drücken". Als Nebeneffekt führen die dafür nötigen Überlegungen und Diskussionen auch zu einem besseren Verständnis dessen was mit der Anforderung eigentlich gewollt ist.

Zuletzt noch ein Hinweis der selbstverständlicher klingt als er ist - es sollte ein Sprintziel geben, nicht mehrere. Auch hier ein Beispiel: "Wir wollen die die Performance erhöhen und das Design von Rot-Blau auf Grün-Silber umstellen" ist zwar ein Satz, trotzdem sind es mehrere Ziele. Ich habe mit Teams gearbeitet, die alle Sprintziele abgelehnt haben in denen ein Komma, ein Punkt oder die Wörter "und" und "ausserdem" vorkamen. Es hat ihnen geholfen.

Donnerstag, 15. Februar 2018

Bild: Freegreatpicture / Max Pixel - CC0 1.0

Es gibt im agilen Umfeld Themen die immer weitere Informationen preisgeben, je mehr man sich in sie vertieft. Story Points gehören auf jeden Fall dazu, mit ihnen kann man wesentlich mehr machen als es auf den ersten Blick scheint. Bevor es darum geht aber zunächst zum Grundsätzlichen: Story Points sind eine neutrale Schätzgröße, mit der man den Umsetzungsaufwand von Anforderungen schätzen kann ohne berücksichtigen zu müssen wer genau die Umsetzung vornehmen wird. Mehr dazu hier. Es bleibt allerdings eine Frage - warum dann der wunderliche Name? Wäre "Requirement Points" nicht passender?

Der Grund für die Benennung liegt darin, dass mit Story Points ursprünglich im Extreme Programming User Stories geschätzt wurden. Ein kurzer Exkurs: User Stories sind Anforderungen in einfacher Sprache, die (End)Anwender, Use Case und Business Value in einem Satz benennen. Mehr dazu hier. Diese exklusive Verwendung gibt es heute kaum noch, mit Story Points werden nicht mehr nur User Stories geschätzt sondern alle anderen Anforderungen genauso. Manche Teams nennen auch einfach jede Anforderung User Story, allerdings ist das dann nicht mehr das was damit beabsichtigt ist.

Um Missverständnissen vorzubeugen, Story Points als generische Schätzeinheit für alle Anforderungen zu verwenden ist nicht per se schlecht. Trotzdem kann es Sinn machen ihre Benutzung auf User Stories zu beschränken. Denn: wenn der (End)Benutzer derjenige ist für den Software gebaut wird, und wenn alles was er damit tun kann ein Use Case ist der sich mit User Stories abbilden lässt, dann kann (und sollte) man bei allem was keine User Story ist die Sinnfrage stellen.

Natürlich verfolgen auch "Nicht-User Stories" einen Zweck. Code wird bereinigt, Lastfähigkeit hergestellt, Architektur wird geradegezogen, Tests werden automatisiert und halbfertige Funktionen werden komplettiert. Der Punkt ist nur der - das kann man auch gleich machen, als Teil einer User Story die benutzbare Funktionalität liefert. Diese Tätigkeiten auf die lange Bank zu schieben ist nichts weiter als das Anhäufen organisatorischer Schulden, wodurch alles länger dauert und teurer wird.

Wenn also alles was dem Anwender Nutzen bringt als User Story formuliert werden kann, und wenn praktisch alle nichtfunktionalen Anforderungen in diesen User Stories unterkommen können, dann kann man auch sagen: User Stories sind das was Mehrwert liefern, der gesamte Rest ist Waste. Unsinnige Arbeit - oder die Folge unsinniger Arbeit.

Die Anwendung von Story Points nur auf User Stories bedeutet in diesem Fall, dass deren Durchschnittsmenge pro Sprint, die Velocity, nur Mehrwert erzeugende Arbeit anzeigt und den Rest ignoriert. Für Teams kann das sehr wertvoll sein. Ihre Velocity zeigt nicht mehr womit sie Zeit verbracht haben (🡢 Output) sondern womit sie Wert generiert haben (🡢 Outcome). Und mit dieser Erkenntnis können sie daran arbeiten den Output zu senken und den Outcome zu erhöhen.

Die Negativseite dieses Ansatzes ist natürlich, dass in Teams mit vielen "Nicht-User Stories" die Velocity nicht mehr beim Planen hilft. Allerdings - dort wo es viele organisatorische Schulden gibt ist Planung ohnehin nur eingeschränkt möglich, man bleibt zu häufig in den Spätfolgen der eigenen Versäumnisse hängen.

Donnerstag, 7. Dezember 2017

Bild: Pxhere - CC0 1.0

Wenn immer es möglich ist sollten Scrum Teams versuchen ihre Anforderungen in Form von User Stories zu verfassen. Das ist zwar nicht im Scrum Guide vorgeschrieben sondern kommt aus dem Extreme Programming und es muss auch nicht immer in der klassischen Form Als [Benutzer mit Rolle ...] möchte ich [Aktion ... durchführen können] um [Mehrwert ... zu haben] sein (es gibt auch andere), es empfiehlt sich aber trotzdem so vorzugehen. Die Vorteile sind unverkennbar.

Um im Sinn des agilen Prinzips Maximizing the amount of work not done vozugehen lohnt es sich darüber nachzudenken wie man die Menge neu implementierten Codes so gering wie möglich halten kann. Ein weithin beliebter Ansatz ist dabei die Fokussierung auf den (End)Anwender. Nur was der tatsächlich benutzen kann ist von Wert, alles andere kann im Zweifel weggelassen werden. Folgerichtig sollten Anforderungen idealerweise auf Use Cases (Anwendungsfällen) beruhen.

User Stories greifen diese Idee auf und reichern sie um weitere Elemente an: in verständlicher Sprache erklären sie wer der Anwender ist, welche neue Funktion er braucht/bekommt und welcher Mehrwert damit verbunden ist. Neben dem oben genannten häufigsten Muster gibt es auch andere Variationen, etwa Um [Ziel ... zu erreichen] ermöglichen wir [Benutzer mit Rolle ...] die Aktion [...] durchzuführen oder ganz schlicht Nutzer: [...], Aktion: [...], Mehrwert: [...].

Natürlich werden trotzdem immer wieder Anforderungen auftauchen die nicht in dieses Muster passen: Arbeit an technischen Komponenten, Anpassungen an Architekturvorgaben, Bugfixes, Absicherung durch Tests, Code Cleaning, Abbau technischer Schulden, etc. Da viele von ihnen ein Zeichen von fehlender Anwender-Zentrierung oder (Spät)Folgen nachlässiger Arbeit sind kann es hilfreich sein das Verhältnis zu tracken: wieviel Prozent der umgesetzten Anforderungen sind User Stories und wie viele nicht? Bei einem zu niedrigem User Story-Anteil kann sich ggf. eine Retrospektive lohnen.

PS: es gibt leider auch Teams in denen der Begriff User Story ein generisches Synonym für Anforderungen aller Art ist. Mitglieder dieser Teams mögen sich bitte zur Behandlung in der nächsten Coach-Klinik melden.

Montag, 11. September 2017

Bild: Wikimedia Commons / Abdulrahman Raofi - CC BY 4.0

Wieder etwas dazugelernt: in einem zur Zeit von mir gecoachten Team wird eine Art von Anforderungsbeschreibung verwendet die ich noch nicht kannte - die Erfolgsgeschichte, bzw. Erfolgs-User Story. Sie beschreibt einen (noch nicht eingetretenen) Fortschritt der Produktentwicklung aus der Sicht desjenigen, der ihr Ergebnis bereits benutzen kann. Ein Beispiel:

"Zum Glück sind ist die Performance unseres Systems besser geworden, gerade noch rechtzeitig vor der Einspeisung der Partnerdaten. Jetzt können wir sie nutzen ohne durch lange Ladezeiten aufgehalten zu werden."

Wie im Fall normaler User Stories gibt es auch hier präzisierende Akzeptanzkriterien, allerdings in einer neuen Form: "Das war nur möglich weil der Datenbankindex angepasst wurde." "Das war nur möglich weil Duplikate bereinigt wurden.", etc.

Bei genauerer Betrachtung steckt etwas Ähnliches dahinter wie im Fall einer normalen User Story, nämlich der grundlegende Use Case mit angehängtem Business Value, bei Bedarf ergänzt um eine Rolle. Auch die Akkzeptanzkriterien sind trotz der neuen Formulierung inhaltlich mit den alten vergleichbar. Der Mehrwert dieses neuen Ansatzes ergibt sich aus seinem Einsatz in der Zusammenarbeit mit Kunden, Anwendern und Auftraggebern.

Im Rahmen von Anforderungs-Workshops kann man jetzt Fragen stellen wie "Welche Erfolgsmeldung würden sie als nächstes hören wollen?" oder "Welche Erfolgsmeldung möchten Sie als nächstes verkünden können?". Anders bei der klassischen Frage "Was brauchen Sie alles?" ist in einer Antwort darauf bereits eine Priorisierung eingeflossen. Darüber hinaus wird auch die (implizite) Erwartungshaltung aufgelöst, eine Anforderung umfassend beschreiben zu müssen.

Auch hier bedarf es natürlich einer gewissen Übung, damit ein Stakeholder nicht auf die Idee kommt ein "Zum Glück ist alles fertig"zu verfassen. Sobald das geschafft ist kann eine Erfolgs-User Story aber eine gute Ergänzung zu der klassischen Form sein.

Dienstag, 2. Mai 2017

Nicht in jedem Planning Poker-Kartenset gibt es sie, dabei sollte es sie in jedem geben: eine Karte mit der Nummer Null. Sie kann tatsächlich bei den Estimation-Meetings nötig sein und ihr Einsatz kann größere Folgen haben als man denken sollte.

Zunächst - kann es wirklich sein, dass ein Product Owner seinem Team eine Anforderung mitbringt deren Umsetzung mit keinem Aufwand verbunden ist? Erstaunlicherweise ja, nämlich dann wenn die Anwendung dieses Feauture bereits enthält. Das ist typischerweise bei eingekaufter Standardsoftware der Fall, über deren Funktionsumfang sich die kaufende Firma nicht vollständig klar gewesen ist, es gibt aber auch andere Fälle (z.B. wenn ein früherer Product Owner die Anforderung bereits umsetzen liess und vergessen wurde das zu dokumentieren).

Im Estimation Meeting kann das Team jetzt die Karte mit dem Wert 0 einsetzen um sich darauf zu einigen, dass es hier keine Komplexität, bzw. keinen Aufwand sieht. Dieser Wert kann dann in die Anforderung eingetragen werden, um sie gegebenenfalls zurück ins Product Backlog zu schieben. Bleibt nur noch die Frage - warum sollte man das tun? Welchen Sinn hat es, eine solche Anforderung zu behalten und nicht zu löschen? Nun, dafür gibt es mehrere Gründe.

Kommunikation:
Null Punkte-Anforderungen können im nächsten Review oder Stakeholder-Meeting eingesetzt werden um den Stakeholdern zu erklären, dass ihre Wünsche nicht mehr umgesetzt werden müssen. Das ist nicht nur transparent und höflich (niemand mag es wenn seine Anforderungen einfach verschwinden), es dient auch der Rückversicherung: ist wirklich nichts mehr zu tun oder gab es doch ein Missverständnis?

Dokumentation:
Vor allem im "regulierungsintensiven Umfeld" (Konzerne und Behörden) kann es vorkommen, dass Anforderungen nachträglich zum Gegenstand von Auditierungen und Revisionen werden. In derartigen Fällen kann es viel Arbeit sparen wenn klar zu sehen ist warum sie nie Teil eines Sprints gewesen sind und trotzdem als erledigt gekennzeichnet sind.

Erinnerung:
Ein Grenzfall. Es kann sein, dass minimale Restaufwände zu erledigen sind, zum Beispiel das Zurücksetzen von Passwörtern oder die temporäre Erteilung von Berechtigungen. Derartige, wenige Minuten in Anspruch nehmende Aufgaben werden von manchen Teams als Null Punkte-Anforderung in den Sprint genommen um sicherzugehen, dass sie auch tatsächlich erledigt werden.

Darüber hinaus mag es noch weitere Verwendungszwecke geben, jedes Team ist da frei seinen eigenen Weg zu finden. Denn auch das ist klar: da Story Points kein offizieller Teil von Scrum sind kann letztendlich frei entschieden werden ob und wie sie benutzt werden.

Montag, 20. Februar 2017

Bild: Unsplash/Olu Eletu - Lizenz

Beim Bonner Scrumtisch letzte Woche war meine Session diejenige mit dem wenigsten Zuspruch. Vielleicht waren die anderen interessanter, vielleicht bin ich unbeliebt, vielleicht lag es aber auch am Thema: es war "Business Value". Bei derartigen Meetups machen Scrum Master und Agile Coaches den Großteil der Teilnehmer aus, und mein Erfahrungswert ist der, dass die meisten sich bei diesem Thema nicht zuständig fühlen. Für den Business Value wird im besten Fall auf den Product Owner verwiesen (der dann oft auch untätig ist), im schlechtesten Fall heisst es "der kann für unsere Anwendung nicht berechnet werden".

Die Folgen dieser Haltung sind offensichtlich: ich habe in den letzten Jahren eine mittlere zweistellige Zahl an Scrum Teams begleiten dürfen, mir fallen aber keine fünf ein in denen Anforderungen anhand ihres Geschäftswertes priorisiert wurden¹. Genau das was mit Scrum erreicht werden sollte trat dann oft nicht ein: die frühe Lieferung benutzbarer und Mehrwert schaffender Software. In den betroffenen Unternehmen wurde der Ruf der Methode dadurch beschädigt - man hatte zwar "shippable Code", der tatsächliche Mehrwert entstand aber so spät, dass behauptet werden konnte, dieser Zeitpunkt wäre mit einem Wasserfall-Vorgehen genauso schnell erreicht worden.

Ja aber, haben mir Scrum Master an dieser Stelle regelmäßig entgegnet, der Business Value liegt nun mal im Aufgabenbereich des Product Owners. Ich kann dem ja schlecht sagen wie er sein Backlog priorisieren soll, und wenn ich es doch tun würde, dann würde ich gegen die Aufgabenverteilung in Scrum verstossen. Allerdings lagen sie an dieser Stelle so falsch wie es falscher kaum sein könnte. Der Scrum Guide ist mehr als eindeutig: The Scrum Master serves the Product Owner in several ways, including [...] Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.

Machen wir uns nichts vor, diese Aufgabe ist nicht einfach. Die meisten Scrum Master die ich kenne waren ursprünglich Software-Entwickler, Teamleiter oder Projektmanager, die wenigsten haben einen betriebs- oder sonstwie -wirtschaftlichen Hintergrund. Und oft genug kommt man an eine Stelle an der man nicht weiter weiss: wie ist z.B. der Wert einer User Story mit der eine Seite von adaptive auf responsive Design umgestellt wird? Aber [Populismus on] wenn es einfach wäre könnte es jeder [/Populismus off]. Wie das im Detail aussieht ist dann nochmal ein eigenes Thema.

Wichtig ist die Erkenntnis, dass man als Scrum Master für den Business Value zuständig ist und sich daher intensiv damit beschäftigen sollte.

¹Weitere haben sich von mir überreden lassen es zu versuchen, haben aber nach kurzer Zeit aufgegeben

Donnerstag, 12. Januar 2017

Bild: Wikimedia Commons/Evan Amos - CC0 1.0

Das Kleinschneiden von Anforderungen in User Stories die innerhalb eines Sprints umgesetzt werden können kann sehr erklärbedürftig sein. Selbst erfahrene Product Owner kommen immer wieder an eine Stelle an der sie Schwierigkeiten bekommen. Für die von mir gecoachten POs habe ich irgendwann begonnen eine Übersicht zu erstellen nach welchen Kriterien man das Messer ansetzen kann. Sie ist sicher noch nicht vollständig, hat aber einigen Teams weiterhelfen können.

Nach MVP-Kriterien
Vor allem dort sinnvoll wo schnelle vorzeigbare Ergebnisse nötig sind. Die Story sollte die kleinstmögliche nutzbare Funktionalität ergeben, selbst wenn sie noch "aufgehübscht" werden muss. Das passiert dann in späteren Stories.

Nach Arbeitsschritten
Der Klassiker. Ich möchte mich einloggen. Ich möchte eine personalisierte Willkommensseite sehen. Ich möchte eine neue Seite anlegen, etc. Jeder Schritt kann eine eigene User Story sein.

Nach Happy-/Unhappy Path
Darauf kommen erstaunlich wenige. Happy Path: Ich möchte mein Geburtsdatum eingeben können. Unhappy Path: Ich möchte eine Fehlermeldung angezeigt bekommen wenn ich in dieses Feld Buchstaben eingebe. Das kann man sehr gut separat umsetzen.

Nach GUI-Elementen
Im oberen Seitendrittel möchte ich meinen Benutzernamen und mein Profilbild sehen. Im mittleren Seitendrittel möchte ich Statusmeldungen eingeben und sehen können. Im unteren Seitendrittel möchte ich eine Liste meiner älteren Statusmeldungen sehen.

Nach Benutzer-Rollen
Zu Beginn gibt es bei diesem Vorgehen nur eine Rolle: den Administrator, der alles sehen und machen kann. Mit den weiteren Rollen werden nach und nach Beschränkungen eingeführt: Redakteur, Auditor, Gast, etc.

Nach Datei-/Daten-Typen
Macht z.B. Sinn wenn verschiedene Dateitypen importierbar und lesbar sein müssen: Erst CSV, dann XLSX, dann Word, dann PDF, dann PPT.

Nach Datenquellen/Schnittstellen
Wenn verschiedene andere Systeme angeschlossen werden müssen, z.B. die der Fabrik, der Marketing-Abteilung, der Tochtergesellschaft und des Lieferanten.

Nach Performance-Bedürfnissen
Schon etwas technischer. Zu Beginn kann man etwa eine Abfrage über die gesamte (noch kleine) Datenbank laufen lassen, später mit Verschlagwortung oder mehr Rechenleistung die Verarbeitung größerer Datenmengen sicherstellen.

Nach "Low hanging Fruits"
Wenn Teile der Anforderungen komplex oder unklar sind kann man sich auf die anderen konzentrieren. Dadurch gewinnt man die Zeit um die schwierigeren Bereiche zu analysieren und zu verstehen (siehe unten: Spike).

Nach Testszenarien
Auch hierauf kommt nicht jeder. Wenn Anforderungen einen hohen Testaufwand mit sich bringen kann man auch den reduzieren indem man kleinere Stories schneidet. Möglichkeiten wären etwa der Login-Status oder Datumskonstellationen.

Nach Endgeräten
Ich erinnere mich an ein Projekt in dem die Anwendung immer zuerst für das iPad des Projektleiters optimiert wurde. Je nach Gerät/Betriebssystem (Apple, Android, Windows, Kindle, Tolino) können andere Anpassungen nötig sein.

Nach Browsern
Ähnlich wie der letzte Ansatz. Eine klassische Reihenfolge wäre Safari, Chrome, Firefox, Edge, IE10, IE9, IE8, IE7. Masochisten können auch bis auf den IE6 runtergehen.

Der Sonderfall: Spike
Eine Forschungsaufgabe um schlecht geschriebene und/oder dokumentierte Software zu verstehen. Sollte nur sparsam und timeboxed eingesetzt werden, da es sonst schnell ausufern kann.

Wie oben gesagt: es gibt bestimmt noch viele weitere Möglichkeiten. Ein Großteil dürfte aber durch diese Liste abgedeckt sein.

Donnerstag, 20. Oktober 2016

Bild: Piqsels - Lizenz

Warum zu große Backlogs regelmässig ausgemistet werden sollten habe ich bereits beschrieben, jedem Product Owner lege ich den regelmässigen Griff zur Heckenschere ans Herz. Nicht festlegen würde ich mich auf die maximale Zahl vertretbarer Backlog Items, das kann je nach Einzelfall unterschiedlich sein. Meine Faustregel ist aber, dass man sich spätestens ab dem hundertsten Eintrag Gedanken machen sollte. Konkrete Ratschläge kann ich dagegen zu etwas anderem geben, nämlich dazu nach welchen Kriterien aussortiert werden sollte. Da gibt es mehrere Möglichkeiten:

Nach Priorität

Zugegeben, ein No Brainer. Je weiter nach unten eine Anforderung priorisiert ist desto verzichtbarer ist sie, weshalb man es sich ganz einfach machen kann - weg mit den unwichtigsten 10 Prozent und das Problem ist gelöst. Aber apropos Problem: an dieser Stelle gibt es eines. Die wichtigsten Anforderungen bekommt man noch irgendwie identifiziert, aber in den meisten Backlogs folgt danach eine amorphe Masse in der alles irgendwie gleich (un)wichtig ist. Wie soll man da mit dem Sortieren weitermachen? Die häufigste Antwort darauf lautet:

Nach Business Value

Okay, noch ein No Brainer. Je geringer der erzeugte Mehrwert desto eher kann eine Anforderung weg. Benutzen wir also das als Vergleichswert und wir haben ... schon wieder Schwierigkeiten. Ein paar zentrale Faktoren für ein funktionsfähigeses MVP oder eine bessere Vermarktbarkeit lassen sich natürlich finden, aber dann - wieder Unklarheit. Ist die intuitive Hauptnavigation jetzt wertvoller als der einfache Bezahlvorgang oder der schnelle Login? Viel Spass beim Entscheiden. Aber es gibt ja weitere Priorisierungskriterien. Zum Beispiel:

Nach Alter

Hier werden die Ersten widersprechen. Denn ich würde sagen: je älter eine Anforderung ist desto eher kann sie weg. Das widerspricht für viele den Denkgewohnheiten, schließlich könnte man meinen, dass eine Umsetzung um so dringlicher wird je länger sie sich hinzieht. Ich sehe das umgekehrt - wenn eine Anwendung so lange Zeit ohne ein Feature funktioniert, dann kann das nicht wirklich wichtig gewesen sein. Aber das nächste Dilemma kommt bereits um die Ecke - gerade zu Beginn kippen üblichweise alle Stakeholder gleichzeitig ihre Wünsche ein, wodurch ihre Anforderungen alle ähnlich alt sind. Doch auch hier gibt es einen Ansatz für eine weitere Auswahl:

Nach Stakeholder

Ja, genau, nach Stakeholder. Es soll weitergehen, es soll mehr Zeit geben, mehr Budget, mehr Ressourcen? Dann hilft es, wenn man nett zu dem ist der das Geld in der Tasche hat. Du kriegst Dein Feature, ich meine Ressourcen, beide sind glücklich. Ein Kuhhandel? Ja, ist es. Opportunistisch? Vermutlich auch. Aber hey, so ist es nun mal in der Welt. Ein grosses Geben und Nehmen. Allerdings, selbst wenn wir das machen bleiben oft noch Anforderungen übrig bei denen man nicht sicher sein kann für wen sie mal wichtig sein könnten. Im Zweifel behalten? Ach was, auch da lässt sich noch reduzieren, und zwar so:

(Festhalten:) Nach Zufall

Wait, what? Nach Zufall. Jetzt kann man losen, Glücksrad drehen, blind mit dem Finger auf etwas zeigen oder einfach jede vierte verbliebene Anforderung löschen. Alles ist erlaubt. Aberwitzig? Mitnichten! Schauen wir nochmal auf die letzten Auswahlrunden. In denen haben wir nicht nur entschieden was nach unten priorisiert wird, wir haben damit gleichzeitig auch nach oben priorisiert, das eine gehört untrennbar zum anderen. Und was in keinem dieser Durchgänge für wichtig genug befunden wurde, das kann eigentlich nur verzichtbar sein. Und deshalb kann die Zufalls-Auswahl so lange weitergehen bis das Backlog auf eine vernünftige Größe eingedampft ist. Nur zu.

AberAber: Was, wenn irgendwas davon doch wichtig war?

Ja, was dann? Was wenn wir versehentlich etwas rausgeworfen haben was wir doch ganz dringend brauchen? Ganz einfach - sobald das auffällt kommt es als neue Anforderung wieder rein. Und wenn auf diesem Weg so lange Anforderungen wieder zurückkommen bis das Backlog erneut ausufert? Na dann geht das Ausmisten eben von vorne los.

Montag, 17. Oktober 2016

Bild: Wikimedia Commons / Jorge Royan - CC BY-SA 3.0

Ein mitgenommenes Thema vom ersten Lean Coffee für Product Owner und Produktmanager, der letzten Freitag stattgefunden hat: wie kann man es schaffen, dass ein Backlog einen überschaubaren Umfang behält und nicht ausufert? Die einfache Antwort - regelmässig ausmisten. Von Zeit zu Zeit ist es sinnvoll sich in grossem Ausmass von bisher gesammelten Anforderungen zu trennen, selbst, bzw. gerade von solchen die noch nicht umgesetzt wurden. Und dafür gibt es auch Gründe:

Zu große Backlogs sind zu unübersichtlich

Zugegeben, eine Binsenweisheit, aber eine mit Folgen. Bei einer drei- oder vierstelligen Anzahl von Einträgen ist es nicht mehr möglich alle Inhalte im Kopf zu behalten, Duplikate, Redundanzen oder Überschneidungen fallen dann nicht mehr auf. Man kann zwar versuchen durch Kategorien, Schlagworte oder Verlinkungen die Übersicht zu behalten, allerdings ist das mit zusätzlicher Arbeit verbunden, die auch erstmal erledigt werden muss. Das bringt uns zum nächsten Punkt:

Zu große Backlogs erfordern einen unverhältnismässigen Pflegeaufwand

Ich habe Menschen gesehen, die in Vollzeit nichts anderes gemacht haben als alte User Stories und Bugs zu aktualisieren. Immer wieder überprüften sie ob das was sich in ihnen befand nicht bereits durch andere Anforderungen umgesetzt wurde, noch gewollt war oder seine Priorität geändert hatte. Nur in den seltensten Fällen führte das dazu, dass irgendetwas aus dem Backlog herausgenommen werden konnte, stattdessen kam es immer und immer wieder zurück (es war nicht ohne Grund so niedrig priorisiert). Eine unglaubliche Verschwendung von Zeit und Geld.

Zu große Backlogs veralten (auch wenn sie gepflegt werden)

Egal wieviel Mühe man sich gibt: zu große Backlogs werden immer Anforderungen enthalten die obsolet oder bereits umgesetzt sind. Alleine die Länge der Aktualisierungszyklen sorgt dafür, denn die können sehr schnell Wochen oder sogar Monate in Anspruch nehmen. Selbst wenn sie gerade erst durchlaufen wurden ist das aber keine Garantie dafür, dass alles aktuell ist. Grund dafür sind die oben erwähnte Unübersichtlichkeit und eine "im Zweifel behalten"-Einstellung die immer wieder anzutreffen ist.

Zu große Backlogs führen zu unrealistischen Erwartungshaltungen und Enttäuschungen

Für viele Stakeholder ist die Angelegenheit klar: ist meine Anforderung noch im Backlog? Klasse, dann ist es ja nur eine Frage der Zeit bis sie umgesetzt wird. Dass unwichtige Dinge immer wieder nach unten priorisiert und von neuen Anforderungen "überholt" werden wird dabei nicht bedacht. Am Ende führt das zu falschen Erwarungen, enttäuschten Hoffnungen und Frustrationen. Die entladen sich dann irgendwann. Apropos:

Zu große Backlogs führen zu Konflikten

"Meine User Story ist jetzt zum fünften mal nach hinten geschoben worden. Jetzt bin ich auch mal dran, wenn nicht eskaliere ich das!" Aussagen wie diese sind die fast schon zwangsläufige Folge zu großer Backlogs. Nicht nur weil ein Stakeholder das Gefühl hat, dass ihm falsche Hoffnungen gemacht wurden, sondern auch aus handfesten Gründen: es ist in vielen Unternehmen "best" practice, dass Boni und Jahresziele an die Umsetzung von Anforderungen geknüpft werden, und wenn die nicht erreicht werden stehen unangenehme Jahresgespräche bevor. In solchen Situationen ist es klar, dass die Betroffenen schnell in Krawallstimmung sind.

Also her mit der Heckenschere

Genug der guten Gründe und ans Werk. Her mit dem Backlog und raus mit allem was nicht wirklich nötig ist. Nur - wie? Wie wird entschieden was bleibt und was nicht? Nun, das wird ein Thema für einen eigenen Artikel.