Tag Archives: User Stories

Business Stories – wirksam wirklich wertvolle Produkte entwickeln

Business Stories

In agilen und nicht-agilen Entwicklungen liegt unser Fokus nach wie vor auf Ergebnissen. Wir betrachten Produktinkremente, bewerten die Geschwindigkeit/Velocity des Teams und zählen die Anzahl der Features. Dabei vergessen wir allzu oft, dass die Ergebnisse am Ende wertvoll sein müssen. Sie sollen Wirkung für alle erzielen, die irgendein Interesse am Produkt haben. Wie Business Stories dabei helfen, den Fokus auf die Wirkung zu richten, hat Stefan Rook in einer Session bei der jüngsten Tools4AgileTeams-Konferenz beleuchtet.

(Kein) Platz für Discovery in Scrum!?

Product Discovery Artikelbild

Das Abarbeiten der User-Stories aus dem Product-Backlog ist Alltag für agile Software-Teams. Und typische Richtungen, aus denen Stories eingebracht werden, sind die Stakeholder, die Kunden und die Produktstrategie. Doch wie lässt sich die Qualität der Stories im Backlog erhöhen? Wie kann eine Verknüpfung zwischen High-Level-Produktstrategie und den konkreten Stories des Product Owners entstehen? Darüber hat Juliana Brell in einem Vortrag auf der letzten Tools4AgileTeams-Konferenz nachgedacht und in diesem Zusammenhang den Product-Discovery-Ansatz vorgestellt. Hier ist das Video zur Session.

Warum wir Anforderungslisten in ein Backlog mit User Stories überführen

Immer wieder kommen Kunden mit sehr groben, technisch ausgerichteten Anforderungslisten in Software-Projekte. Der erste Projektschritt für //SEIBERT/MEDIA besteht in einem solchen Fall dann darin, die Anforderungsliste, die uns vom Kunden zur Realisierung übergeben wird, gemeinsam in ein Product Backlog umzuarbeiten, das den Kundennutzen der Anforderungen verdeutlicht. Das ist keine triviale Aufgabe und fordert dementsprechend etwas Zeit und einige Ressourcen ein. Doch warum soll der Kunde für diese Vorbereitungsarbeiten zahlen, die ja noch gar nichts mit der eigentlichen Umsetzung zu tun haben?

Scrum-Projekte: Beschätzungen auf Basis von Story Points

Unsere Entwicklungsteams schätzen den Aufwand für eine User Story in der Regel auf Basis von Story Points. Die meisten Kunden können mit dieser Messgröße erst mal nichts anfangen, weil sie Schätzungen in Zeit (Stunden) oder Geld (Euro) gewöhnt sind. Wir wollen Ihnen deshalb kurz erklären, warum wir Story Points in Aufwandsschätzungen verwenden und wie Schätzungen auf Basis von Story Points zu verstehen sind.

Kontinuierliches Schätzen in agilen Projekten

In einem Software-Projekt will der Kunde natürlich wissen, auf was für ein Budget er sich einstellen muss: Was kostet das denn? In komplexen IT-Vorhaben, in denen man sich naturgemäß immer mit Unsicherheiten konfrontiert sieht, ist die Beantwortung dieser Frage jedoch nicht trivial. Am Anfang eines agilen Scrum-Projekts steht daher eine grobe Schätzung aus dem Bauch heraus, die dann mit jeder Iteration genauer wird, sodass früh im Projekt immer mehr Klarheit über die zu erwartenden Gesamtkosten entsteht.

Das “blinde” Scrum-Team und das Produkt “Elefant”: Wie blindes Herumtasten im Scrum-Projekt vermeidbar ist

Software-Entwicklung ist ein komplexer Prozess, bei dem – gerade wenn man nach agilen Entwicklungsmethoden wie Scrum vorgeht – intensive Kommunikation und enge Abstimmungsrunden in kurzen, regelmäßigen Abständen unerlässlich sind. Doch der agile Entwicklungsprozess birgt die Gefahr, dass die Beteiligten aufgrund fehlender Abstimmung und einer fehlenden gemeinsamen Vision blind durch das Projekt tappen. Kommunikation und frühes Feedback können helfen, Situationen wie die zu vermeiden, in die die Handelnden im Gleichnis von den sechs blinden Männern und dem Elefanten geraten.

Scrum: Welche Eigenschaften sollte ein gutes Product Backlog haben?

In der agilen Software-Entwicklung ist das sog. Product Backlog ein wichtiges Artefakt. Es enthält alle Arbeiten, die für die Erstellung einer erfolgreichen Software-Anwendung erforderlich sind, also Funktionen, Fehler (Bugs) usw. Die Güte eines Product Backlogs hat erheblichen Einfluss darauf, wie gut das Entwicklungsteam es abarbeiten kann. Je besser der Kunde und das Team ein solches Backlog also aufbereiten und aktuell halten, desto produktiver und schneller erfolgt die Umsetzung.

Der Beginn eines Happy Ends: Initialer Anforderungs-Workshop für erfolgreiche Projekte

Bevor Auftraggeber und Dienstleister in die Realisierung eines Software-Entwicklungsprojekts einsteigen, ist es wichtig, dass sich beide Parteien darüber im Klaren sind, ob sie tatsächlich das gleiche gemeinsame Ziel vor Augen haben. Ein Anforderungs-Workshops bietet die Möglichkeit, das Ziel der Reise in Form einer Produktvision sowie die einzelnen notwendigen Schritte (User-Stories), die in der Gesamtheit den Product Backlog bilden, zu bestimmen. Wie ein solcher Anforderungs-Workshop ablaufen kann, soll in diesem Artikel umrissen werden.

User Stories: Anforderungen aus Nutzersicht dokumentieren

Internet-Anwendungen werden für den Nutzer entwickelt. Punkt. Doch warum werden die Anforderungen an Web-Applikationen so häufig aus einer eher technischen Perspektive beschrieben? Tatsächlich gibt es nämlich ausgereifte Möglichkeiten, Anforderungen aus Sicht der Anwender zu beschreiben. Bei der agilen Software-Entwicklung nach dem Scrum-Modell setzt //SEIBERT/MEDIA auf sog. User Stories.