KI & Verantwortlichkeiten [KI]

3 Übungsfragen mit Lösung und Erklärung.

☝️ SingleEin Scrum Team lässt Product-Backlog-Einträge durch ein Sprachmodell erzeugen und priorisieren. Wie verändert das die Verantwortlichkeiten?
Die Verantwortung geht anteilig auf das Werkzeug und dessen Anbieter über
Die Verantwortung entfällt, solange die Vorschläge im Team besprochen werden
Die Developers übernehmen die Verantwortung, weil sie das Werkzeug betreiben
Gar nicht: Der Product Owner bleibt rechenschaftspflichtig für Inhalt und Reihenfolge, unabhängig davon, welches Werkzeug den Entwurf erstellt hat
Dies ist die zentrale Aussage der AI-Essentials-Zertifizierungen: Werkzeuge verschieben keine Accountability. Ein Product Owner, der generierte Priorisierung ungeprüft übernimmt, hat seine Verantwortlichkeit nicht delegiert, sondern nicht wahrgenommen.
✌️ MultiWelche Aussagen über KI-Einsatz im Scrum Team treffen zu? (Mehrere richtig)
Der Scrum Guide beschreibt seit 2024 den Umgang mit KI-Assistenten
Generierte Inhalte gelten als geprüft, wenn das Modell hohe Zuverlässigkeit angibt
Die Entscheidung über den Einsatz im Sprint liegt bei den Developers als selbstverwaltendem Team, soweit organisationale Vorgaben dies zulassen
KI-Werkzeuge sind eine Praktik, keine Änderung des Rahmenwerks
Der Einsatz ändert nichts daran, dass das Increment die Definition of Done erfüllen muss
Der Scrum Guide äußert sich nicht zu KI; er ist bewusst unvollständig und überlässt Werkzeugentscheidungen den Anwendern. Selbsteingeschätzte Zuverlässigkeit eines Modells ist kein Prüfnachweis.
✍️ OffenIhre Organisation führt KI-Assistenten für alle Scrum Teams ein. Der Vorstand erwartet eine Produktivitätssteigerung von dreißig Prozent. Nehmen Sie als Scrum Master dazu Stellung.
Musterantwort: Zuerst würde ich die Zielgröße selbst hinterfragen. "Produktivität" ist in der Produktentwicklung keine brauchbare Größe, weil sie Ausbringung misst, nicht Wirkung: Dreißig Prozent mehr gelieferte Funktionen bedeuten nicht dreißig Prozent mehr Wert, wenn ein erheblicher Teil ohnehin kaum genutzt wird. Zudem wird eine vorgegebene Prozentzahl zur Zielvorgabe und lädt zur Optimierung der Zahl ein, etwa über größere Schätzungen oder kleinteiligere Einträge. Dann würde ich benennen, wo Beschleunigung realistisch entsteht und wo nicht. Assistenten wirken auf die Zeit, in der tatsächlich gearbeitet wird. In den meisten Organisationen liegt der größere Teil der Durchlaufzeit aber in Wartezeiten: auf Freigaben, auf Abhängigkeiten, auf Rückmeldungen von Stakeholdern. Diese Zeit verkürzt kein Werkzeug. Wer dort nichts ändert, wird den erwarteten Effekt nicht sehen, unabhängig davon, wie gut die Assistenten sind. Drittens würde ich auf die Risiken hinweisen, und zwar nicht als Bedenken, sondern als messbare Größen. Schneller erzeugter Code, den niemand vollständig versteht, erhöht Produktionsvorfälle und technische Schuld; die gewonnene Kapazität fließt dann in Nacharbeit. Deshalb würde ich Durchlaufzeit niemals allein betrachten, sondern gemeinsam mit Vorfallzahl, Nacharbeitsanteil und dem Anteil der Kapazität, der für Neues zur Verfügung steht. Als Vorgehen schlage ich vor: einen Zielzustand statt einer Prozentzahl, ein begrenztes Vorgehen mit wenigen Teams über einige Sprints, vorab festgelegte Kennzahlen über mehrere Wertbereiche und eine ausdrückliche Anpassung der Definition of Done um eine menschliche Prüfpflicht. Parallel sind Lizenzfragen, Datenverarbeitung und die Beteiligung des Betriebsrats zu klären. Schließlich: Die Entscheidung über Werkzeuge im Sprint gehört zur Selbstverwaltung der Developers. Eine verpflichtende Nutzungsvorgabe erzeugt Widerstand und verdeckt gerade die Erfahrungen, die man für die Bewertung bräuchte.
Bewertet werden: Kritik an Produktivität als Ausbringungsgröße und an der Prozentvorgabe als Zielvorgabe + Wartezeit als dominierender Anteil der Durchlaufzeit + Qualitätsrisiko mit Gegenkennzahlen + Zielzustand und begrenztes Vorgehen statt Vollrollout + Anpassung der Definition of Done + Selbstverwaltung bei Werkzeugentscheidungen.
← Alle ThemenIm Quiz üben