4.9 9 Votes
Artikel-Rating

Burndown Charts sind eine beliebte Methode der agilen Produktentwicklung. Für Scrum Teams existieren dabei zwei grundsätzliche Anwendungsfälle. Und zwar einerseits als Sprint Burndown Chart, das die Entwickler des Teams in ihrer Selbstorganisation unterstützt. Und andererseits als Release Burndown Chart, das den Product Owner dabei unterstützt, gegenüber seinen Stakeholdern auskunftsfähig zu sein.

In dieser ultimativen Anleitung stelle ich Dir beide Anwendungsfälle detailliert vor und zeige Dir, wie Du Burndown Charts in Deinem Scrum Team noch besser einsetzen kannst.

Inhaltsverzeichnis

Aufbau eines Burndown Charts

Der Aufbau eines Burndown Charts ist grundsätzlich sehr simpel. Es besteht aus einem Koordinatensystem, das den verbleibenden Aufwand und den zeitliche Verlauf visualisiert.

  • Die X-Achse des Burndown Charts zeigt den zeitlichen Verlauf.

  • Die Y-Achse bildet den verbleibenden Aufwand ab.

Gundgerüst eines Burndown Charts

Wie genau der verbleibende Aufwand und Zeit erfasst werden, ist für die Funktion des Burndown Charts erst einmal zweitrangig. Je nachdem, ob es sich um ein Sprint oder ein Release Burndown Chart handelt, werden diese beiden Metriken unterschiedlich genutzt.

Idealtrend & verbleibender Aufwand

Wichtig ist vielmehr, dass der verbleibende Aufwand zu den definierten Zeitpunkten aktualisiert wird. Viele Teams und Product Owner nutzen zur besseren Visualisierung eine Ideallinie.

  • Der Idealtrend ist eine gerade Linie, die vom ursprünglichen Aufwand bis zur Null-Linie am letzten Zeitpunkt des Burndown Charts verläuft.

Die fortlaufende Visualisierung des aktuellen Aufwands im Vergleich mit der Ideallinie hilft Euch dabei, möglichst gut einschätzen zu können, ob zum definierten Ende auch wirklich alles fertig ist.

Idealtrend & verbleibender Aufwand

Burndown Chart mit Trendlinie

Falls Ihr Euch noch mehr Transparenz wünscht, könnt Ihr Euer Burndown Chart noch um eine Trendlinie ergänzen.

  • Die Trendlinie ist eine gerade Linie, deren Startpunkt beim ursprünglichen Aufwand beginnt und dann durch den letzten aktuellen Stand verläuft.

Die Trendlinie visualisiert den tatsächlichen durchschnittlichen Aufwand, der bisher abgearbeitet wurde. Durch sie kannst Du leichter einschätzen, wo Ihr (wahrscheinlich) am Ende rauskommt. Liegt die Trendlinie über der Ideallinie, wirst Du Dein Ziel höchstwahrscheinlich verfehlen. Liegt sie darunter, wirst Du eventuell früher fertig sein.

Hier siehst Du ein Sprint Burndown Chart mit einer Trendlinie, die auf dem Stand des fünften Sprint-Tages basiert. Wenn dieses Scrum Team nichts unternimmt, sollte es davon ausgehen, sein Sprintziel nicht zu erreichen, da die Trendlinie deutlich über der Ideallinie liegt.

Burndown Chart mit Trendlinie

Das Sprint Burndown Chart

Der Hauptgrund, ein Sprint Burndown Chart zu nutzen, ist das Selbstmanagement der Entwickler. Denn der optimale Fall sieht ja so aus, dass sich Entwickler, Scrum Master und Product Owner im Sprint Planning auf ein gemeinsames Sprintziel geeinigt und einen Plan entwickelt haben, dieses Ziel zu erreichen. Und dieser Plan ist nichts anderes als das Sprint Backlog:

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Die Punkte real-time picture of the work und inspect their progress sind hier besonders wichtig.

Mehr Transparenz durch ein Sprint Burndown Chart

Das Sprint Backlog dient dazu, Transparenz darüber zu erzeugen, wie es um die Erreichung des Sprintziels steht. Gleichzeitig sind die Entwickler des Scrum Teams dafür verantwortlich, am Ende des Sprints auch ein nutzbares Increment zu liefern. Deshalb müssen sie natürlich möglichst gut einschätzen können, wie es aktuell um ihren ursprünglichen Plan bestellt ist.

Eine einfache Liste oder ein Kanban Board sind dabei oft nur bedingt hilfreich. Deshalb hat sich bei den meisten Scrum Teams die Nutzung eines Sprint Burndown Charts etabliert. (Auch wenn es kein fester Bestandteil des Scrum Frameworks ist.) Aber da es ein visuelles Tool ist, unterstützt es die Entwickler Deines Teams dabei, einschätzen zu können, ob das Sprintziel (noch) erreicht werden kann.

Wenn Du so möchtest, ist das Sprint Burndown Chart eine zusätzliche (und sehr hilfreiche) Visualisierung Eures Sprint Backlogs.

Inspect & Adapt

Wenn die Entwickler mit Hilfe des Sprint Burndown Charts während ihres Daily Scrums erkennen, dass das Sprintziel in Gefahr ist, haben sie prinzipiell drei unterschiedliche Optionen.

  • Sie beschließen selbstorganisiert, ihren Plan entsprechend anzupassen, sodass sie das Sprintziel weiterhin erreichen können. (Diese Option wäre auch gleichzeitig der Optimal-Fall.)

  • Sie erkennen, dass sie sich im Sprint Planning verschätzt haben und die Umsetzung aufwändiger ist, als ursprünglich gedacht. Die Entwickler können dann den Dialog mit ihrem Product Owner suchen und gemeinsam entscheiden, ob und wie sie den Scope des Sprints verringern können. (Bestenfalls ohne das Sprintziel zu gefährden.)

  • Die Entwickler erkennen die Auswirkungen bestimmter Impediments, die sie (noch) nicht eigenständig lösen können. Sie können dann in den Dialog mit ihrem Scrum Master gehen. Dieser kann dann die Aufgabe übernehmen, das Hindernis aus dem Weg zu räumen oder Hilfestellung bei der eigenständigen Beseitigung des Hindernis geben.

Sprint Burndown Charts mit Zeitaufwänden

Viele Scrum Teams schätzen die notwendigen Stunden für die zu erledigenden Aufgaben (Tasks) des Sprints und visualisieren diese dann als zeitlichen Aufwand auf ihrem Sprint Burndown Chart. Dieses Vorgehen hat einige Vor- als auch Nachteile, auf die ich ein wenig genauer eingehen möchte.
0
Wie schätzt Ihr in Eurem Team Aufwände? Und wie sind Eure Erfahrungen damit?x

Zunächst einmal muss sich Dein Team gemeinsam darüber Gedanken machen, wie viele Stunden pro Sprinttag es für die tatsächliche Arbeit am Produkt aufwenden kann. Wenn Ihr beispielsweise zu dem Schluss kommt, insgesamt 5h pro Tag für die Arbeit am Sprint aufzuwenden und Dein Team besteht aus insgesamt 6 Entwicklern, kommt Ihr auf eine Kapazität von insgesamt 270h bei einem 14-tägigem Sprint. (5h × 9 Arbeitstage × 6 Entwickler)

Während des Scrum-Sprints werden dann die verbleibenden Stunden Eurer Aufgaben bzw. User Stories aktualisiert, sodass Ihr (im Vergleich mit der Ideallinie) erkennen könnt, wo Ihr aktuell steht.

Wichtig: Ihr müsst darauf achten, dass Ihr den verbleibenden Aufwand trackt. (Und nicht, wie viele Stunden Ihr abgearbeitet habt.)

  • Falls Ihr eine Aufgabe innerhalb von 1h erledigt, die Ihr im Sprint Planning jedoch mit 8h geschätzt habt, dann verringert Ihr den verbleibenden Aufwand um 8h (und nicht um 1h).

  • Umgekehrt müsst Ihr den verbleibenden Aufwand erhöhen, falls eine Aufgabe länger dauert. Habt Ihr 16h an einer Aufgabe gearbeitet, die ursprünglich mit 8h geschätzt war, und Ihr glaubt, dass es noch weitere 4h dauern wird, erhöht ihr den verbleibenden Aufwand um 4h.

Euer Sprint Burndown Chart könnte am 5. Sprinttag folgendermaßen aussehen:

Sprint Burndown Chart mit Zeitwand

Wenn Du mit Deinem Team ein Sprint Burndown Chart mit Zeitaufwänden nutzen möchtest, müsst Ihr allerdings für jede Aufgabe eine Stundenschätzung festhalten. Das kann durchaus hilfreich sein, weil Ihr so bereits im Sprint Planning erkennen könnt, ob Ihr Euch vielleicht zu viel vornehmt. (Oder ob Ihr noch “Luft nach oben” habt.)

Gleichzeitig erzeugt diese Art des Sprint Plannings natürlich auch viel Aufwand. So müsst Ihr beispielsweise bereits im Planning festhalten, ob 2 oder sogar 3 Entwickler gemeinsam an einer Aufgabe arbeiten wollen und das mit einer Erhöhung der dazugehörigen Stunden für diesen Tasks notieren. (Ein Task, an dem 3 Entwickler jeweils 5h arbeiten, hat daher 15h Aufwand.)

Vorteile eines Sprint Burndown Charts mit Zeitaufwänden

Einen Vorteil habe ich bereits oben genannt. Durch das Schätzen von Zeitaufwänden könnt Ihr in Eurem Team recht früh erkennen, ob Ihr Euch nicht doch eventuell zu viel (oder zu wenig) vornehmt. Es gibt aber noch weitere Vorteile dieser Art des Sprint Burndown Charts.

Die verbleibende Kapazität kann visualisiert werden

Wenn Ihr in Eurem Scrum Team die Kapazitäten beim Sprint Planning ermittelt und auch Urlaubstage etc. festhaltet, dann ergibt sich dadurch eine weitere Linie, die auf dem Sprint Burndown Chart angezeigt werden kann.

Hier siehst Du beispielsweise ein Team, bei dem am sechsten Sprinttag vier von fünf Entwicklern nicht am Sprint arbeiten können. Dadurch ergibt sich auf dem Burndown Chart ein sichtbarer Knick in der blauen Linie, welche die Kapazität dieses Scrum Teams visualisiert.

Diese Visualisierung kann für Teams, bei denen Entwickler aus diversen Gründen häufig abwesend sind, sehr viel hilfreicher sein als die Idealtrend-Linie.

Sprint Burndown mit Kapazitäts-Linie

Nutzung des On Product Index

Die Nutzung von Stunden beziehungsweise Zeit für ein Sprint Burndown Chart hat noch einen weiteren Vorteil. Und zwar lernt Dein Team nach und nach, wie viel Zeit es tatsächlich für die Arbeit am Produkt aufwenden kann. Es gibt sehr viele Teams, die anfänglich davon ausgehen, 6h pro Tag am Sprint arbeiten zu können. Durch eine Auswertung vergangener Sprints können sie aber klar erkennen, dass es tatsächlich nur 2,5h pro Tag sind.

Im Evidence-Based Management gibt es dazu eine Metrik, die sich On Product Index nennt. Sie stellt das Verhältnis von tatsächlicher Arbeitszeit am Produkt zu insgesamt verfügbarer Zeit dar.

Legst Du 7,5h pro Arbeitstag zugrunde, die Entwickler arbeiten aber nur 2,5h pro Tag wirklich am Produkt, beträgt der On Product Index 33 %.

  • Die gezielte Steigerung des On Product Index kann außerdem ein hervorragendes Key Result sein, wenn es Euer Objective ist, die Produktivität Eurer Teams zu steigern.

Nachteile eines Sprint Burndown Charts mit Zeitaufwänden

Neben diesen Vorteilen bringen Sprint Burndown Charts, die Aufwände in Form von Zeit visualisieren, auch einige Nachteile mit sich. Den erhöhten Aufwand im Sprint Planning habe ich bereits erwähnt. Es kann wirklich anstrengend sein, jede Aufgabe mit Stundenschätzungen zu versehen.

Kollaboratives Arbeiten wird untergraben

Wie schon erwähnt müssen Zeitaufwände von Aufgaben, an denen mehrere Entwickler arbeiten werden, (häufig) entsprechend multipliziert werden. Ein Refinement, das 2h dauert, an dem jedoch 5 Entwickler teilnehmen, schlägt direkt mit 10h zu Buche. Schnell wird dann die “Effizienzkeule” geschwungen und kollaboratives Arbeiten systematisch untergraben: “Müssen da wirklich immer alle Entwickler mit dabei sein?!”

Story Points werden mit Stunden verglichen

Wenn Du so möchtest, erzeugt die Schätzung von Tasks in Zeit eine Art “Umwandlung” von Story Points zu Stunden. Denn im Sprint Planning beginnt Dein Team ja beispielsweise damit, eine User Story mit 3 Story Points mit Tasks zu versehen und gleichzeitig Stunden für diese Tasks zu schätzen.

Einerseits kann das hilfreich sein, um Fehleinschätzungen aus dem Backlog Refinement sichtbar zu machen.

Stell Dir vor, in Eurem Sprint Backlog sind zwei User Stories mit 5 Story Points. Für die eine User Story schätzen die Entwickler 10h Zeitaufwand, für die Tasks der anderen User Story jedoch 25h. Die Frage wäre dann: Warum ist das so? Ist es, weil die zweite User Story vielleicht doch eher eine Größe von 8 Story Points hat? Oder liegt es daran, dass die erste User Story zwar zeitlich gesehen keinen großen Aufwand darstellt, aber Risiken existieren, die ihre Fertigstellung verzögern?

Andererseits liegt darin auch eine große Gefahr. Dein Team (und schlimmstenfalls die Stakeholder Deines Teams) beginnen damit, Story Points in Stunden umzurechnen (und umgekehrt). Story Points berücksichtigen jedoch auch Faktoren wie Komplexität, Risiken und Hindernisse. Deshalb lassen sich Stunden und Story Points nicht 1:1 vergleichen.

  • Eine mögliche Maßnahme wäre beispielsweise eine (tägliche) gemeinsame Fokuszeit zu bestimmten Uhrzeiten. Bestenfalls sogar ein ganzer Tag, an dem keine Meetings stattfinden (dürfen).

Sprint Burndown Chart mit Story Points

Die zweite Variante, die Ihr in Eurem Team nutzen könnt, ist ein Sprint Burndown Chart mit Story Points. Die Methode ist dabei ausgesprochen simpel:

Jedes Mal, wenn während des Sprints eine User Story geschlossen wird, senkt Ihr den verbleibenden Aufwand auf dem Burndown Chart um die entsprechenden Story Points dieser User Story.

Sprint Burndown Chart mit Story Points

Vorteile eines Sprint Burndown Charts mit Story Points

Diese Art des Sprint Burndown Charts hat drei große Vorteile, die es im Vergleich mit Stundenschätzungen unschlagbar machen.
0
Siehst Du das genauso? Oder nutzt Ihr in Eurem Team lieber Stunden bzw. Zeit?x

Geringerer Pflegeaufwand

Das Aufschreiben, Tracken und Verändern aufgewendeter Stunden für jeden Task eines Sprints kann eine ziemlich umfangreiche Angelegenheit werden. (Selbst mit digitalen Tools wie Jira oder Azure DevOps.)

Denn wer weiß schon immer so genau, wie lange er an einem konkreten Task gearbeitet hat? Haben zwei Entwickler gemeinsam an einer Aufgabe gearbeitet, muss die Stundenzahl entsprechend verdoppelt werden. (Obwohl das im Sprint Planning noch nicht klar war.) Gleichzeitig muss die Anzahl der noch verbleibenden Stunden angepasst werden, falls klar wird, dass eine Aufgabe doch länger dauert, als ursprünglich gedacht.

Bei einem Burndown Chart mit Story Points verringert Ihr einfach den aktuellen Stand an Story Points, sobald eine User Story umgesetzt wurde. Fertig!

Fokus auf Fortschritt statt Zeitaufwand

Ein weiterer großer Vorteil dieser Sprint Burndown Charts ist der Fokus auf Fortschritt. Denn wenn Dein Scrum Team für sein Sprint Burndown Chart Zeitaufwände und Kapazität nutzt, kann es durchaus sein, dass zwar die Stunden getrackt werden und das Burndown Chart “gut aussieht”, aber zum Ende des Sprints nicht eine einzige User Story fertig ist.

Wenn Ihr hingegen fertige User Stories trackt, könnt Ihr über das Sprint Burndown Chart sehen, wie viele User Stories bereits geschlossen wurden. (So wird zum Beispiel auch sehr gut sichtbar, wenn Dein Team alle User Stories immer erst zum Ende des Sprints abschließt und erst kurz vor Torschluss fertig wird.)

Kleinere User Stories

Ein Sprint Burndown Chart mit Story Points funktioniert natürlich nur dann wirklich gut, wenn das Sprint Backlog aus vielen möglichst kleinen User Stories besteht. (Also User Stories mit 1, 2 oder 3 Story Points.) Hat Dein Team lediglich eine User Story mit 20 SP im Sprint Backlog, sieht man im Sprint Burndown Chart während des Sprints natürlich gar nichts.

Die Nutzung von Story Points für Euer Sprint Burndown Chart hat daher auch einen “erzieherischen Nebeneffekt”. Denn sie zwingt Euch gewissermaßen dazu, User Stories, die (noch) zu groß sind, während Eures Refinements weiter zu verkleinern.

Das Release Burndown Chart

Burndown Charts lassen sich natürlich nicht nur für einen einzelnen Sprint nutzen, sondern auch bei der Entwicklung eines Produktes oder im Rahmen von Projekten. In diesem Fall spricht man von einem Release Burndown Chart. (Manchmal wird es auch Product Burndown Chart genannt.)

Das Release Burndown Chart stellt eine große Hilfe für Dich als Produkt Owner dar, wenn es um die Kommunikation mit Stakeholdern und Kunden geht.
0
Nutzt Du als Product Owner ein Release Burndown Chart? Wie sind Deine Erfahrungen damit?x
Im Grunde funktioniert es genauso wie das Sprint Burndown Chart (mit Story Points), das ich Dir bereits weiter oben vorgestellt habe. Lediglich den Zeitraum, der über die X-Achse abgebildet wird, veränderst Du dabei von Tage auf Sprints.

  • Die Voraussetzung für ein Release Burndown Chart ist natürlich ein vollständig geschätztes Product Backlog. Hierzu eignet sich die Methode Magic Estimation außerordentlich gut, da Schätzungen deutlich schneller durchgeführt werden können als mit Planning Poker.

Beispiel für ein Release Burndown Chart mit Idealtrend

Mit dem Release Burndown Chart Vorhersagen treffen

Beim Release Burndown Chart hast Du zwei grundsätzliche Optionen, um Vorhersagen über potenzielle Release Dates zu treffen. Entweder Du nutzt die durchschnittliche Velocity Deines Teams oder Du verwendest die sogenannte Velocity Range.

Diese hat den Vorteil, dass Du einen zeitlichen Korridor visualisieren kannst, der umso größer wird, je weiter ein Release Date in der Zukunft liegt.

Release Dates mit der Sprint Velocity ermitteln

Als Product Owner kannst Du die (historische) Sprint Velocity Deines Scrum Teams zur Ermittlung eines potenziellen Release Dates nutzen. Dabei kannst Du zunächst ganz simpel vorgehen:

Wenn Dein Team eine (durchschnittliche) Velocity von 10 SP hat und Dein Product Backlog Features mit insgesamt 200 SP, dann ist Dein Backlog (wahrscheinlich) nach 20 Sprints abgearbeitet.

Vorhersagen mit der Velocity Range treffen

Die durchschnittliche Sprint Velocity taugt jedoch nur zur groben Einschätzung. Was Du als Product Owner benötigst, ist ein Methode, die Dir dabei hilft, eine Art Zeit-Korridor zu ermitteln. Denn je weiter ein Datum in der Zukunft liegt, desto weniger genau sind ja auch Deine Prognosen.

Möglich wird das durch die sogenannte Velocity Range, die eine wunderbare Ergänzung für Dein Release Burndown Chart ist.

Die Velocity Range besteht aus 3 (historischen) Kennzahlen eines Scrum Teams.

  • Niedrigste Sprint Velocity (der letzten x Sprints)

  • Median der Sprint Velocity (der letzten x Sprints)

  • Höchste Sprint Velocity (der letzten x Sprints)

Nehmen wir einmal das rechts zu sehende Velocity Chart als Beispiel, dann liegt die minimale Velocity bei 5, die maximale Velocity bei 20 und der Median dieses Scrum Teams bei 8.

Velocity Chart der letzten 7 Sprints

Die Velocity Range auf dem Release Burndown Chart

Wenn wir diese Velocity Range einmal auf unser Backlog-Beispiel mit 200 Story Points anwenden, kannst Du als Product Owner drei unterschiedliche Trendlinien nutzen, um auf Deinem Release Burndown Chart einen Zielkorridor zu visualisieren.

Release Burndown Chart mit Velocity Range

Wenn also alles gut läuft, ist dieses Team bereits nach 10 Sprints mit allem fertig. Umgekehrt könnte es auch 40 Sprints dauern, falls die Velocity in jedem Sprint nur bei 5 liegt. Der Median sagt Dir, dass 25 Sprints recht gut in der Mitte liegt. Die anvisierten 20 Sprints kann das Team aber wahrscheinlich nicht halten.

Trotzdem ist der Korridor zu Beginn Deines Projektes mit 10 bis 40 Sprints sehr groß.

Aktualisiere die Velocity Range nach jedem Sprint

Glücklicherweise kannst Du Dein Release Burndown Chart von Sprint zu Sprint aktualisieren und daraus neue Erkenntnisse ableiten.

Nehmen wir einmal an, Du hättest das Projekt begonnen und bereits 5 Sprints abgeschlossen.

Das Velocity Chart hat sich wie hier zu sehen verändert. Die Werte für die minimale und maximale Velocity, aber auch den Medianwert sind nun andere.

Die minimale Velocity liegt nun bei 6 SP, die maximale Velocity ist weiterhin 20 SP. Der Medianwert liegt nun bei 12 SP pro Sprint.

Velocity Chart nach 5 weiteren Sprints

Außerdem kommt hinzu, dass sich der Scope Deines Projektes verändert hat. Denn Euer Team hat ja bereits 5 Sprints gearbeitet und den verbleibenden Aufwand von 200 auf 151 Story Points verringert.

Der Zielkorridor Deines Projektes liegt nun zwischen 13 und 34 Sprints, wobei der Median 18 Sprints prognostiziert. Damit sieht es nun schon deutlich positiver aus, die Deadline von 20 Sprint zu halten.

Auf dem Release Burndown Chart sieht das Ganze folgendermaßen aus:

Release Burndown Chart mit Velocity Range

Scope-Veränderungen auf dem Release Burndown Chart abbilden

Der Umfang (Scope) eines Projektes bleibt natürlich in den seltensten Fällen konstant. Sehr häufig kommen im späteren Verlauf Aufwände hinzu, die zu Beginn nicht klar waren. Diese Scope-Veränderungen kannst Du in Deinem Release Burndown Chart visualisieren, indem Du die Null-Linie weiter nach unten verschiebst.

Bleiben wir einmal bei unserem Beispiel und nehmen an, dass im 5. Sprint wichtige Aufgaben hinzukommen, die einen geschätzten Aufwand von 20 Story Points haben. Auf Deinem Release Burndown Chart trägst Du diese Information wie folgt ein:

Release Burndown Chart mit Scope-Veränderung

Auf dem Release Burndown Chart kannst Du die neuen Prognosen der Velocity Range einfach ablesen. Dazu nutzt Du nicht mehr die ehemalige Null-Linie, sondern die darunter befindliche Scope-Linie. Der Zeitkorridor für das fertige Projekt liegt damit bei 14 bis 37 Sprints. Der Medianwert prognostiziert 20 Sprints.

Fazit zu Burndown Charts

Wie Du siehst, sind Release und Sprint Burndown Charts wirklich mächtige visuelle Tools! Auch wenn der Scrum Guide sie nicht direkt vorschreibt, kann ich Dir ihre Nutzung nur ans Herz legen.

Ob Ihr aber Eure Aufwände im Sprint Burndown Chart mit Stunden oder mit Story Points visualisiert, ist sicherlich Geschmacksache beziehungsweise Vorliebe. Das Gleiche gilt für die Nutzung von durchschnittlicher Velocity, Medianwert oder Velocity Range beim Release Burndown Chart.

Experimentiert mit verschiedenen Varianten und probiert sie einfach mal aus. Denn nur so könnt Ihr herauszufinden, was am besten für Euer Team passt.