Dienstag, 30. Mai 2017

Kommentierte Links (XXV)

Grafik: Pixabay / Geralt - Lizenz
  • Mike Cohn: The Career Path of a Scrum Master

    Die Kehrseite flacher Hierarchien: die klassischen Karrierewege existieren nicht mehr. Für viele Scrum Master (und solche die es werden wollen, sollen oder müssen) stellt sich daher die Frage wie die eigene Laufbahn zukünftig aussehen soll. Mike Cohn hat da einige gute Ideen, die allerdings für viele deutsche Unternehmen gewöhnungsbedürftig sein dürften. Vor allem die Frage wie sich das mit den üblichen Gehaltsstufen vereinbaren lässt wäre ein Thema für sich.

  • Robert Galen: Agile Coaching – An Awful Truth

  • Ich gestehe - seit langem hat mich kein Artikel mehr so bewegt wie dieser. Das mag an meiner beruflichen Situation liegen: mehr als einmal habe ich mich bei verschiedenen Kunden gefragt ob ich als Agile Coach überhaupt noch irgendetwas bewirken kann. In den meisten Fällen habe ich das mit Ja beantworten können, was sich rückwirkend auch als richtig erwiesen hat. Auf der anderen Seite habe ich definitiv zu selten zu einem Kunden gesagt, dass er sich nicht helfen lassen will und ich deshalb gehe. Ein To Do für die Zukunft.

  • Klaus Leopold: Ampel, reloaded [Edit: Link ist mittlerweile tot]

    Bei Ampeln musste ich sofort an die Wassermelonen-Projekte denken: Aussen Grün, innen Rot. Was Klaus Leopold als Gegenmassnahme vorschlägt ist erkennbar vom Test Driven Development inspiriert. Zuerst den Test (bzw. dessen Visualisierung, die Ampel) erstellen und dann daran arbeiten, dass aus Rot Grün wird. Richtig gemacht ist es sogar Lean Management - nur das Nötigste tun um die Ampel Grün zu bekommen und alles andere weglassen.

  • John Cutler: 40 Ways to Invest in More Resilient Teams

    Was wäre die Welt ohne Listicles? Ob dieses hier der goldene Schlüssel zur Lösung aller Probleme ist sei erstmal dahingestellt, auf jeden Fall bietet es eine Übersicht über zahlreiche Good Practices an. Viele davon habe ich in verschiedenen Teams bereits ausprobiert und für gut befunden, und auch das vorangestellte Modell eines "Overtraining Syndrome" kann ich nur zur Reflektion des eigenen Tuns empfehlen.

  • Wolf Steinbrecher: Agile Arbeitsorganisation in der Praxis - die „Arenen“ Ängelholms

    Ein weiteres Beispiel für agile Vorgehensweisen ausserhalb der IT. Ich gestehe, dass ich beim Lesen mehr Fragen als Erkenntnisse hatte, trotzdem sehe ich in diesem Beitrag einen wertvollen Impuls. Wie, wenn nicht durch Ausprobieren, würden sich neue Wege finden lassen? So gesehen ist Ängelholm, die "erste agile Kommunalverwaltung Europas", ein hochinteressantes Fallbeispiel.

Donnerstag, 25. Mai 2017

Continuous Documentation

Bild: Flickr / Denise Chan - CC BY-SA 2.0
Die üblichen Fehlwahrnehmungen agiler Softwareentwicklung sind vermutlich nie wieder so prägnant zusammengefasst worden wie vor zehn Jahren in einem einzigen Dilbert-Comic: "We're going to try something called agile programming. It means no more planning and no more documentation. Just start writing code and complaining." Legendär. Warum das Klischee der fehlenden Planung ein falsches ist steht bereits an anderer Stelle aufgeschrieben, jetzt zum zweiten, der angeblich fehlenden Dokumentation.

Eines vorweg: nicht jede Dokumentation ist sinnvoll. Viel zu häufig wird nur aus Prinzip dokumentiert, "weil es so vorgeschrieben ist". Es gibt Datengräber in denen in absurder Detailtiefe sinnloseste Informationen angehäuft wurden, wie etwa sämtliche Business Use Cases und Backend-Workflows von Komponenten die bereits vor Jahren ausgebaut wurden. Es gibt aber auch Dokumentationen die Sinn machen, etwa um gesetzliche Regulierungen zu erfüllen oder um komplexe Funktionen zu erklären. Wie geht man damit um?

Zunächst: anders als in den meisten klassischen Vorgehen. Einen Schockmoment erleben zum Beispiel viele Business Analysten wenn sie erfahren müssen, dass die Anforderungen nicht auch als Dokumentation benutzbar sind. Da jede spätere Anforderung die Ergebnisse jeder früheren überschreiben kann sind sie schon nach kurzem veraltet und unbrauchbar. Auch das Verfassen ganz am Ende ist nicht zu empfehlen, wenn man nicht gerade ein Faible für die Quälerei eines Reverse Engineering hat. Es muss früher und entwicklungsnäher stattfinden wenn es beherrschbar sein soll.

Best practice ist das Erstellen von Dokumentationen als Teil der Anforderungs-Umsetzung. Genau wie zu jeder neuen Funktion das Schreiben eines (automatisierten) Tests gehört kann auch das Schreiben von Anleitungen, Erläuterungen oder sonstigen Informationen dazugehören. Je nach Arbeitsweise lässt sich das sogar in den Akzeptanzkriterien, der Definition of Done o.ä. verankern. Ja, das bedeutet, dass all das permant angepasst werden muss. Continuous Documentation könnte man dazu sagen. Und ja, das ist viel Arbeit. Noch viel mehr Arbeit wäre es allerdings, erst gegen Ende damit zu beginnen. Wie gesagt, Reverse Engineering ist nichts Angenehmes.

Bleibt nur noch eine Frage: wer soll diese Arbeit machen? Die Antwort ist einfach - das Entwicklungsteam. Und bevor jetzt nach Luft geschnappt wird ("Waaaas? Die Entwickler sollen auch Anleitungen schreiben?") gibt es einen kurzen Verweis auf den Scrum Guide, dessen Inhalt sich an dieser Stelle auch auf andere agile Methoden übertragen lässt: "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment." Wenn zum Produkt eine Dokumentation gehört, dann gehört in das Team jemand der sie schreiben kann.

Montag, 22. Mai 2017

Palliativ-Therapie

Bild: Wikimedia Commons / Wm. Notman & Son - Public Domain
In der Medizin gibt es den Behandlungstyp der Palliativ-Therapie. Diese wird dann angewandt wenn eine Erkrankung so schwer ist, dass die Hoffnung auf Besserung bereits aufgegeben wurde. Im Mittelpunkt steht folgerichtig nicht mehr das Wiederherstellen der Gesundheit sondern das Lindern der Schmerzen und sonstigen Symptome. Nur das ist der Grund dafür, dass die Therapie weitergeht, um eine mögliche Heilung bemüht sich keiner mehr.

In Unternehmen deren agile Transition sich im Zustand des Scheiterns befindet gibt es ein ähnliches Phänomen. Allen Beteiligten ist klar, dass die Anhänger des "alten Weges" die Oberhand behalten haben. Es gibt wieder, bzw. immer noch Top-Down-Management, Herrschaftswissen und eine "mittelfristige Planung", die bereits jetzt festlegt welche Ergebnisse das übernächste Jahr bringen wird. Es ist wieder wie früher. Aber es gibt auch etwas Neues - es gibt "agile" Teams, Scrum Master und Agile Coaches, deren Job nichts anderes als eben Palliativ-Therapie ist.

Vereinfacht gesagt kann man sich deren Job als Regisseur einer Theateraufführung vorstellen, durch die das simuliert wird was ein agiles Unternehmen eigentlich haben sollte. Was auf den ersten Blick aussieht wie Product Ownership, Selbstorganisation und Selbstbestimmung hat in Wirklichkeit nichts damit zu tun. Detailanforderungen, technische Lösungswege und Deadlines sind von oben vorgegeben, die Teams dürfen nur noch entscheiden wie sie das im Tagesgeschäft umsetzen wollen (und besonders perfide: wie sie aus ihrem Arbeitsfortschritt Messzahlen für das Management ableiten wollen).

All das kann man natürlich in Form von Sprints durchführen, man kann Standups, Plannings, Reviews und Retrospektiven durchführen, kann die Arbeit mit Zetteln auf physischen Boards in digitalen Ticket-Tools abbilden und vieles dergleichen mehr. Theater. Dabei ist es nicht so, dass nicht allen bewusst wäre, dass das lediglich eine Farce ist. Jeder weiss es, viele sprechen es sogar aus. Aber, mit den Worten eines von derartigen Zuständen betroffenen Teams: "Wenn wir dem Ganzen einen irgendwie nach agil aussehenden Anstrich geben tut es weniger weh."

Noch einmal zurück zur Medizin. Palliativ-Therapie wird vor allem da angewandt wo das Versterben des Patienten nur noch eine Frage der Zeit ist. Wer sie in seinem Unternehmen bemerkt tut gut daran sich einen neuen Job zu suchen.

Donnerstag, 18. Mai 2017

Signal vs Noise

Grafik: Flickr/_DJ_ - CC BY-SA 2.0
"What did I do yesterday?", "What will I do today?", "Do I see any impediment?" Zahllose Scrum Teams auf der ganzen Welt stellen sich jeden Tag diese Fragen in ihrem Daily Standup - und viele von ihnen beantworten sie falsch. Vermutlich ist das nicht zielführende Beantworten sogar der häufigste Fehler der bei Scrum-Implementierungen gemacht wird, und dazu einer der weitreichende Folgen hat. Er kann die Akzeptanz des Meetings und sogar der gesamten Methode schwer in Mitleidenschaft ziehen.

Wie sähe so ein entgleistes Daily Standup aus? Zum Beispiel so:
  • Entwickler I: "Gestern habe ich mit der GUI angefangen, aber dann kam der Linienmanager mit einem Meeting für die Ressourcenplanung des neuen Projekts für nächstes Jahr, nachher gehe ich in das Folgemeeting dazu, dann mache ich mit der GUI weiter."
  • Entwickler II: "Ich musste gestern den kritischen Bug fixen der aufgetreten ist. Danach hatte ich die Schulung zum Nothelfer beim Betriebsarzt, da haben wir geübt wie man den Defibrilator bedient. Ach ja, und ich ziehe nachher den Unit Test nach."
  • Entwickler III: "Ich bin gestern zu nichts gekommen, da ich Ausbilder Schmidt bei den Werkstudenten vertreten musste. Der fällt wegen Beinbruch für unbestimmte Zeit aus. Das geht nachher noch weiter, danach schaue ich was liegengeblieben ist."
  • Entwickler IV: "Ich hatte ein Problem mit dem SAP-Stundenbuchungstool. Irgendwie war das kaputt, so dass ich fast den ganzen Tag beim IT-Support verbracht habe. Ich arbeite als nächstes an der Import-Funktion."
  • Entwickler V: "Ich war auch in dem Meeting für die Ressourcenplanung des neuen Projekts für nächstes Jahr, das war echt ätzend. Ich frage mich immer warum wir da jetzt schon hinmüssen. Na egal. Nachher mache ich das Code Review für den Bug."
Ob irgendjemand nach diesem Meeting sagen kann auf welchem Arbeitsstand das Team im Augenblick ist? Eher nicht. Die Entwickler haben relevante und irrelevante Informationen wild durcheinandergewürfelt, sind zum Teil ins Anekdotische abgeglichen und waren dafür an anderer Stelle nicht spezifisch genug. Alle Teilnehmer sind zu ständigen Context Switches gezwungen und müssen ausserdem versuchen die irrelevanten Informationen zu erkennen und auszufiltern, was schwieriger ist als man denken sollte.

In der Kommunikationswissenschaft spricht man in diesem Zusammenhang von der aus der aus der Nachrichtentechnik entlehnten Signal-to-noise ratio (dem Verhältnis zwischen Nutzsignal und Rauschen): wenn die irrelevanten Informationen (Noise, bzw. Rauschen) einen bestimmten Grad überschreiten beginnen sie die relevanten Informationen (das Nutzsignal) so zu überlagern, dass sich beide nur noch schwer auseinanderhalten lassen. Für den Empfänger kann dieser Effekt anstrengend und nervig sein, weshalb er mit hoher Wahrscheinlichkeit beginnen wird das Daily Standup negativ zu konnotieren. Im schlimmsten Fall kann diese Sicht sogar auf die gesamte Methode übertragen werden.

Der Witz an dieser Geschichte ist - den Schöpfern von Scrum war diese Problematik durchaus bewusst. Sie haben sogar in der Methode eine Vorkehrung eingebaut die ihr entgegenwirken soll, aber leider von vielen Teams ignoriert wird. Zur Erinnerung: "What did I do yesterday?", "What will I do today?", "Do I see any impediment?" ist nicht das was der Scrum Guide vorgibt. Er formuliert es stattdessen so: "What did I do yesterday that helped the Development Team meet the Sprint Goal?", "What will I do today to help the Development Team meet the Sprint Goal?", "Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Hinter dieser etwas umständlichen Formulierung verbirgt sich nichts anderes als der Hinweis darauf, sich im Daily Standup bitte auf die Punkte zu beschränken die für die Produktentwicklung sinnvoll sind. Mit anderen Worten - bitte nur Signal und kein Noise. Teams die sich daran halten können in ihren täglichen Meetings wesentlich effizienter kommunizieren und empfinden sie als deutlich weniger anstrengend. Es ist daher ein lohnenswertes Ziel darauf hinzuarbeiten.


Nachtrag 20.11.2020:
Mit dem 2020er-Update des Scrum Guide wurden die drei Fragen ersetzt durch die Aussage "The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal." Die Aussage dieses Textes bleibt dadurch unverändert.

Montag, 15. Mai 2017

Nicht Updatefähig

Grafik: WannaCry/Wikimedia Commons/Roke - CC BY-SA 3.0
Es war die große Geschichte des Wochenendes: eine Ransomware namens "WannaCry" übernahm hunderttausende mit Microsoft Windows betriebene Computer auf der ganzen Welt, verschlüsselte die dort gespeicherten Daten und verlangte für eine Entsperrung Geld. Betroffen waren vor allem große Behörden und Unternehmen, unter anderem Telefonica, Renault, Deutsche Bahn, der britische National Health Service, FedEx, Nissan, PetroChina sowie Ministerien in Russland und Rumänien. Warum diese Organisationen nicht besser geschützt waren lässt sich von Aussen natürlich nur vermuten, eine Annahme drängt sich aber geradezu auf - sie sind nicht in der Lage Sicherheitsupdates einzuspielen, zumindest nicht ohne monatelange Vorlaufzeit.

Zum Kontext: nach allem was man weiss beruht WannaCry auf einer Software des amerikanischen Geheimdienstes NSA, die im April von einer Hacker-Gruppe gestohlen und veröffentlicht wurde. Zu diesem Zeitpunkt war diese Sicherheitslücke bei Microsoft bereits bekannt - schon im März wurde ein Sicherheitsupdate veröffentlicht, durch das diese Lücke geschlossen wurde. Mit anderen Worten: bereits seit zwei Monaten hätte sich das Problem durch ein einfaches Windows-Update beheben lassen. In all den oben genannten Unternehmen und Behörden ist das allerdings unterblieben.


Um zu verstehen warum das so ist muss man wissen, dass viele Großorganisationen eingekaufte Standardsoftware stark modifizieren, damit sie mit den eigenen Systemen enger verzahnt werden kann. Single Sign ons, Zugriffe auf den Datei-Explorer, Beschränkungen des Web-Browsers oder Einbindung von Mail und Kalender in CRM-Prozesse erfordern zum Teil so tiefgreifende Eingriffe, dass wegen ihnen das Betriebssystem nicht mehr in der Lage ist Updates des Herstellers zu integrieren. Jedes mal wenn ein solches Update eintrifft muss es in langwieriger Anpassungsarbeit kompatibel gemacht werden. Und das ist noch der vergleichsweise harmlose Fall.

Oft sind die zuständigen IT-Abteilungen gar nicht mehr in der Lage derartige Anpassungen vorzunehmen, sei es aufgrund fehlender Ressourcen, sei es weil die Komplexität die Qualifikation der Mitarbeiter übersteigt, sei es aus anderen Gründen. Die Folge: in vielen Unternehmen und Behörden laufen die Computer mit stark veralteten und unzureichend gesicherten Software-Versionen, häufig noch immer mit Windows XP, in Extremfällen sogar mit Programmen aus den 90er Jahren. Vor diesem Hintergrund ist es nachvollziehbarer warum ein so veraltetes Programm wie WannaCry solchen Schaden anrichten konnte.

Letztendlich ist es eine neue, eher unbeachtete Dimension agiler Softwareentwicklung die hier zu Tage tritt: Agilität kann auch bedeuten, dass man in kürzester Zeit in der Lage sein muss kritische Hersteller-Updates einzuspielen. Ist das nicht möglich können unkalkulierbare Risiken die Folge sein.

Donnerstag, 11. Mai 2017

Fehlschläge kompostieren

Bild: Flickr/Philip Cohen - CC-BY-2.0

Vor gerade erst einem Tag habe ich einem von mir gecoachten Product Owner den Ratschlag gegeben, regelmässig einen "Hausputz" durchzuführen. Weg mit fehlgeschlagenen Produktideen und Prototypen, keine große nachträgliche Beschäftigung mit vom Kunden abgelehnten Features und von den Usern nicht genutzten Funktionen. Stattdessen Tabula Rasa und auf zur nächsten Hypothese, zum nächsten Experiment, zum nächsten Prototyp. Und dann habe ich dieses Video gesehen:

Design Thinking 3: Composting Prototypes from Harrison Metal on Vimeo.

Jetzt stehe ich da und denke mir, dass ich es eigentlich hätte besser wissen müssen. Tatsächlich predige ich ständig, dass Fehlschläge nichts Schlimmes sind, dass sie im Gegenteil sogar einen hohen Wert haben können - schließlich lernt man aus ihnen und kann es in Zukunft besser machen. Aber wenn das so ist, ist ein Hausputz dann wirklich das Richtige? Führt er nicht zu einem "Aus den Augen, aus dem Sinn?"

Den im Video gemachten Vergleich mit einem Komposthaufen finde ich wirklich gut. Ganz im Sinn von try again, fail again, fail better bilden alte, verworfene Prototypen mitsamt der Ergebnisse ihrer Praxistests den Nährboden für neue, bessere Ideen. Ob das jetzt in Form einer "Wall of Fuck Ups" geschieht, eines "Bitter-Sweet Memories"-Albums, einer "Lessons Learned Gallery" oder einer "Fool me once"-Ecke wäre je nach Einzelfall zu überlegen.

Mal sehen welchen Product Owner ich überreden kann so etwas einzurichten.

Montag, 8. Mai 2017

Build Trap

Ein leider sehr häufiges Phänomen: ein Unternehmen führt Scrum oder ähnliche Methoden ein, steigert seine Effizienz und Produktivität - und stellt in großem Maßstab unnötige Features und Produkte her. Melissa Perri hat für dieses Antipattern den Begriff der Build Trap geprägt und in den Mittelpunkt dieses Vortrages gestellt:

Escaping the Build Trap by Melissa Perri at Mind the Product San Francisco 2017 from Mind the Product on Vimeo.

[Edit 09.08,2018: Das ursprüngliche Video wurde gelöscht, daher ist jetzt eine andere Version dieses Vortrags hier eingebunden]

Freitag, 5. Mai 2017

Zero Bug-Policy

Bild: Wikimedia Commons/JohnSka - CC BY-SA 3.0
Auf einem Projekt das ich letztes Jahr auditieren durfte konnte es die Delivery Managerin (so hieß dort die Scrum Masterin) nicht lassen über ihren ehemaligen Agile Coach herzuziehen. Der habe zwar ein paar gute Ideen gehabt, aber auch ein paar unsinnige. Beispielsweise hätte er eine "Zero Bug-Policy" gefordert. Als ob das umsetzbar wäre. Erwartungsvoll schaute sie mich an, in der Hoffnung, dass ich in ihr Gelächter einstimmen würde, doch den Gefallen konnte ich ihr nicht tun. Der Mann hatte nämlich völlig recht, bugfreie Software ist möglich. Und nicht nur das - sie ist sogar die Voraussetzung für agile Softwareentwicklung.

"Kann gar nicht sein", erwiederte die Delivery Managerin, Scrum Guide und Agiles Manifest habe sie beides gelesen, da würde nichts von Bugs stehen. Nun ja, nicht wörtlich, aber indirekt durchaus. Werfen wir einen Blick darauf. Zunächst der Scrum Guide: im Abschnitt Increment sagt er über das Sprintergebnis It must be in useable condition [...] und ergänzt im Abschnitt Definition of Done Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. Weiter mit dem agilen Manifest: in seinen Prinzipien legt es fest: We follow these principles: [...] Deliver working software frequently [...] Working software is the primary measure of progress. Software soll also "Usable" und "Working" sein, und um das sicherzustellen darf sie keine bekannten Fehler mehr enthalten. Denn selbst wenn die Fehlfunktion scheinbar gering ist - niemand kann sagen ob nicht weitere Funktionen auf dieser einen fehlerhaften aufbauen. Wenn das so ist können selbst kleine Bugfixes wirken wie das Entfernen des untersten Steins in einem Jenga-Turm - alles bricht zusamen. Also: Agilität erfordert eine Zero Bug-Policy.

Erneut musste die Delivery Managerin widersprechen. Für das Fixen aller Bugs wäre gar keine Zeit da, es müssten doch Deadlines eingehalten werden. Auch den Hinweis, dass die aktuell laufende Bugfixing-Phase den Release um drei Monate nach hinten geschoben hätte wollte sie nicht gelten lassen. Einen besseren Weg gebe es nun mal nicht, oder könnte ich einen nennen? Zu ihrem Pech - ja, ich konnte. Er nennt sich Andon und ist eines ältesten agilen Vorgehensmuster überhaupt. Übernommen aus dem Maschinenbau bedeutet er (vereinfacht gesagt), dass beim Auftreten eines Fehlers die Produktion neuer Features sofort angehalten und erst dann fortgesetzt wird wenn der Fehler behoben ist. Dadurch befindet sich alles immer in einem auslieferungsfähigen Zustand (Zero Bugs) und monatelange Test-, Bugfixing- und Retest-Phasen entfallen. Selbst wenn die Fehlerbehebung die Feature-Produktion kurzfristig verzögert ist der Gesamtzeitraum bis zur Fertigstellung kürzer, man spart also Zeit und Geld.

Sichtbar verärgert legte die Delivery Managerin ihr letztes Argument auf den Tisch. Das wäre ja alles schön und gut, und irgendwo würde das sicher funktionieren, ganz sicher aber nicht in ihrer Firma. Da wäre die Situation eine besondere, weite Teile der Anwendung könnte man nämlich gar nicht testen. Nun ja, ein klarer Fall von Truthiness. Um es mit einem Sprichwort zu sagen: ich kann den Menschen nur die Tür aufhalten, durchgehen müssen sie selber. Manchmal tun sie es nicht. Für alle Anderen (zum Glück die Mehrheit) gilt: eine Zero Bug-Policy ist machbar, sie beschleunigt die Entwicklung, spart Kosten und sie macht agile Softwareentwicklung überhaupt erst möglich.

Dienstag, 2. Mai 2017

Null Punkte-Anforderungen


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.