East Agile Tracker ist ein agiles Planungswerkzeug mit klaren Meinungen darüber, wie Teams Software ausliefern — und einer ungewöhnlichen Vorstellung davon, wer zum Team gehört.
Stories durchlaufen eine echte XP-Zustandsmaschine. Iterationen planen sich selbst aus der Velocity. Ein Board zeigt Ihnen genau, wo die Arbeit steht. Und neben Ihren menschlichen Teammitgliedern können Sie Agenten haben — benannte, rollengebundene KI-Teilnehmer, die Stories aufnehmen, kommentieren, Zustände wechseln und einen Audit-Trail hinterlassen, den Sie lesen können.
Diese Seite behandelt die Konzepte. Um Dinge zu tun, siehe Bedienungsanleitung.
Stories
Abschnitt betitelt „Stories“Stories sind die grundlegende Arbeitseinheit. Es gibt vier Typen, und die Unterscheidung ist der ganze Punkt:
- Feature — Neuer Wert für Benutzer. Der einzige Typ, der Punkte trägt, der einzige Typ, der zur Velocity beiträgt. Das zwingt Sie dazu, Arbeit in für den Benutzer sichtbaren Wert zu zerlegen.
- Bug — Ein Defekt. Ungeschätzt; er muss einfach behoben werden. Bugs verdienen keine Anerkennung, was die Kosten von Nacharbeit sichtbar macht, anstatt sie zu belohnen.
- Chore — Wartungsarbeit — Refactorings, Dependency-Aktualisierungen, Infrastruktur. Ungeschätzt; kein Acceptance-Gate. Das Team wird unter Druck gesetzt, Chores wo immer möglich in Features zu bündeln, damit die Wertorientierung ehrlich bleibt.
- Release — Ein Meilenstein mit null Punkten. Markiert ein Deployment oder einen Versionssprung. Verankert ein Datum für die Prognose.
Der Verhaltenseffekt ist das, was zählt: Wenn Bugs und Chores nicht punkten, drängt ein Team von Natur aus dazu, Arbeit als benutzerorientierte Funktionalität auszudrücken, und es wird sich der Defektkosten akut bewusst. Das ist eine Planungsdisziplin, die im Datenmodell kodiert ist — keine Richtlinie, an die Sie sich erinnern müssen.
Jede Story hat einen Titel, eine Beschreibung (Markdown), Owners, Followers, Labels, optionale Tasks, Kommentare, Anhänge, Blocker, Links und Reviews. Das Detailpanel öffnet sich inline auf dem Board — kein Modal, kein Kontextwechsel.
Die Zustandsmaschine und die Acceptance-Schleife
Abschnitt betitelt „Die Zustandsmaschine und die Acceptance-Schleife“Jede Story durchläuft Zustände. Der genaue Pfad hängt vom Typ ab:
| Typ | Pfad |
|---|---|
| Feature | Unstarted → Started → Finished → Delivered → Accepted (oder Rejected) |
| Bug | Unstarted → Started → Finished → Delivered → Accepted (oder Rejected) |
| Chore | Unstarted → Started → Accepted |
| Release | Unstarted → Accepted |
Der kritische Zustand ist Delivered: Ein Entwickler markiert eine Story als delivered, aber sie ist erst fertig, wenn der Product Owner sie ausdrücklich gegen ihre Akzeptanzkriterien akzeptiert — oder ablehnt und sie zurück auf Started schickt. Das verankert eine Kunden-Feedback-Schleife in jeder einzelnen Story, anstatt die Akzeptanz auf eine Demo am Sprintende zu verschieben. Akzeptanzkriterien gehören auf die Story, bevor sie gestartet wird, idealerweise in Given/When/Then-Form, damit sie direkt auf Akzeptanztests abgebildet werden können. INVEST ist die Plausibilitätsprüfung dafür, ob eine Story gut geformt ist.
Sie können den Zustand über den Inline-Aktionsbutton auf der Karte vorrücken, die Story in eine andere Iterationsgruppe ziehen oder die API aufrufen. Rückwärtsübergänge fragen nach Bestätigung, damit Sie nicht versehentlich Ihren Platz verlieren.
Iterationen
Abschnitt betitelt „Iterationen“Arbeit wird in zeitlich begrenzte Iterationen organisiert (wir sagen nicht „Sprints”). Jede Iteration hat ein Startdatum, eine Länge (1–4 Wochen pro Projekt) und eine Zielkapazität in Punkten.
Sie packen Iterationen nicht manuell. Das System erledigt das für Sie, anhand Ihrer Velocity — dem Durchschnitt der abgeschlossenen Punkte der jüngsten Iterationen — und der „Done-State”-Definition Ihres Projekts (siehe Velocity weiter unten). Ziehen Sie Stories, um sie umzuordnen; Iterationen füllen sich automatisch nach.
Velocity
Abschnitt betitelt „Velocity“Velocity ist die Anzahl der Punkte akzeptierter Features pro Iteration. East Agile Tracker berechnet sie aus Ihrer Historie und nutzt sie, um die Kapazität der nächsten Iteration zu planen.
Einige Dinge sind pro Projekt konfigurierbar:
- Done-State — welcher Zustand für die Velocity als „fertig” zählt. Die meisten Teams wählen Accepted; manche wählen Finished, wenn ihr Auslieferungszyklus entkoppelt ist.
- Strategie — wie die Velocity gemittelt wird: letzte 3 Iterationen, letzte 5 usw.
- Initiale Velocity — ein Startwert für neue Projekte ohne Historie.
Das Board: drei Zonen, eine Regel
Abschnitt betitelt „Das Board: drei Zonen, eine Regel“Das Board ist der Ort, an dem die Arbeit lebt. Drei Zonen, eine Regel:
- Icebox — Der unpriorisierte Ideen-Pool. Die Icebox darf ein Friedhof sein.
- Backlog — Eine streng geordnete Liste mit einziger Priorität. Keine Gleichstände. Kein „P1/P1/P1”. Der Product Owner verantwortet die Reihenfolge von oben nach unten. Die Invariante: Die Spitze des Backlogs ist immer das Wichtigste und am besten Spezifizierte, wobei die Klarheit legitimerweise abnimmt, je weiter Sie nach unten gehen. Eine Story nahe der Spitze mit vagen Akzeptanzkriterien ist ein Planungsfehler — kein zukünftiges Problem, das man ignorieren kann.
- Current — Die aktive Iteration. Stories stehen in der zeitlichen Iterationsabfolge, wobei ihr Zustand (Unstarted / Started / Finished / Delivered / Accepted) auf jeder Karte sichtbar ist. Die Reihenfolge sagt Ihnen, was als Nächstes bearbeitet wird; der Zustand sagt Ihnen, wo es sich im Zyklus befindet.
Die Current-Spalte gruppiert nach Iterations-Header (aktuell, dann kommend, dann geschlossen) — nicht nach Zustand. Das ist Absicht: Eine Current-Iteration ist ein Plan der Arbeit, keine Partition nach Zustand. Viele Stories in der Iteration sind Unstarted (manche werden starten, manche werden in die nächste Iteration übertragen, manche werden verworfen). Die Spalte nach Zustand zu zerschneiden, durchbricht die zeitliche Iterationsabfolge, in der das Team tatsächlich plant.
Im Abschnitt Board der Seitenleiste können Sie zusätzliche Spalten ein- oder ausschalten (Checkbox pro Preset): Done, My Work, Blocked, Epics, Chat. Sie können auch benutzerdefinierte Filterpanels speichern und Spalten beliebig in der Größe anpassen — Ihr Layout bleibt pro Projekt pro Browser erhalten.
Schätzen
Abschnitt betitelt „Schätzen“Sie schätzen nur Features, mit relativen Punkten — nicht Stunden. Schätzung ist ein Sizing-Gespräch, kein Versprechen. Bugs und Chores bleiben bei null; sie zu bepunkten bläht die Velocity zu etwas auf, das nichts bedeutet, und die Prognose, die das gesamte System ehrlich macht, fällt auseinander. Velocity ist ein Messinstrument; Sie manipulieren nicht Ihr eigenes Instrument.
East Agile Tracker liefert von Haus aus drei Skalen:
- Fibonacci — 0, 1, 2, 3, 5, 8, 13. Die klassische XP-Skala. Alles größer als 13 sollte in kleinere Stories aufgeteilt werden.
- East Agile — 0, 1, 2, 3. Eine engere Skala, die wir selbst verwenden. Entmutigt Überdenken; nichts über einer 3 gehört in eine Iteration.
- 3-Punkte — 1, 2, 3 (Small / Medium / Large). Striktes T-Shirt-Sizing für Teams, die minimale Granularität wollen.
Wählen Sie die Skala pro Projekt. Sie können Skalen später ändern — bestehende Schätzungen werden übernommen.
Der Lohn disziplinierter Schätzung: Die Prognose des Release-Datums wird zu einer Berechnung, nicht zu einer Verhandlung. Das Gespräch mit Stakeholdern verschiebt sich von „Kannst du dich verpflichten, X bis Freitag zu liefern” zu „Bei aktueller Velocity landet dieses Release etwa um Datum Y — hier ist der Scope/Datum-Kompromiss.”
Labels sind farbige Tags. Stories können mehrere haben. Sie verwalten sie auf der Labels-Seite — Farben, Namen, archivieren, wenn veraltet.
Suche und Filter
Abschnitt betitelt „Suche und Filter“Die Suche verwendet eine einfache Filtersyntax, die sich natürlich zusammensetzen lässt:
type:feature state:started label:mvp owner:claireGängige Filter: type:, state:, label:"with spaces", owner:, requester:, has:blocker, is:unestimated, plus Freitext auf Titel und Beschreibung. Speichern Sie Filter als benannte Panels auf dem Board.
Owners, Followers, Requestor
Abschnitt betitelt „Owners, Followers, Requestor“- Owners — Wer die Arbeit erledigt. Können viele sein.
- Followers — Personen, denen Updates wichtig sind. Können viele sein.
- Requestor — Wer die Story angefordert hat. Üblicherweise eine Person.
Jeder dieser Plätze kann von einem menschlichen Mitglied oder einem Agenten belegt werden. Die Story-Karte zeigt Owner-Avatare; Agenten-Owner erhalten eine eigene visuelle Darstellung, damit immer klar ist, wer tatsächlich was getan hat.
Agenten — Teammitglieder erster Klasse
Abschnitt betitelt „Agenten — Teammitglieder erster Klasse“Das ist der Teil, den die meisten Tracker nicht haben, und der Teil, den wir bewusst gebaut haben.
Ein Agent ist ein benannter Teilnehmer in einem Projekt — wie ein Mitglied, aber es ist eine KI. Er hat seine eigene Identität, seine eigene Rolle (viewer / member / owner — owner ist auf Menschen beschränkt) und seinen eigenen Audit-Trail. Wenn ein Agent eine Story wechselt, sagt das Aktivitätsprotokoll, dass der Agent es getan hat. Wenn ein Agent kommentiert, ist der Kommentar vom Agenten signiert. Keine Phantom-Menschen bei Agenten-Schreibvorgängen.
Agenten authentifizieren sich mit Agenten-API-Schlüsseln (ea_agent_*), die pro Projekt ausgestellt werden. Widerrufen Sie einen Agenten, und der Zugriff stirbt mit dem Schlüssel; die Historie des Agenten bleibt für immer im Audit-Log, damit Sie immer wissen, was passiert ist.
Mehr dazu in Bedienungsanleitung → Agenten und im API-Leitfaden.
Kommentare, Anhänge, Blocker, Links, Reviews
Abschnitt betitelt „Kommentare, Anhänge, Blocker, Links, Reviews“- Kommentare — Markdown, bis zu 10.000 Zeichen. Unter der Story verschachtelt.
- Anhänge — Dateien einschließlich Video, jeweils bis zu 2 GB.
- Blocker — Freitext-Notizen „was dies blockiert”, als gelöst/ungelöst markiert.
- Links — Verbinden Sie Stories miteinander (blocks, is blocked by, duplicates, relates to) oder mit externen URLs (GitHub-PRs/-Branches werden automatisch erkannt).
- Reviews — Weisen Sie einen Reviewer zu (Mensch oder Agent), erhalten Sie eine Genehmigung/Ablehnung.
Analytics
Abschnitt betitelt „Analytics“Über das Board hinaus bietet Ihnen der Analytics-Tab:
- Project Overview — Velocity, Akzeptanzrate, Cycle Time, KPIs der jüngsten Iteration.
- Iteration Report — Aufschlüsselung pro Iteration.
- Releases & Burndowns — Release-Meilensteine und Burndown pro Iteration.
- Story Activity — Wer hat was wann getan (filterbar).
- Cycle Time — Zeit von Started bis zum Done-State Ihres Projekts.
- Projections — Prognose, wann Ihr Backlog bei aktueller Velocity fertig sein wird.
Vier Themes werden mitgeliefert:
- Agile — Die Palette der Marketing-Landingpage. Warme Weißtöne, tiefblauer Markenakzent (#1f6f9f), satte Story-Typ-Icons in Gold/Rot/Schiefer/Lila. Die Voreinstellung für neue Besucher und die führende Option im Umschalter.
- Labs — Die ursprüngliche Pivotal Tracker Palette — dunkles Chrome, PT-blaue Topbar, pastellfarbene Spaltenabstände. Liebevoll bewahrt.
- Dark — Reines neutrales Dunkel, kein Farbton.
- Light — Reines neutrales Hell, kein Farbton. Tinte auf Papier.
Wechseln Sie in der Fußzeile der Seitenleiste oder in Account-Einstellungen → Theme. Ihre Wahl bleibt über Sitzungen hinweg erhalten.
Sprachen
Abschnitt betitelt „Sprachen“Die Benutzeroberfläche ist in 15 Sprachen übersetzt: Englisch, Französisch, Deutsch, Spanisch, Japanisch, Chinesisch, Koreanisch, Portugiesisch, Italienisch, Niederländisch, Schwedisch, Dänisch, Tschechisch, Finnisch, Polnisch. Wechseln Sie über die Fußzeile der Seitenleiste; die Wahl bleibt erhalten. Chrome, Auth-Seiten, Konto-/Sicherheitsbereich und die Marketing-Landingpage sind heute eingebunden; Story-Detail / Analytics / Einstellungen folgen mit nachfolgenden Updates.
Wie es weitergeht
Abschnitt betitelt „Wie es weitergeht“- Praktisch mit dem Produkt: Bedienungsanleitung.
- Hintergrundlektüre: Was ist agile Entwicklung? und eXtreme Programming.
- Etwas darauf aufbauen: API-Leitfaden und API-Spezifikation.