Browse Tag

User Story

atdd

Gastbeitrag: ATDD kurz erklärt – Die richtigen Dinge entwickeln

Gastbeitrag: Ralf Wirdemann www.b-simple.de

Akzeptanztest-getriebene Entwicklung (kurz ATDD, für Acceptance Test Driven Development) ist eine Entwicklungspraxis, in der die funktionalen Anforderungen einer User Story als konkrete und automatisierbare Beispiele vor der eigentlichen Entwicklung der Story selber geschrieben werden. ATDD fördert die Kommunikation zwischen Product Owner und Entwicklungsteam und hilft Software zu entwickeln, die der Kunde wirklich will. ATDD treibt die Entwicklung einer User Story entlang ihrer Akzeptanzkriterien. Akzeptanzkriterien beschreiben Geschäftsregeln, die erfüllt sein müssen, damit die Story als fertig gilt und vom Product Owner abgenommen wird. Betrachten wir als Beispiel eine User Story für die Durchführung einer Banküberweisung:

Als Kunde will ich einen Betrag von meinem Konto auf ein Zielkonto überweisen.

Weiterlesen

Paper vector designed by Freepik

Wer schreibt eigentlich die User Stories?

Der Einsatz von User Stories in der Agilen Softwareentwicklung wird immer populärer. Viele sehen das Verfassen von Benutzergeschichten als Aufgabe des Product Owners – aber wieso eigentlich?

Ich bin der Meinung, dass jeder User Stories erstellen kann. Mike Cohn plädiert sogar dafür, dass alle Projektzugehörigen mindestens eine User Story verfasst haben sollten. Ich verfolge diesen Ansatz auch in meinen Projekten und habe gute Erfahrungen damit machen können. Zwei Anwendungsfälle aus der Praxis möchte ich heute kurz vorstellen.

Im ersten Fall mussten wir bei Start eines Projektes zügig zu ersten User Stories gelangen. Da das Projekt sehr technisch ausgelegt war, waren die Entwickler aus dem Team prädestiniert für das Schreiben der initialen Stories. Also veranstaltete ich mit dem Team und Product Owner einen User Story Workshop. Dieser startete mit den Grundlagen. Daraufhin ging es schnell an das Eingemachte und wir definierten die User Rollen und bestimmten die Ziele.

Weiterlesen

Hat vector designed by Freepik

Gastbeitrag: Die magische Schätzmethode

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Neben dem von Sven kürzlich vorgestellten Team Estimation Game, möchte ich heute noch eine weitere Herangehensweise vorstellen, die mir zu Ohren gekommen ist und eine zügige initiale Schätzung des gesamten Product Backlogs möglich machen soll: Magic Estimation.

Gerade beim Start eines neuen Projektes ist es häufig wichtig, schnell zu einer Aussage über den Zeitaufwand für die zu entwickelnden Funktionalitäten zu kommen. Vor dem ersten Sprint sollten daher ausreichend Backlog Items für mindestens 1-3 Sprints im Backlog vorhanden und priorisiert sein, um diese vom Team schätzen zu lassen. Weiterlesen

Light vector designed by Freepik

Gastbeitrag: Team Estimation Game

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Planning Poker ist in Scrum-Projekten in der Regel die Schätzmethode der Wahl. Es wurde 2002 von James Grenning erstmalig beschrieben und später durch Mike Cohn’s Buch Agile Estimating and Planning sehr populär. Die Regeln sind sehr einfach und das Schätzen kann nach wenigen einführenden Worten starten. Die größte Schwierigkeit bei der Einführung liegt meines Erachtens darin, dem Team den Sinn einer Schätzung von relativer Komplexität anstelle von Aufwand in Arbeitsstunden zu vermitteln.

Wenn diese erste Hürde genommen ist, steht man vor der nächsten Herausforderung: Gerade technisch sehr starke Teams neigen dazu, beim Schätzen bereits Lösungsansätze zu diskutieren. Als Argument dient oft „Für eine gute Schätzung müssen wir doch wissen, wie wir die Story umsetzen wollen“. Wenn man diese Diskussionen als Scrum Master nicht in den Griff bekommt, dauert die initiale Schätzung des Product Backlog viel länger als geplant (falls man überhaupt durchkommt und die weitere Schätzung nicht in die Estimation Meetings während der Sprints verschiebt).

Auf dem Scrum Gathering 2009 habe ich nun eine Methode kennengelernt, die sehr vielversprechend klingt und schnell gute Ergebnisse liefert: Das Team Estimation Game nach Steve Bockman. Die Regeln für das Spiel sind simpel:

Weiterlesen