,,Wer zu schnell geht, kommt oft nicht mit‘‘ – Anke Maggauer-Kirsche

Wir empfehlen, dass Teams ihre Velocity messen, um in zukünftigen Sprints besser abschätzen zu können, wieviel Komplexität sie in einem Sprint schaffen können.
Velocity beschreibt die Menge der erledigten Arbeit, die ein Team in einem Sprint geschafft hat (kann z.B. mit Story Points gemessen werden). Hier werden nur die Product Backlog Einträge herangezogen, die gemäß der „Definition of Done“ geschlossen wurden.
Auf keinen Fall darf Velocity zur Bewertung oder zum Vergleich von Teams herangezogen werden.
Schwankungen sind hierbei völlig normal. Nach einer bestimmten Zeit sollte sich ein gewisses Gefühl im Team entwickeln.

„Hör nicht auf, wenn es wehtut. Hör auf, wenn du fertig bist.” – Autor unbekannt

Wir nutzen eine „Definition of Ready”, um sicherzustellen, dass auch in den Product Backlog Einträgen alle Aspekte beachtet wurden, die zur Umsetzung notwendig sind. Vergleichbar mit einer „Definition of Done” werden Kriterien festgelegt, die erfüllt sein müssen, bevor das Product Backlog Eintrag in den Sprint Backlog übernommen wird. Ein paar Beispiele, die enthalten sein können:

• Geschätzt
• Klein genug, um in einem Sprint erledigt zu werden
• Möglichst keine Abhängigkeiten zu anderen Backlog-Einträgen (technisch wie fachlich)
• Von allen Teammitgliedern verstanden
• Sicherheitsrelevante Aspekte beachtet

„You’ll never walk alone.” – Richard Rodgers

Wir empfehlen beim Daily Scrum die Methode „Walk the Board“, wenn mehr als eine Story gleichzeitig aktiv bearbeitet wird. Jeder Sprint Backlog Eintrag wird durchgegangen und der aktuelle Stand sowie eventuell aufgetretene Impediments besprochen.
Es ist sinnvoll, sich auf eine festgelegte Reihenfolge zu einigen. Zum Beispiel nach Priorisierung im Sprint Backlog oder am weitesten fortgeschritten in der Umsetzung (von rechts nach links). Dadurch wird ein häufiger Kontextwechsel vermieden.

,,Erfolg ist eine Treppe, keine Tür‘‘ – Dottie Walters

Wir empfehlen, den Fortschritt des Teams während eines Sprints mit einem Burndown Chart zu visualisieren. Dabei wird jeden Tag die geleistete Arbeit in Relation mit dem Zeitverlauf des Sprints gesetzt, beginnend mit der voraussichtlichen Gesamtarbeitsmenge. Dies bietet einen schnellen Überblick auf die noch zu leistende Arbeit und hilft zu erkennen, ob Impediments das Team blockieren und wie gut die Arbeitspakete aufgeteilt sind.
Der Graph wird jeden Tag aktualisiert und ähnelt im Idealfall einer Rutsche oder einer Treppe (bei Jira).

„Das Ganze ist mehr als die Summe seiner Teile.“  – Aristoteles.

Für uns ist Mob Programming zu einem wichtigen Bestandteil des Entwickleralltags geworden. Wir finden es klasse, wenn mehrere Entwickler gemeinsam an einem Problem arbeiten können.
Nicht nur die Qualität des Codes wird (bereits während seiner Erstellung) gesichert, auch Wissensinseln innerhalb des Teams werden vermieden.

„Es hört doch jeder nur, was er versteht.“ – J.W. Goethe

Wir nutzen Behaviour Driven Development in Verbindung mit einer „ubiquitous language“, also einer allgegenwärtigen, für alle verständlichen und auf der Fachdomäne basierenden Sprache, um Verständnisprobleme zwischen Fachexperten, Developern und anderen Stakeholdern zu minimieren und ein gemeinsames Verständnis von der Anwendung zu entwickeln.
Da die Tests während oder besser noch vor der Entwicklung des Codes erstellt werden und das Verhalten der Anwendung in einer semi-formalen Syntax (z.B. gherkin) beschreiben, ist allen Beteiligten von Anfang an klar, wie die Anwendung nach der Implementierung eines neuen Features funktionieren soll.