Blog

Das Muster des Business Support Teams

Pieter Rijken

Aktualisiert Oktober 22, 2025

7 Minuten

Teams, die planbare oder Ad-hoc-Arbeit mit agilen Methoden organisieren, weisen oft ein ähnliches Muster auf. Wenn sie in der Regel für den Betrieb der Anwendung, die Unterstützung des Unternehmens bei ihrer Nutzung und/oder die Entwicklung neuer Funktionen auf der Grundlage einer Anwendung (in der Regel eines Drittanbieters) verantwortlich sind, nenne ich sie "Business Support Teams". Ich habe festgestellt, dass je mehr Ad-hoc-Arbeit diese Teams zu bewältigen haben, desto mehr Probleme haben sie mit einem einzigen Backlog-Ansatz für die Verwaltung dieser Arbeit. In diesem Beitrag zeige ich Ihnen, wie solche Business-Support-Teams ein bestimmtes Set-up von Boards und Vereinbarungen verwenden können, um ihre Arbeit in den Griff zu bekommen.

Kick-Off

In der Praxis verwenden Teams, die mit Agile beginnen, häufig standardmäßig Scrum. Es bietet zunächst eine Struktur und legt einen Rhythmus für die häufige Lieferung von Arbeit und Feedbackschleifen fest. Solche Teams beginnen oft mit einer "typischen" Scrum-Tafel, die aus drei Bahnen besteht: "Zu tun", "In Arbeit" und "Erledigt".Hier hat das Team ein Backlog, das aus Funktionen besteht, die das Geschäft unterstützen, ein visuelles Board mit drei Bahnen, "Definition der Bereitschaft", "Definition der Erledigung" und eine Kadenz von zwei- oder manchmal dreiwöchigen Sprints.Hinweis: Die "Definition der Bereitschaft" ist nicht Teil von Scrum und eine gute Praxis, die oft von Scrum-Teams verwendet wird. Siehe auch diesen Blog.

Business Support Team

Ein Business Support Team unterscheidet sich von anderen Teams sowohl durch die Liste der Funktionen (Anwendungserweiterungen) als auch durch die Art der Arbeit, die es leistet:

Anforderung von Informationen, z.B. Berichte
Neue Funktionen zur Beschleunigung des Geschäfts
Langfristige Verbesserungen
Aufrechterhaltung des Betriebs der Anwendung und der Plattform
Tägliche und routinemäßige operative Aufgaben
Umgang mit Vorfällen in der Produktion

Die Arbeit folgt dem von Serge Beaumont in dieser Präsentation beschriebenen Muster mit dem Zusatz von "Geschäftsanfragen" (Anfragen nach Informationen).

Häufig anzutreffende Unzufriedenheiten

Aus geschäftlicher Sicht können die Kunden eine der folgenden Erfahrungen machen:

Unvorhersehbarer Service, wann neue Funktionen verfügbar sind
Begrenzte Unterstützung für Fragen
Lange Wartezeiten für Informationen und/oder Berichte

Andererseits kann das Team selbst Erfahrungen machen:

Starke Einschränkungen bei der Arbeit an neuen Funktionen (aufgrund der Arbeit, die erforderlich ist, um die Anwendung in Betrieb zu halten)
Unterbrechungen aufgrund von eingehenden Anfragen oder Vorfällen, die sofortige Aufmerksamkeit erfordern, führen zu längeren Vorlaufzeiten
Zu viel Arbeit in Arbeit
Der Druck, für bestimmte Gruppen von Geschäftsanwendern etwas zu leisten, geht auf Kosten anderer Interessengruppen.

Geschäftserwartungen

Die Erwartungen des Kunden an die Arbeiten können variieren, umfassen aber in der Regel Folgendes:

Ersuchen um Informationen, z.B. Berichte,
- Art: ad hoc, und kann variieren
- Erwartung: in der Regel zwischen einer Woche und einem Monat
Neue Funktionen zur Beschleunigung des Geschäfts
- Natur: kontinuierlich in den Rückstand geraten
- Erwartung: Vorhersehbarkeit
Aufrechterhaltung des Betriebs der Anwendung und der Plattform
Tägliche operative und Routineaufgaben
- Erwartung: einfach eine laufende Plattform zu haben
Umgang mit Vorfällen in der Produktion
- Erwartung: so schnell wie möglich

Aus der Sicht des Teams:

Langfristige Verbesserungen
- Erwartung: regelmäßig Zeit damit verbringen zu können
Aufrechterhaltung des Betriebs der Anwendung und der Plattform
Umgang mit Vorfällen in der Produktion
- Erwartung: die geringstmöglichen Störungen im Team

Die Herausforderung für das Team besteht darin, den Spagat zwischen vorhersehbaren Vorlaufzeiten für neue Funktionen, Arbeiten, die sofort erledigt werden müssen, und akzeptablen Vorlaufzeiten für Geschäftsanfragen zu schaffen.

Vorstand & Richtlinien

Vorstand und eine Reihe von Richtlinien, die gut funktionieren, siehe unten:

Die Spalten sind die gleichen, aber die Arbeit ist anders verteilt. Das Spielbrett hat vier Bahnen: Erweitern: Reserviert für Arbeiten, die sofort erledigt werden müssen, z.B. Produktionsvorfälle. Manchmal auch "Fast Lane" genannt. Maximal ein Workitem zu jeder Zeit. (Regelmäßige) Änderungen: Hält regelmäßige Arten von Arbeit, die "vorhersehbar genug" sein muss. Dringend: Arbeiten, die mit einem bestimmten Service erledigt werden müssen, z.B. innerhalb von fünf Arbeitstagen. Hauptsächlich geschäftliche Anfragen nach Informationen, Support und möglicherweise Probleme mit einer niedrigeren Prioritätsstufe als eins. Operativ: Für alle Aufgaben, die erforderlich sind, um die Anwendung am Laufen zu halten. Typischerweise tägliche Routineaufgaben. Hinweis: Damit dies funktioniert, müssen Sie sich auf Grenzen für die unfertige Arbeit (WIP) einigen und Kriterien festlegen, wann die Arbeit in die Fahrspuren einfließen darf, wie im folgenden Abschnitt beschrieben. Hinweis: Wie oben erwähnt, folgt dies dem in der Präsentation beschriebenen Muster, wobei die Zeile für "Dringende" Arbeit hinzugefügt wurde.

Politik Beispiel

Wie in der Präsentation erläutert, überwachen die "Definition von fertig" und die "Definition von erledigt" die Qualität der Arbeit, die das Team betritt bzw. verlässt. Legende Definition von Run Gibt den Zustand der Anwendung an - was bedeutet "running"? Workitems, die das System in diesen Zustand zurückversetzen, werden auf die "Expedite"-Spur gesetzt. Beispiel:

Anwendung ist eingerichtet und läuft
Die Antwort der Anwendung erfolgt innerhalb von ... Sekunden
Der kritische Teil der Anwendung funktioniert
...

Hinweis: Eine andere Art von Artikeln ist in der Regel in dieser Spur erlaubt: Artikel, die eine Frist haben und zu spät geliefert werden - und für die es eine Richtlinie gibt! Definition von Änderungen Regelmäßige Anfragen nach neuen Funktionen und Verbesserungen. Vorhersagbarkeit ist am wichtigsten. Eine gewisse Abweichung von der Vorlaufzeit wird als akzeptabel angesehen. Service Level ist ... Wochen mit 85% Liefertreue (eine Standardabweichung Service Level). Definition von Anfragen Geschäftliche Anfragen. Typischerweise handelt es sich dabei um Supportanfragen, die Erstellung von Berichten oder Informationen (z.B. können nationale Banken im Rahmen einer Prüfung Berichte anfordern). Auch andere Arten von Anfragen, die nicht so wichtig sind, dass sie in die Expedite-Spur gehören, und die mehr als ein paar Stunden Arbeit erfordern. Für diese werden Vorlaufzeiten erwartet, die jedoch deutlich kürzer sind als die Vorlaufzeiten für Änderungen. Beispielkriterien:

Geschäftliche Anfragen, die weniger als eine Woche Arbeit erfordern
Ein Problembericht mit dem Schweregrad 2, 3, oder 4
Der Service-Level beträgt .... Arbeitstage mit 95% pünktlicher Lieferung

Definition des Betriebs Beschreibt die Routineaufgaben, die regelmäßig erledigt werden müssen, damit das System wie in der "Arbeitsweise" angegeben funktioniert. Beispielkriterien:

Weniger als zwei Stunden Arbeit
Routineaufgaben wie in der "Arbeitsweise" beschrieben
Kann noch am selben Tag begonnen und abgeschlossen werden
Maximal ... Stunden pro Tag durch das Team.

Es ist wichtig, den Zeitaufwand des Teams für diese Aufgaben zu begrenzen, damit das Team das erwartete Serviceniveau für die anderen Arbeiten aufrechterhalten kann.

Kadenzen

Von allen oben erwähnten Workitem-Typen ist nur das Item "Änderung" planbar. "Laufende" Aufgaben sind von Natur aus sehr ad hoc, wie es auch bei "operativen" Aufgaben der Fall ist (einige sind Routine und andere tauchen einfach im Laufe des Tages auf). Anfragen aus dem Unternehmen kommen in der Regel kurzfristig und mit der Erwartung kurzer Lieferzeiten. Da die meisten Workitem-Typen ad hoc sind, muss die Planung und Terminierung öfter als einmal pro Sprint durchgeführt werden. Die "To-Do"-Liste wird kontinuierlich aufgefüllt, sobald neue Arbeit eintrifft. Das Team kann sich auf eine Richtlinie einigen, wie oft und auf welche Weise dies geschehen soll. Die Reihenfolge, in der die Arbeit zwischen den Zeilen geplant wird, wird entweder vom Product Owner festgelegt oder durch eine Richtlinie selbst geregelt, die auch WIP-Limits für die Zeilen festlegt. Damit wird die verfügbare Kapazität des Teams effektiv auf die einzelnen Workitem-Typen aufgeteilt.

Zusammenfassung

Business Support Teams folgen einem Muster, das dem in der Präsentation beschriebenen sehr ähnlich ist. Zusätzlich zu den Arbeitstypen "Ausführung", "Änderung" und "Betrieb" wird der Typ "Anfrage" identifiziert. Die Arbeit wird nicht durch einen einzelnen Auftragsbestand ähnlicher Aufgaben beschrieben, sondern durch einen Auftragsbestand von verschiedenen Arten von Arbeit. Die Art und Weise, wie die Teams mit diesen Typen umgehen, ist unterschiedlich, da jeder Typ ein anderes Risikoprofil (Class of Service) aufweist. Ein Rückstand von Arbeitsarten ermöglicht es dem Team,: