Agile Tools sollten Übergaben absichern und nicht nur Sprints organisieren

Freitagnachmittag, letzter Tag des Sprints. Das Entwicklungsteam setzt das neue Export-Feature auf „Fertig“, alle Tests laufen grün, die Karte wandert auf dem Board in die rechte Spalte. Alle gehen mit dem guten Gefühl ins Wochenende, die Arbeit sei erledigt - und genau an dieser Stelle beginnt ein Lehrstück über die Aufgabenübergabe im Team.

Das zweite Team, zuständig für Dokumentation und Rollout, hat die Aufgabe nämlich nie als seine eigene erkannt. Auf seinem Board existiert keine Karte dazu, im Planning fiel kein Wort darüber. Das Feature ist fertig entwickelt und trotzdem wirkungslos: Das eine Team hält es für übergeben, das andere für nie angekommen. Drei Wochen später fragt ein Kunde im Termin nach der zugesagten Funktion, und niemand am Tisch kann erklären, warum sie nicht live ist.

Die Aufgabenübergabe im Team, auch Task-Handover genannt, bezeichnet den Moment, in dem eine Aufgabe samt Verantwortung und Kontext von einer Person oder Gruppe zur nächsten wechselt. Sie betrifft alle, die in Sprints, über Teamgrenzen hinweg oder mit Vertretungen arbeiten: Entwicklungsteams, Product Owner, Projektleiter und Fachabteilungen. Relevant wird sie immer dann, wenn die Zuständigkeit wechselt - beim Sprintwechsel, an Schnittstellen zwischen Teams, bei Urlaub oder bei einer Eskalation. Gelingt die Übergabe, kommt die Aufgabe mit vollständigem Kontext an und läuft ohne Rückfragen weiter. Scheitert sie, entstehen genau die Lücken, in denen fertige Arbeit unbemerkt liegen bleibt.

Dieser Artikel enthält eine Übergabe-Checkliste mit fünf Punkten und je einem Warnsignal, an dem Sie erkennen, dass eine Übergabe gerade schiefgeht. Die Aufgabenfunktionen von Bitrix24 dienen dabei als Beispiel dafür, wie sich diese Punkte direkt am Vorgang verankern lassen, statt in Chatnachrichten zu verschwinden.

Agile Tools organisieren Sprints, sichern aber keine Übergaben ab

Werfen Sie einen Blick in ein beliebiges agiles Tool: Backlog, Sprint-Planung, Velocity-Diagramm, Burndown-Chart. Der gesamte Funktionsumfang kreist um die Frage, wie ein Team seine Arbeit innerhalb eines Zeitfensters organisiert. Für den Moment, in dem eine Aufgabe dieses Zeitfenster oder dieses Team verlässt, sehen die meisten Werkzeuge wenig mehr vor als einen Statuswechsel.

Genau dieser Moment ist aber der riskanteste im ganzen Ablauf. Solange eine Aufgabe bei einer Person liegt, gibt es jemanden, der sich erinnert, nachhakt und Blockaden meldet. Zwischen zwei Zuständigkeiten gehört die Aufgabe für einen kurzen Zeitraum niemandem: Der Abgebende hat sie innerlich abgehakt, der Übernehmende weiß noch nichts von seinem Glück. Läuft in diesem Fenster etwas schief, fällt es keinem der beiden auf, weil sich beide auf den jeweils anderen verlassen.

Der Statuswechsel auf dem Board täuscht dabei eine Sicherheit vor, die es nicht gibt. „Erledigt“ auf dem Board des Absenders bedeutet nicht „angenommen“ auf der Seite des Empfängers. Zwischen diesen beiden Zuständen liegen eine Benachrichtigung, die gelesen werden muss, ein Kontext, der verstanden werden muss, und eine Bestätigung, die aktiv erfolgen sollte. Fehlt eines dieser drei Elemente, existiert die Übergabe nur in der Vorstellung des Absenders.

Ein belastbarer Übergabeprozess behandelt den Wechsel der Zuständigkeit deshalb als eigenen Arbeitsschritt mit eigenen Kriterien, nicht als Nebeneffekt eines Statuswechsels. Wo dieser Schritt im agilen Alltag überall anfällt, zeigt der nächste Abschnitt.

Die fünf typischen Übergabepunkte im agilen Alltag

Übergaben passieren häufiger, als die meisten Teams vermuten. Ein Übergabepunkt ist dabei jede Stelle im Ablauf, an der die Zuständigkeit wechselt und damit eine Aufgabenübergabe im Team nötig wird. Fünf Situationen kehren in fast jedem agilen Umfeld wieder, und jede hat ihre eigene Bruchstelle.

Übergabepunkt 1: Sprintwechsel

Beim Sprintabschluss bleiben fast immer Aufgaben übrig, die nicht fertig geworden sind. Die bequeme Lösung: Die Karte rollt unverändert in den nächsten Sprint. Riskant wird das, wenn im neuen Sprint eine andere Person übernimmt oder sich die Priorität verschoben hat. Der Restaufwand, der Grund für den Übertrag und der aktuelle Stand müssen explizit mitwandern, sonst beginnt der neue Bearbeiter mit einer Schätzung, die längst überholt ist.

Übergabepunkt 2: Teamgrenzen

An den Schnittstellen zwischen Teams geht am meisten verloren, weil hier zwei Arbeitswelten aufeinandertreffen. Das gilt für die abteilungsübergreifende Zusammenarbeit zwischen Entwicklung und Marketing genauso wie für zwei Entwicklungsteams mit unterschiedlichen Boards. Besonders anfällig sind Organisationen, die Scrum und Kanban kombinieren: Das Scrum-Team denkt in Sprints von zwei Wochen, das Kanban-Team im Support zieht kontinuierlich Tickets. Eine Aufgabe, die kurz nach dem Planning des einen Teams ankommt, wartet im schlimmsten Fall einen ganzen Takt lang, ohne dass jemand die Wartezeit bemerkt.

Übergabepunkt 3: Rollenwechsel

Auch innerhalb eines Teams wechselt eine Aufgabe die Hände: von der Entwicklerin zum Tester, vom Tester zum Product Owner für die Abnahme. Diese Übergaben wirken harmlos, weil alle Beteiligten am selben Board arbeiten. Genau deshalb wird hier am wenigsten dokumentiert. Der Tester erfährt, dass etwas testbereit ist, aber selten, welche Randfälle die Entwicklerin bewusst ausgeklammert hat und warum.

Übergabepunkt 4: Urlaubsvertretung

Zwei Wochen Abwesenheit bedeuten in einem aktiven Projekt zwei Wochen, in denen jemand anderes Entscheidungen treffen muss. Ohne geplante Übergabe wird die Vertretung zur reinen Durchgangsstation: Sie leitet Fragen an den Abwesenden weiter oder vertagt sie bis zu seiner Rückkehr. Die Aufgabe ruht dann de facto, obwohl sie auf dem Board als aktiv geführt wird.

Übergabepunkt 5: Eskalation

Wenn eine Aufgabe blockiert ist und zur Führungskraft oder in ein anderes Gremium wandert, findet ebenfalls eine Übergabe statt - nur nach oben statt zur Seite. Die Bruchstelle: Die Führungskraft entscheidet auf Basis einer mündlichen Kurzfassung, der die Hälfte des Kontexts fehlt. Die Entscheidung fällt dann schnell, aber auf dünner Grundlage, und das Team arbeitet anschließend an der Korrektur.

Diese fünf Übergabepunkte - Sprintwechsel, Teamgrenzen, Rollenwechsel, Urlaubsvertretung und Eskalation - sind planbar. Für jeden lässt sich vorab festlegen, was übergeben werden muss und woran ein Scheitern früh erkennbar ist. Genau das leistet die folgende Checkliste.

Übergabe-Sicherheitsset: Vorlagen, Prüflisten, Verantwortungsmatrix

Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten

Ich bestätige hiermit, dass ich die Bedingungen der Datenschutzpolitik von Bitrix24 vollständig gelesen und verstanden habe.

Die Übergabe-Checkliste: fünf Punkte, fünf Warnsignale

Eine brauchbare Übergabe-Checkliste beantwortet zwei Fragen pro Übergabepunkt: Was muss den Besitzer wechseln, und woran erkennen Sie innerhalb der ersten Tage, dass die Übergabe gerade misslingt? Die Warnsignale sind dabei der eigentliche Wert der Liste, denn sie machen ein stilles Scheitern sichtbar, bevor Wochen vergehen.

Auffällig ist das zweite Warnsignal: Keine Rückfragen sind kein gutes Zeichen, sondern ein schlechtes. Ein Team, das eine fremde Aufgabe wirklich übernommen hat, stößt praktisch immer auf mindestens eine Unklarheit. Bleibt es vollständig still, wurde die Aufgabe mit hoher Wahrscheinlichkeit noch gar nicht angesehen.

Damit die Checkliste greift, müssen Teams den Aufgabenstatus dokumentieren, und zwar dort, wo die Aufgabe lebt, nicht in einem separaten Protokoll. Ein Status wie „Zur Übergabe bereit“ mit ausgefüllter Checkliste sagt dem Empfänger präzise, was ihn erwartet. Für die Aufgabenübergabe im Team gilt dabei eine einfache Faustregel: Erst wenn die übernehmende Person den Empfang aktiv bestätigt hat, ist die Übergabe abgeschlossen. Vorher ist sie ein Angebot.

Die Checkliste beschreibt allerdings nur die Mechanik. Wann eine Aufgabe überhaupt übergabefähig ist, regelt ein anderes Instrument, das die meisten agilen Teams bereits besitzen und selten dafür nutzen.

Definition of Done als Übergabevertrag statt Formalie

Die Definition of Done, also die gemeinsam vereinbarten Fertigstellungskriterien eines Teams, fristet vielerorts ein Schattendasein als Poster neben dem Board: getestet, dokumentiert, deployt. Gelesen wird sie beim Onboarding, danach nie wieder. Dabei steckt in ihr ein Vertrag, der Übergaben absichern kann, wenn beide Seiten ihn ernst nehmen.

Der Gedanke dahinter: „Fertig“ heißt übergabefähig. Eine Aufgabe erfüllt die Definition of Done erst, wenn die nächste Station sie ohne Rückgriff auf das Gedächtnis des Absenders weiterbearbeiten kann. Das verschiebt die Perspektive. Der Absender fragt sich nicht mehr „Bin ich fertig?“, sondern „Kann die Empfängerin damit arbeiten?“. Diese zweite Frage hat messbare Kriterien: Checkliste ausgefüllt, Randfälle notiert, Ansprechpartner benannt.

Wirksam wird der Vertrag, wenn die empfangende Seite ihn mitschreibt. Ein Team, das regelmäßig Arbeit vom Entwicklungsteam übernimmt, formuliert seine drei häufigsten Rückfragen als feste Punkte in der Definition of Done. Ab dann prüft der Absender genau die Dinge, an denen Übergaben bisher gescheitert sind. Wer Verantwortung übergeben will, braucht ein Gegenüber, das sie bewusst annimmt - und die gemeinsam formulierte Definition of Done ist der Ort, an dem beide Seiten festhalten, was „annehmen“ konkret bedeutet.

Welche Rolle die Definition of Done bei der Aufgabenübergabe im Team am Ende spielt, entscheidet sich also an ihrer Formulierung: Eine Liste technischer Kriterien sichert den Code, ein Übergabevertrag sichert den Wechsel der Zuständigkeit. Beides zusammen sichert die Fertigstellung und die Übergabe ab. Was dem Empfänger dann noch fehlt, ist der Kontext.

"Nach der Einführung von Bitrix24 haben wir die Geschäftsprozesse in unserem Unternehmen maximal vereinfacht."

Geschäftsführer, Alexander Dortmann

DortmannKids

KOSTENFREI STARTEN

Kontext mitgeben: was außer dem Status übergeben werden muss

Ein korrekter Status beantwortet die Frage „Wo steht die Aufgabe?“. Er beantwortet nicht die Frage „Warum steht sie dort?“. Genau an dieser zweiten Frage entscheidet sich, ob die übernehmende Person weiterarbeiten kann oder erst rekonstruieren muss, was vor ihr geschah.

Vier Bausteine gehören deshalb zu jeder vollständigen Übergabe:

1. Getroffene Entscheidungen samt Begründung: Nicht „Wir nutzen Variante B“, sondern „Wir nutzen Variante B, weil Variante A die Schnittstelle des Bestandssystems überlastet hätte“. Ohne das Warum wird jede Entscheidung früher oder später neu diskutiert.
2. Offene Fragen und bekannte Risiken: Was ist ungeklärt, was wackelt, wo wurde bewusst eine Abkürzung genommen? Diese Liste erspart der Empfängerin die unangenehmste Erfahrung: ein Risiko zu entdecken, das der Vorgänger längst kannte.
3. Ansprechpartner: Wer beantwortet fachliche Fragen, wer beantwortet technische Fragen, wer kennt die Vorgeschichte beim Kunden? Drei Namen mit Zuständigkeit sparen tagelange Suchketten.
4. Historie am Vorgang: Bisherige Kommentare, verworfene Ansätze, relevante Dateien und Verknüpfungen, gesammelt an der Aufgabe selbst statt verstreut über Postfächer und Chatverläufe.

Wer Kontextverlust vermeiden will, hängt diese vier Bausteine an die Aufgabe selbst. Eine Übergabe per E-Mail trennt den Kontext vom Vorgang: Die Aufgabe wandert ins neue Board, die Begründungen bleiben im Postfach des Absenders und verschwinden dort beim nächsten Aufräumen. Der Wissensverlust im Projekt beginnt selten mit einer Kündigung, er beginnt mit der ersten Übergabe, bei der nur der Status weitergereicht wird und der Rest im Kopf des Vorgängers bleibt.

Das kostet auf den ersten Blick Schreibarbeit. Verglichen mit der Alternative bleibt die Bilanz trotzdem positiv: Der Aufwand liegt beim Absender im Minutenbereich, die Rekonstruktion beim Empfänger im Stundenbereich, sobald Rückfragen, Wartezeiten und Fehlversuche zusammenkommen. So nützlich diese Disziplin ist, ein Selbstläufer ist sie nicht - und es gibt Situationen, in denen die beste Checkliste das eigentliche Problem nicht löst.

Grenzen der Checkliste: wann Prozesse allein nicht reichen

Eine Checkliste strukturiert Übergaben, aber sie repariert keine Zusammenarbeit. Drei Grenzen sollten Sie kennen, bevor Sie die Liste im Team einführen.

Die erste Grenze ist fehlendes Vertrauen. Wo Teams einander die Schuld für Verzögerungen zuschieben, verkommt jede Checkliste zur Absicherungsbürokratie: Der Absender füllt Felder aus, um später beweisen zu können, dass der Fehler beim Empfänger lag. Die Übergabe wird dokumentiert und misslingt trotzdem, weil niemand anruft, wenn etwas unklar ist. Ein kurzes Übergabegespräch von zehn Minuten leistet in solchen Teams mehr als jedes weitere Pflichtfeld.

Schwerer zu greifen ist die zweite Grenze: die fehlende gemeinsame Sprache. „Getestet“ bedeutet für die Entwicklerin Unit-Tests, für den Support einen Durchlauf aus Kundensicht, für den Product Owner die Abnahme. Solange solche Begriffe nicht geklärt sind, bestätigen beide Seiten die Checkliste guten Gewissens und meinen verschiedene Dinge. Ein Glossar der fünf wichtigsten Begriffe, gemeinsam verfasst, kostet einen Nachmittag und beendet solche Missverständnisse dauerhaft.

Am brisantesten ist die dritte Grenze: zu viele Übergaben. Wandert eine gewöhnliche Aufgabe im Regelfall durch vier oder fünf Hände, ist der Übergabeprozess nicht das Problem, sondern der Zuschnitt der Teams. Jede Station kostet Wartezeit und Kontext, und keine Checkliste holt diese Verluste vollständig zurück. Die wirksamere Antwort ist dann strukturell: Verantwortungen zusammenlegen, crossfunktionale Teams bilden, Übergaben ersatzlos streichen. Die Checkliste zeigt in diesem Fall vor allem, wie groß das strukturelle Problem ist - schon das ist ein brauchbares Ergebnis.

Bleibt die Zahl der Übergaben dagegen überschaubar, lohnt sich der nächste Schritt: die Checkliste aus dem Wiki in das Werkzeug zu holen, in dem die Aufgaben ohnehin liegen.

Aufgabenübergabe im Team mit Bitrix24 absichern

Damit die agile Zusammenarbeit auch an den Übergabepunkten belastbar bleibt, muss die Checkliste dort hängen, wo die Arbeit stattfindet. Bitrix24 bringt dafür fünf Funktionen mit, die sich direkt auf die fünf Übergabepunkte anwenden lassen.

• Checklisten in der Aufgabe: Jede Aufgabe in Bitrix24 kann eine Checkliste enthalten. Legen Sie Ihre Übergabepunkte als wiederverwendbare Vorlage an - Restaufwand notiert, Entscheidungen begründet, Ansprechpartner benannt, Empfang bestätigt. Der Empfänger sieht auf einen Blick, ob die Übergabe vollständig ist, und offene Punkte bleiben sichtbar, statt stillschweigend unterzugehen.
• Verantwortliche Person plus Beobachter: Bei jedem Wechsel trägt genau eine Person die Verantwortung für die Aufgabe. Der bisherige Bearbeiter bleibt als Beobachter eingetragen und kann die weiteren Aktivitäten verfolgen, ohne weiterhin für die Aufgabe zuständig zu sein. Das löst das Niemandsland zwischen zwei Zuständigkeiten auf: Die Aufgabe gehört ab dem Wechsel eindeutig der neuen Person, und der Vorgänger kann weiterhin nachvollziehen, wann seine Erfahrung gebraucht wird. Für die Urlaubsvertretung funktioniert das identisch; nach zwei Wochen wechseln die Rollen einfach wieder zurück.
• Kommentarverlauf am Vorgang: Entscheidungen, verworfene Ansätze und Rückfragen sammeln sich als Kommentare direkt an der Aufgabe. Die vier Kontext-Bausteine aus diesem Artikel liegen damit genau dort, wo die nächste Bearbeiterin sie sucht, statt im Postfach des Vorgängers. Wer sechs Monate später wissen will, warum Variante B gewählt wurde, liest es am Vorgang nach.
• Automatisierungsregeln beim Statuswechsel: Wechselt eine Aufgabe in den Status „Zur Übergabe bereit“, kann eine Automatisierungsregel die neue Bearbeiterin benachrichtigen, eine Bestätigungsaufgabe erstellen oder nach zwei Arbeitstagen eine Erinnerung auslösen, falls die vereinbarte Empfangsbestätigung noch aussteht. So überwacht das System ein eindeutig prüfbares Warnsignal, und kein Mensch muss selbst an die Frist denken.
• Kontrolle nach Fertigstellung: Für Aufgaben, bei denen die Übergabe ausdrücklich bestätigt werden muss, lässt sich eine Prüfung nach Abschluss vorsehen. Sobald die verantwortliche Person ihre Arbeit beendet, bleibt die Aufgabe bis zur Freigabe im Prüfstatus. Die empfangende Seite kann das Ergebnis annehmen oder zur Überarbeitung zurückgeben. So wird aus „erledigt“ nicht automatisch „angenommen“.

Ein Beispiel aus dem Alltag: Eine Product Ownerin geht für zwei Wochen in den Urlaub. Sie setzt ihre Vertretung bei den drei laufenden Aufgaben als verantwortliche Person ein, trägt sich selbst als Beobachterin ein und füllt je Aufgabe die Übergabe-Checkliste aus, inklusive der Entscheidungen, die die Vertretung allein treffen darf. Eine Automatisierungsregel erinnert die Vertretung am zweiten Tag an die Empfangsbestätigung. Bei ihrer Rückkehr liest die Product Ownerin den Kommentarverlauf und kennt in einer halben Stunde jeden Zwischenstand - ohne Übergabemeeting, ohne Rekonstruktion aus dem Chat.

Eine Aufgabenübergabe im Team ist erst abgeschlossen, wenn Verantwortung, Kontext und offene Entscheidungen tatsächlich bei der nächsten Person angekommen sind. Checklisten, eindeutige Zuständigkeiten, ein vollständiger Kommentarverlauf und eine aktive Empfangsbestätigung machen diesen Wechsel überprüfbar, statt ihn nur durch einen neuen Status auf dem Board anzudeuten.

Wenn Sie Ihre Aufgabenübergabe im Team auf diese Weise absichern möchten, legen Sie ein Bitrix24-Konto an, erstellen Sie Ihre erste Aufgabe mit der Übergabe-Checkliste aus diesem Artikel und testen Sie den Ablauf am nächsten Sprintwechsel.

FAQ