Klare Workflow-Statusbezeichnungen machen Übergaben über Tools hinweg deutlich. Lernen Sie 5–7 praktische Status kennen, was jeder bedeutet und wie Sie sie auf Web und Mobile konsistent halten.
Vage Workflow-Statusbezeichnungen schaffen Verwirrung, die wie Beschäftigung aussieht. Leute schieben Items voran, aber niemand ist sich sicher, was sich tatsächlich geändert hat. Ein Ticket mit dem Marker „In Bearbeitung“ kann je nach Person bedeuten: „Ich habe angefangen darüber nachzudenken“, „Ich bin blockiert“ oder „Ich bin fertig und warte auf Review“.
Diese Diskrepanz verursacht drei vorhersehbare Probleme: Nacharbeit, verpasste Übergaben und laute Benachrichtigungen. Wenn ein Status nicht sagt, was die nächste Person tun soll, hüpft die Arbeit hin und her. Wenn eine Übergabe in einem vagen Label versteckt ist, bleibt sie liegen, bis es jemand bemerkt. Wenn alle Status nur aktualisieren, um Aktivität zu signalisieren, wird Ihr Feed verschwommen und echte Änderungen sind leicht zu übersehen.
Ein weiteres häufiges Symptom ist, dass dasselbe Label auf verschiedenen Bildschirmen unterschiedlich verwendet wird. Ein Teammitglied nutzt „Bereit“, um „bereit zur Prüfung“ zu bedeuten, ein anderes nutzt „Bereit“, um „bereit zum Starten“ zu meinen. Ein Manager, der das Board prüft, kann nicht erkennen, ob das Team wartet, arbeitet oder fertig ist.
Das Ziel ist nicht, jeden Randfall zu beschreiben. Das Ziel ist, den normalen Ablauf mit wenigen Status klar zu machen. Wenn Status überall konsistent sind, bekommen Sie schnellere Übergaben und weniger Fragen wie „Ist das jetzt wirklich erledigt?"
Wenn Ihr Team nicht weiß, wo es anfangen soll, streben Sie 5–7 Status an, die die meisten Arbeiten abdecken: einen für neue Items, einen für aktive Arbeit, einen für wartende oder blockierte Arbeit, einen für Prüfung oder Freigabe und einen für erledigt. Fügen Sie Details nur hinzu, nachdem die Basics stabil sind und alle dieselben Bedeutungen verwenden.
Ein Statuslabel ist ein gemeinsames Versprechen darüber, was als Nächstes passiert. Wenn jemand einen Status ändert, sollte jeder den nächsten Schritt vorhersagen können, ohne nachzufragen.
Gute Workflow-Statusbezeichnungen beschreiben die aktuelle Realität der Arbeit, nicht die Meinung einer Person darüber. Wenn das Label wahr ist, kann das Team sagen, ob das Item sich bewegt, wartet oder blockiert ist, und wer als Nächstes handhaben soll.
Ein Status ist nicht dasselbe wie Priorität, Zuständiger, Kategorie oder Fortschrittsnotizen. Diese Felder können wichtig sein, aber sie in den Status zu mischen macht diesen unzuverlässig.
Es hilft außerdem, „State“ (Zustand) von „Stage“ (Phase) zu trennen. Zustand ist, was gerade wahr ist (z. B. „blockiert wegen Kundenantwort“). Phase ist, wo das Item im Prozess steht (z. B. „Prüfung“). Man kann beides mischen, aber wenn ein einzelner Status beides versucht zu beschreiben, wird er oft vage.
Ein nützlicher Status sollte eines von drei Dingen auslösen:
Kurzer Realitätscheck: Kann jemand das Label in einer kleinen Listenansicht lesen und trotzdem wissen, was zu tun ist? Wenn die Antwort „kommt darauf an“ ist, verbirgt das Label wahrscheinlich eine Entscheidung, die anderswo getroffen werden sollte (z. B. Prioritätsregeln oder Zuweisung).
Ein Statussystem sollte Arbeit auf einen Blick leichter lesbar machen. Zu viele Status und die Leute vertrauen dem, was sie sehen, nicht mehr. Zu wenige und Sie verlieren die Details, die man für Übergaben braucht.
Für die meisten Teams sind 5–7 Status der Sweet Spot. Sie passen auf einen Bildschirm, funktionieren gut auf einem Kanban-Board oder in einer einfachen Listenansicht und geben genug Signal, um die täglichen Fragen zu beantworten: Was ist blockiert, was wird gerade bearbeitet und was wartet auf Prüfung?
Eine kleine Menge reduziert außerdem das „Status-Suchen“ (raten, welcher von 12 Optionen passt), erleichtert Reporting und zwingt dazu, Priorität, Verantwortlichen und Typ als separate Felder zu führen.
Bezeichnungen können variieren, und das ist in Ordnung. Ein Team sagt „In Bearbeitung“, ein anderes „Doing“. Was nicht variieren darf, ist die Bedeutung. Wenn „In Review“ manchmal „wartet auf QA“ und ein anderes Mal „wartet auf einen Kunden“ heißt, wird Ihr Board zum Rauschen.
Um Bedeutungen konsistent zu halten, richten Sie eine einzige Quelle der Wahrheit ein: ein kurzes Team-Dokument mit jedem Status, seiner Bedeutung und den Regeln, wann etwas in und aus dem Status kommt. Kurz genug, um es in zwei Minuten zu lesen. Verwenden Sie dann dieselben Status überall, wo Arbeit angezeigt wird.
Wenn Sie Statusbezeichnungen wollen, die über die Zeit klar bleiben, beginnen Sie mit einer kleinen Menge, die drei Fragen beantwortet: Wer besitzt es gerade, was passiert als Nächstes und wie sieht „fertig“ aus.
Hier ein einfaches 7-Status-Set, das für die meisten Teams funktioniert, ohne zu ins Detail zu gehen.
| Status | Was es bedeutet (einfach erklärt) | Standardverantwortlicher | Nächster Schritt |
|---|---|---|---|
| Neu | Die Anfrage ist erfasst, aber noch nicht überprüft. | Request-Triage (Lead/PM) | Prüfen und entscheiden: sofort machen, einplanen oder ablehnen. |
| Triagiert | Es wurde geprüft und eingeordnet (Bug vs Feature) und das Team bestätigt die Gültigkeit. | Lead/PM | Umfang klären und entscheiden, ob es umgesetzt wird. |
| Bereit | Es kann ohne fehlende Infos oder Abhängigkeiten begonnen werden. | Lead/PM | Einen Verantwortlichen zuweisen und mit der Arbeit beginnen. |
| In Bearbeitung | Jemand arbeitet aktiv daran. | Zuständiger | Vorantreiben, bis es bereit ist, geprüft zu werden. |
| Zur Prüfung | Die Arbeit ist ausreichend abgeschlossen, um sie zu prüfen (Peer-Review, QA, Stakeholder-Freigabe). | Prüfer | Freigeben oder mit klaren Anmerkungen zurückschicken. |
| Blockiert | Die Arbeit kann wegen einer konkreten Abhängigkeit nicht weitergehen. | Zuständiger | Die Blockade entfernen oder an die Person eskalieren, die helfen kann. |
| Erledigt | Erfüllt die vereinbarte Definition von fertig und benötigt keine weitere Aktion. | Niemand | Für Reporting behalten; nur mit einem neuen Grund wieder öffnen. |
Wichtige Regel: Verwenden Sie nicht nur „Warten“. Wenn etwas feststeckt, nennen Sie es Blockiert und benennen Sie die Abhängigkeit in der Notiz (zum Beispiel „Blocked: Kundenantwort“ oder „Blocked: Zugriff gewähren").
Klare Statusbezeichnungen funktionieren am besten, wenn jede von ihnen eine einfache Frage beantwortet: Was ist gerade wahr?
Neu
Was ist wahr: das Item wurde erfasst, aber noch nicht bewertet.
Was nicht wahr ist: Priorität, Umfang oder Verantwortlicher sind vereinbart.
Eintritt: Eine Anfrage wird eingereicht.
Austritt: Jemand liest sie und verschiebt sie nach Triagiert.
Beispiel: „Ein Support-Mitarbeiter legt einen Bug-Report mit einem Screenshot an.“
Triagiert
Was ist wahr: Das Team versteht die Anfrage genug, um sie zuzuordnen und ihre Gültigkeit zu bestätigen.
Was nicht wahr ist: Es ist bereit zu starten.
Eintritt: Jemand fügt Grundkontext hinzu (Zusammenfassung, Auswirkung, betroffener Bereich).
Austritt: Entweder vorbereitet für die Arbeit (Bereit) oder absichtlich abgelehnt (außerhalb des Workflows behandelt, nicht als Status).
Beispiel: „Der PM markiert es als echten Bug und notiert Reproduktionsschritte.“
Bereit
Was ist wahr: Es kann begonnen werden, ohne dass Infos fehlen.
Was nicht wahr ist: Die Arbeit hat begonnen.
Eintritt: Abnahmekriterien sind klar und Abhängigkeiten vorhanden.
Austritt: Eine Person beginnt die Arbeit und macht die erste sinnvolle Änderung (In Bearbeitung).
Beispiel: „Die Formularfelder und Validierungsregeln sind vereinbart.“
In Bearbeitung
Was ist wahr: Es wird aktiv daran gearbeitet.
Was nicht wahr ist: Es wartet in einer Warteschlange.
Eintritt: Jemand nimmt es auf und beginnt zu arbeiten.
Austritt: Es ist ausreichend fertig zur Prüfung (Zur Prüfung) oder es trifft auf eine Abhängigkeit (Blockiert).
Beispiel: „Ein Entwickler baut das neue Status-Dropdown und speichert die Logik.“
Zur Prüfung
Was ist wahr: Es wird überprüft (Peer-Review, QA oder Stakeholder-Freigabe).
Was nicht wahr ist: Es werden weiterhin neue Features hinzugefügt.
Eintritt: Der Bearbeiter reicht es zur Verifikation ein.
Austritt: Es wird genehmigt und erfüllt die Definition von fertig (Erledigt) oder es geht mit Feedback zurück (In Bearbeitung).
Beispiel: „QA bestätigt, dass es sowohl auf Web als auch Mobile funktioniert."
Blockiert
Was ist wahr: Die Arbeit kann wegen einer spezifischen, benannten Abhängigkeit nicht weitergehen.
Was nicht wahr ist: Das Item ist einfach nur niedriger Priorität.
Eintritt: Der Zuständige trifft auf eine Abhängigkeit, die er nicht allein lösen kann.
Austritt: Die Abhängigkeit ist entfernt und die Arbeit wird wieder aufgenommen (in der Regel In Bearbeitung).
Beispiel: „Blocked: wartet auf Zugriff auf Produktionslogs."
Erledigt
Was ist wahr: Es erfüllt die vereinbarten Abnahmekriterien und ist ausgeliefert oder bereit zur Auslieferung.
Was nicht wahr ist: Es benötigt noch Review, Tests oder Folgearbeiten.
Eintritt: Review besteht und Release-Schritte sind abgeschlossen (gemäß der Team-Definition).
Austritt: keiner; ein Wiederöffnen startet einen neuen Zyklus mit einem klaren Grund.
Beispiel: „Der Fix ist live und der Bug lässt sich nicht mehr reproduzieren."
Sie können unordentliche Status in einer fokussierten Sitzung beheben. Das Ziel ist kein perfektes Modell, sondern ein gemeinsames Set von Labels, das widerspiegelt, wie Arbeit wirklich fließt, mit Regeln, die Ihr Team wiederholen kann.
Bringen Sie je eine Person aus jeder Rolle mit, die mit der Arbeit zu tun hat (Anforderer, Ausführender, Prüfer, Freigebender). Teilen Sie Ihren Bildschirm mit dem aktuellen Board oder der Liste.
Erstellen Sie zuerst die tatsächliche Workflow-Karte (nicht die ideale). Wählen Sie ein typisches Item und verfolgen Sie, was wirklich passiert, inklusive Wartezeiten. Schreiben Sie die Schritte als Verben („entwurf“, „prüfen“, „freigeben"). Wenn ein Schritt nur manchmal passiert, notieren Sie ihn als Abzweigung.
Als Nächstes entfernen Sie Duplikate und benennen unklare Labels um. Führen Sie Labels zusammen, die dasselbe meinen („In Bearbeitung“ vs. „Doing"). Benennen Sie vage Titel („Ausstehend") in etwas um, das eine Handlung auslöst („Blocked: Kundenantwort"). Wenn Sie ein Label nicht in einem Satz erklären können, ist es nicht bereit.
Dann fügen Sie Definitionen mit Ein- und Austrittsregeln hinzu. Für jeden Status schreiben Sie, was wahr sein muss, um einzutreten, und was wahr sein muss, um zu verlassen. Kurz halten. Beispiel: „Zur Prüfung tritt ein, wenn die Arbeit eingereicht wurde; Austritt, wenn Feedback bearbeitet und der Prüfer freigibt."
Danach wählen Sie Verantwortliche für jede Übergabe. Jeder Status sollte einen Standardverantwortlichen haben (eine Rolle reicht). Das verhindert, dass Items hängen bleiben. Beispiel: Items in „Zur Prüfung" gehören dem Prüfer, nicht der Person, die die Arbeit gemacht hat.
Testen Sie abschließend an 10 kürzlich bearbeiteten Items und passen Sie an. Nehmen Sie 10 fertige oder aktive Items aus den letzten Wochen und ordnen Sie jedem Item für jeden Zeitpunkt einen Status zu. Wenn Sie oft streiten, überlappen sich Ihre Labels. Wenn Sie ein Item nicht zuordnen können, fehlt ein Status oder zwei Ideen sind in einem Status vermischt.
Nach der Sitzung veröffentlichen Sie die Definitionen an einem Ort und sorgen dafür, dass die Labels überall übereinstimmen, wo Leute sie sehen.
Wenn ein Status auf Web etwas anderes bedeutet als auf Mobile, verlieren Leute das Vertrauen. Sie fangen an, im Chat nachzufragen, Details nachzuprüfen oder eigene „echte Status“ in Kommentaren zu erstellen. Der Zweck von Workflow-Statusbezeichnungen ist gemeinsame Wahrheit, nicht Dekoration.
Behandeln Sie den Status als ein gemeinsames Feld mit einer Quelle der Wahrheit. Dasselbe Label sollte überall mit derselben Schreibweise, Groß-/Kleinschreibung und Bedeutung erscheinen: Listen, Detailansichten, Benachrichtigungen, Exporte und Push-Nachrichten.
Mobile Bildschirme bestrafen lange Namen und schwaches visuelles Design. Ein Status, der auf dem Desktop in einer Tabelle gut aussieht, kann auf dem Telefon zu einem abgeschnittenen, verwirrenden Badge werden.
Auch die Platzierung zählt. Platzieren Sie den Status in der Detailansicht nahe am Titel, damit er vor der kompletten Beschreibung gesehen wird. In Listenansichten zeigen Sie ihn immer an derselben Stelle.
Barrierefreiheit hilft allen. Farbe ist ein Hinweis, nicht die Botschaft. Zeigen Sie immer das Textlabel und ziehen Sie ein einfaches Icon in Betracht (z. B. ein Häkchen für Erledigt), damit Personen mit Screenreadern oder Farbsehschwächen die Bedeutung schnell erfassen.
Status driften, wenn sie aufhören zu bedeuten „wo die Arbeit ist“ und anfangen zu bedeuten „wie Leute zur Arbeit stehen“. Dann wirkt das Board beschäftigt, aber niemand vertraut ihm.
Eine Ursache sind zu viele Labels für jeden kleinen Schritt. Wenn eine Aufgabe sich dreimal in einer Stunde bewegt, hören Leute auf, sie zu aktualisieren, oder sie wählen einen „nah genug“ Status. Eine kleine Auswahl funktioniert am besten, wenn jede Bewegung eine echte Änderung in Bereitschaft oder Verantwortung darstellt.
Ein weiterer Drift-Punkt ist das Mischen verschiedener Dimensionen in einem Feld. Priorität und Dringlichkeit sind wichtig, gehören aber in separate Felder, nicht in den Status. Wenn „Dringend" ein Status ist, konkurriert er mit „Zur Prüfung" und Ihr Reporting wird wenig aussagekräftig.
Achten Sie auf diese Muster:
Um Drift zu verhindern, setzen Sie einen Besitzer für das Status-Set und machen Änderungen selten. Wenn Sie etwas ändern, notieren Sie, was sich geändert hat, warum und was ersetzt wurde.
Ein Kunde schreibt an den Support: „Auf dem Handy zeigt die Bestellhistorie eine leere Ansicht, obwohl ich Bestellungen habe." Support legt ein Item an, das zu einem Produktfix und später einem Release wird.
Neu: Support erfasst Screenshots, Gerätedetails und wie „korrekt" aussehen sollte.
Triagiert: Der Product Owner bestätigt, dass es ein echter Bug ist, bestimmt die Zugehörigkeit (Mobile App, nicht Backend) und klärt die Auswirkung.
Bereit: Reproduktionsschritte sind bestätigt und Abnahmekriterien sind klar.
In Bearbeitung: Ein Entwickler reproduziert das Problem, findet, dass die API Daten liefert, der Screen sie aber falsch filtert, und beginnt mit der Behebung.
Blockiert: Der Entwickler entdeckt, dass die UI ein Feld von älteren Accounts braucht und ein Backend-Change nötig ist. Das Item wird mit einer klaren Notiz markiert: „Blocked: Backend benötigt Legacy-Feld-Mapping."
Zur Prüfung: Nachdem die Abhängigkeit gelöst ist, prüft QA iOS und Android und verifiziert, dass die leere Ansicht nur dann angezeigt wird, wenn wirklich keine Bestellungen vorhanden sind.
Erledigt: Der Fix ist freigegeben und deployed (oder für das nächste Releasefenster eingeplant, je nachdem, was Ihr Team als erledigt definiert). Support bestätigt, dass es live ist und antwortet dem Kunden.
Beachten Sie, was Verwirrung vermeidet: „Blockiert" hat einen Grund und eine nächste Aktion, und die Zuständigkeit springt nicht herum. Jeder kann das Item öffnen und sehen, wer den Ball hat.
Wenn Ihr Board unordentlich wirkt, finden Sie meist innerhalb von 10 Minuten den Grund.
Gehen Sie das Board durch und achten Sie auf diese Signale:
Wenn Leute sich nicht einig sind, wo eine Karte hingehört, überlappt ein Status mit einem anderen oder ist nicht ausreichend definiert.
Öffnen Sie denselben Workflow auf einem Telefon und prüfen Sie, ob die Labels auch in engen Flächen funktionieren.
Statussysteme bleiben nützlich, wenn Sie sie wie ein Regelwerk behandeln: stabil, aber überprüfbar. Ziel ist nicht ständige Änderung, sondern konsistente Nutzung.
Setzen Sie eine leichte Kadenz, z. B. eine 30-minütige monatliche Überprüfung mit je einer Person aus jeder Rolle, die das Board berührt. Bringen Sie 5–10 aktuelle Items mit und suchen Sie nach Ausnahmen, die Sie beheben können.
Ein paar einfache Signale, die sich lohnen zu tracken:
Wenn sich etwas falsch anfühlt, widerstehen Sie der Versuchung, sofort einen neuen Status hinzuzufügen. Fügen Sie einen Status nur hinzu, wenn der neue Zustand wirklich anders ist, das nächste Verhalten der Leute ändert und oft vorkommt. Meist ist die Lösung einfacher: die Definition straffen, eine Eintrittsregel hinzufügen oder die Zuständigkeit klären.
Wenn Sie den Workflow in ein internes Tool einbauen, behandeln Sie Status als gemeinsame Daten, nicht als bildschirmspezifischen Text. In AppMaster (appmaster.io), zum Beispiel, können Sie das Statusfeld einmal im Data Designer definieren und in Web- und nativen Mobil-Apps wiederverwenden, was hilft, das Problem „auf meinem Telefon bedeutet es etwas anderes" zu verhindern.
Wie viele Workflow-Status sind gut für ein Team?Beginnen Sie mit 5–7 Status, die dem normalen Ablauf entsprechen: zum Beispiel Neu, Bereit, In Bearbeitung, Zur Prüfung, Blockiert und Erledigt. Jeder Status sollte genau eine klare Bedeutung haben — vermeiden Sie, Status für Priorität oder persönliche Notizen zu verwenden.
Woran erkenne ich, ob eine Statusbezeichnung wirklich „klar“ ist?Ein Status sollte jemandem sagen, was gerade wahr ist und was als Nächstes passiert, ohne Rückfrage. Wenn ein Label nicht den nächsten Besitzer, die nächste Aktion oder eine klare Wartebedingung impliziert, ist es zu vage.
Sollen wir „Warten“ oder „Blockiert“ verwenden?Verwenden Sie „Blockiert“, wenn die Arbeit wegen einer konkreten Abhängigkeit nicht weitergehen kann, und nennen Sie die Abhängigkeit im Ticket (zum Beispiel „Blocked: Kundenantwort“). „Warten“ ist meist zu unspezifisch, weil es verschleiert, worauf gewartet wird und wer handeln soll.
Was sollte „Bereit“ in der Praxis bedeuten?„Bereit“ bedeutet praktisch: Das Element kann sofort begonnen werden, es fehlen keine Informationen oder Zugänge. Wenn noch Anforderungen, Zugänge oder Entscheidungen fehlen, ist es noch nicht „Bereit“.
Wie verhindern wir, dass „In Bearbeitung“ zur Ablage wird?„In Bearbeitung“ darf nur aktives Arbeiten bedeuten, nicht „jemand hat es sich kurz angeschaut“ oder „es ist nur zugewiesen“. Wenn etwas geparkt ist, auf Input wartet oder an einer Abhängigkeit hängt, verschieben Sie es zu „Blockiert“ oder zurück in einen Vor-Arbeits-Status.
Brauchen wir wirklich Ein- und Austrittsregeln für Status?Schreiben Sie einen Satz pro Status: was muss wahr sein, um einzutreten, und was muss wahr sein, um zu verlassen. Kurz, lesbar und als gemeinsame Regel für alle, die mit dem Workflow arbeiten.
Wie halten wir Statusbedeutungen zwischen Web und Mobile konsistent?Treffen Sie eine Entscheidung für eine kanonische Menge von Statuswerten und nutzen Sie dasselbe Feld überall: Web, Mobile, Benachrichtigungen und Exporte. Wenn Bildschirme Status umbenennen oder anders anordnen, verliert das System Vertrauen und die Leute erfinden eigene Bedeutungen.
Welche Tipps zur Benennung sind auf Mobilgeräten besonders wichtig?Halten Sie Labels kurz, idealerweise ein bis zwei Wörter, damit sie in Listenansichten nicht abgeschnitten werden. Achten Sie darauf, dass der Text alleine die Bedeutung trägt — Farbe kann fehlen oder anders angezeigt werden.
Was ist der schnellste Weg, um die Status mit dem Team neu zu gestalten?Wählen Sie ein typisches Item und verfolgen Sie, was tatsächlich passiert — von der Anfrage bis zur Fertigstellung, inklusive Wartezeiten. Doppelte Labels zusammenführen, vage Begriffe in handlungsorientierte Begriffe umbenennen, Ein-/Austrittsregeln hinzufügen, Standardverantwortliche festlegen und das Set an 10 kürzlich abgeschlossenen Items testen.
Wie kann ein No-Code-Tool helfen, dass Status im Laufe der Zeit nicht auseinanderdriften?Behandeln Sie den Status als gemeinsame Datenquelle, nicht als bildschirmspezifischen Text, damit jede Oberfläche dieselben Werte zieht. In AppMaster (appmaster.io) können Sie zum Beispiel ein einzelnes Statusfeld im Datenmodell definieren und in Web- und nativen Mobil-Apps wiederverwenden, um die Drift zwischen den Bildschirmen zu reduzieren.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
