Wie viel Zeit sollten Product Owner eigentlich in das Schreiben von User Stories investieren? Darüber sprechen Dominique Winter und Tim Klein in dieser Podcastfolge. Wenn der Kalender voll ist und die To-do-Liste überquillt, wirkt das Story-Schreiben schnell wie eine lästige Pflicht. Viele betrachten es als reine Schreibarbeit. In Wahrheit ist es jedoch vor allem Denk- und Teamarbeit.

Eine gute User Story entsteht nicht allein am Schreibtisch, sondern im Gespräch. Sie ist das sichtbare Ergebnis gemeinsamer Klärung und ein Zeichen dafür, dass ein Team ein gemeinsames Verständnis erreicht hat. Das Schreiben von User Stories dient daher weniger der Dokumentation als der Verständigung. Eine Story ist kein statisches Artefakt, sondern ein Kommunikationswerkzeug, das an ein Gespräch erinnert, in dem klar wird, welches Nutzerproblem gelöst werden soll.

Das Ziel im Blick behalten

Manche Teams versuchen, Sicherheit durch besonders ausführliche Formulierungen zu schaffen und verlieren dabei leicht das eigentliche Ziel aus den Augen. Gute User Stories entstehen, wenn Teams gemeinsam begreifen, worum es geht – nicht, wenn jedes Detail schriftlich fixiert wird. Sie sind eine Einladung zum Dialog, sollen Empathie für Nutzerinnen und Nutzer wecken sowie den Blick auf deren Bedürfnisse richten. In dieser Haltung wird das Schreiben von Stories zu einem Werkzeug, das Orientierung schafft. Wenn Teams verstehen, warum etwas wichtig ist, finden sie auch den passenden Weg dorthin. Manchmal genügt ein einziger Satz, um eine Idee zu verankern und das Gespräch darüber am Laufen zu halten.

Organisationen gehen sehr unterschiedlich mit User Stories um. In großen Unternehmen wird häufig zu viel dokumentiert – oft, weil es der gewohnte Weg ist. Start-ups hingegen schreiben meist zu wenig auf. Beides zeigt ein Ungleichgewicht zwischen Vertrauen und Kontrolle. Teams, die ihre Prozesse kennen und einander vertrauen, benötigen keine langen Texte. Sie verlassen sich auf Dialog und gemeinsame Verantwortung. Wie viel Zeit in die Story-Erstellung fließt, hängt daher stark von der Reife eines Teams ab. Eingespielte Teams mit tiefem Produktverständnis kommen mit wenigen Worten aus, während neue Teams mehr Austausch benötigen, um ein gemeinsames Verständnis aufzubauen. In jedem Fall sollte die Energie eher in Nachdenken und Reflexion fließen als in das Polieren von Formulierungen.

Zehn-Prozent-Regel und KI-Einsatz

Hilfreich ist die bekannte Zehn-Prozent-Regel: Rund zehn Prozent der Sprintzeit sollten in die Erstellung und das gemeinsame Refinement des Backlogs investiert werden. Diese Zeit schafft Klarheit über Ziele, Annahmen und Prioritäten. Wer hier spart, zahlt später mit Missverständnissen und Nacharbeit.

Auch Künstliche Intelligenz (KI) kann unterstützen – etwa durch Strukturvorschläge oder Formulierungsideen. Doch sie ersetzt kein gemeinsames Denken. Eine automatisch erzeugte Story ist noch keine Story, solange nicht darüber gesprochen wird. KI kann inspirieren, aber kein echtes Verständnis schaffen. Am Ende braucht es immer Menschen, die beurteilen können, ob das Ergebnis wirklich gut ist. Gute User Stories entstehen in Gesprächen, nicht in Tools. Sie schaffen ein gemeinsames Bild des Nutzerproblems und machen die Produktentwicklung wirkungsvoller. Teams, die sich Zeit für den Austausch nehmen, gewinnen Klarheit – und diese Klarheit ist die beste Grundlage für jedes gute Produkt.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Wie viel Zeit darf User-Story-Erstellung kosten – hilft uns KI dabei?„

(mai)

Der Debian-Entwickler Julian Andres Klode hat angekündigt, ab Mai 2026 harte Rust-Abhängigkeiten in den Paketmanager APT einzuführen. Künftig werden zentrale Teile von APT in der Programmiersprache Rust implementiert. Betroffen sind unter anderem der Code zum Parsen von .deb-, .ar- und .tar-Archiven sowie die HTTP-Signaturverifizierung.

APT (Advanced Package Tool) ist das zentrale Werkzeug zur Paketverwaltung in Debian und darauf basierenden Distributionen wie Ubuntu. Die geplante Umstellung auf Rust betrifft damit eine der grundlegendsten Systemkomponenten der Distribution. Klode begründet den Schritt mit den Vorteilen speichersicherer Programmiersprachen und besseren Möglichkeiten für Unit-Tests.

Die Rust-Integration umfasst zunächst den Rust-Compiler, die Standardbibliothek und das Sequoia-Ökosystem. Sequoia ist eine OpenPGP-Implementierung in Rust, die bereits in verschiedenen Projekten zum Einsatz kommt. Durch den Einsatz von Rust sollen typische Speicherfehler wie Buffer Overflows oder Use-after-Free vermieden werden, die in C und C++ häufige Sicherheitslücken eröffnen.

Die Ankündigung richtet sich explizit auch an Maintainer weniger verbreiteter Debian-Ports. Architekturen wie m68k, hppa (HP PA-RISC), sh4 (SuperH) und Alpha adressiert Klode in der Nachricht direkt. Diese Ports haben nun sechs Monate Zeit, eine funktionierende Rust-Toolchain bereitzustellen – andernfalls droht die Einstellung des Supports.

Modernisierung versus Retro-Hardware

Klode betont in seiner Nachricht, dass es für das Projekt wichtig sei, sich weiterzuentwickeln und auf moderne Technologien zu setzen. Man könne nicht zulassen, dass die Distribution durch den Versuch ausgebremst werde, moderne Software auf Retro-Computing-Geräte zu portieren. Diese Haltung dürfte in der Community durchaus kontrovers diskutiert werden, da Debian traditionell eine sehr breite Hardwareunterstützung anstrebt.

Die Entscheidung reiht sich in einen größeren Trend ein: Auch der Linux-Kernel hat mit der Integration von Rust begonnen, um sicherheitskritische Komponenten schrittweise in der speichersicheren Sprache zu implementieren. Rust hat sich in den vergangenen Jahren als bevorzugte Alternative zu C und C++ für systemnahe Programmierung etabliert, wenn es um Sicherheit und Zuverlässigkeit geht.

Für Nutzer von Debian auf gängigen Architekturen wie x86-64, ARM oder RISC-V dürfte die Umstellung transparent verlaufen, da Rust für diese Plattformen bereits vollständig unterstützt wird. Die Frist bis Mai 2026 gibt den Maintainern kleinerer Ports zumindest etwas Zeit, entweder eine Rust-Toolchain zu implementieren oder ihre Ports offiziell einzustellen.

Die vollständige Ankündigung findet sich in einer Nachricht an die Debian-Entwicklerlisten.

(fo)

Microsoft hat seine Entwicklungsumgebung Visual Studio 2022 mit dem Oktober-Update versehen. Es bietet nun eine größere Auswahl an Large Language Models (LLMs) im Chat und bringt GitHub Copilot Memories – ein Erinnerungsvermögen für den KI-Assistenten. Darüber hinaus hat Microsoft für C++-Entwicklerinnen und -Entwickler eine Anleitung veröffentlicht, wie sie ihre Projekte auf das nächste Release Visual Studio 2026 aktualisieren können.

KI-Updates für Visual Studio 2022

Unter der Bezeichnung Copilot Memories kann sich der KI-Assistent GitHub Copilot nun an Dinge „erinnern“: Wenn Entwickler beispielsweise das Verhalten des Copiloten korrigieren, einen Standard explizit ausdrücken oder ihn darum bitten, sich etwas zu merken, erhalten sie die Aufforderung, die entsprechende Präferenz zu speichern. Diese wird in einer von drei möglichen Dateien abgespeichert: .editorconfig für Coding-Standards, CONTRIBUTING.md für Best Practices, Richtlinien und Architekturstandards oder README.md für High-Level-Informationen über das Projekt. Diese gespeicherten Informationen gelten auch für den Rest des Teams, der am Projekt arbeitet.

Darüber hinaus können Developer im Oktober-2025-Update nun auch die Anthropic-Sprachmodelle Claude Sonnet 4.5 und Claude Haiku 4.5 verwenden. Claude Sonnet 4.5 hat soll insbesondere in der Softwareentwicklung vergleichsweise stabil und vielseitig sein, während Claude Haiku 4.5 sich durch eine erhöhte Leistung bei geringeren Kosten auszeichnet.

Neben diesen sind auch weitere neue KI-Features mit an Bord, die Microsoft auf seinem Entwicklerblog vorstellt.

C++-Projekte auf Visual Studio 2026 aktualisieren

Speziell für C++-Projekte hat Microsoft eine Anleitung verfasst, wie sie sich auf Visual Studio 2026 migrieren lassen. Derzeit ist das nächste Major Release nur innerhalb des Insider-Programms verwendbar, nähert sich jedoch der allgemeinen Verfügbarkeit.

Microsoft empfiehlt C++-Developern daher das Ausprobieren der neuen Version in Visual Studio 2026 Insiders, die sich parallel zu einer stabilen Visual-Studio-Version installieren lässt. Dann können C++-Developer zunächst bei ihrer bestehenden MSVC-Toolset-Version verbleiben und den neuen Setup-Assistenten verwenden, um fehlende Tools je nach Projekt zu installieren. Wenn sie dafür bereit sind, können sie schließlich ihre MSCV-Build-Tools auf Version 14.50 aktualisieren, die den MSVC-Compiler in Version 19.50 mitbringen.

(mai)