Wie ein 6-köpfiges Entwicklerteam Jira durch ein einfaches Scrum-Board ersetzte (und keine Sprints mehr verpasste)

Jira ist mächtig. Für ein sechsköpfiges Team, das ein SaaS-Produkt entwickelt, ist es aber auch ein erheblicher Overhead.

Ich habe in den letzten Jahren mit vielen kleinen Entwicklungsteams gesprochen und ständig taucht dasselbe Muster auf: Das Team hat Jira adoptiert, weil es Branchenstandard ist, zwei Wochen lang konfiguriert und dann festgestellt, dass es mehr Zeit mit dem Tool als mit der eigentlichen Arbeit verbringt. Sprint-Zeremonien wurden zu Jira-Admin-Sitzungen. Das Backlog wurde zum Friedhof. Stand-ups verwandelten sich in Statusberichte, weil niemand seit dem letzten Stand-up auf das Board geschaut hatte.

Dies ist die Geschichte davon, wie ein Team das Problem gelöst hat — und wie das Setup auf der anderen Seite aussah.

Das Problem: Tool-Komplexität bremste die Sprint-Dynamik

Bei dem betroffenen Team handelte es sich um eine Backend-orientierte Gruppe von sechs Personen: zwei Senior-Entwickler, zwei Mid-Level, einen QA und einen Teilzeit-PM. Sie entwickelten eine B2B-Datenplattform und arbeiteten in zweiwöchigen Sprints. Auf dem Papier war ihr Scrum-Prozess solide. In der Praxis:

• Sprint-Planung dauerte 90 Minuten, weil die Hälfte der Zeit darauf verwendet wurde, das richtige Jira-Projekt, Epic und den Ticket-Typ zu finden – bevor überhaupt etwas diskutiert werden konnte.
• Tickets verblieben tagelang im „In Bearbeitung“, weil das Aktualisieren vier Bildschirme durchklicken erforderte.
• Der PM verbrachte Freitagnachmittage damit, die Sprint-Reports manuell zu erstellen, weil die integrierten Dashboards entweder zu komplex waren oder kostenpflichtige Add-ons zur richtigen Konfiguration erforderten.
• Neue Teammitglieder mussten eine Woche herausfinden, wo was liegt, bevor sie zum Board beitragen konnten.

Das Tool war nicht kaputt. Es war nur für ein Team von sechzig, nicht sechs Personen gedacht. Und die mentale Belastung, jeden Tag bei jeder Aufgabe damit zu arbeiten, hat die Sprint-Disziplin unbemerkt untergraben.

Der Wechsel: Wonach sie suchten

Als das Team anfing, Alternativen zu prüfen, gab es drei Kriterien, an denen nicht gerüttelt wurde:

• Ein Board, das man auf einen Blick verstehen kann. Spalten für To Do, In Progress, In Review, Done. Sprint deutlich erkennbar. Kein Suchen nach Kontext.
• Docs direkt neben der Arbeit. Das Team erstellte viele technische Spezifikationen und Entscheidungsprotokolle. Diese mussten neben den entsprechenden Aufgaben liegen und nicht in einem separaten Confluence-Bereich, den niemand aktuell hielt.
• Schnelles Onboarding. Im Wechselmonat kam ein neuer Entwickler. Zwei Wochen Einarbeitung in das Tool waren zu viel.

Sie fanden, was sie brauchten, in Vaiz – genauer: in der Scrum-Board-Vorlage, die ihnen direkt am ersten Tag ein funktionierendes Sprint-Setup bereitstellte, ganz ohne Konfiguration.

Das Setup: Wie sie das Board konfigurierten

Die Basis bildete die Scrum-Vorlage. Bereits im Standard bietet sie ein Kanban-artiges Board mit Sprint-Gruppierung, Storypoint-Feldern für jede Aufgabe und Meilenstein-Tracking für die Release-Ziele.

Sie nahmen drei kleine Anpassungen vor:

• Eine 'Blockiert' Spalte hinzugefügt zwischen In Bearbeitung und In Überprüfung. Das Team hatte aus Erfahrung gelernt, dass blockierte Tickets sichtbar sein müssen, ohne mit aktiver Arbeit vermischt zu werden.
• Eigene Labels für Ticket-Typen erstellt: Feature, Bug, Technische Schulden und Spike. Dadurch wurde die komplexe Hierarchie der Ticket-Typen in Jira durch etwas ersetzt, das jeder sofort verstanden hat.
• Technische Spezifikationsdokumente direkt an die relevanten Tasks verknüpft. Entwickler konnten ein Ticket öffnen und die Spezifikation lesen, ohne das Tool wechseln zu müssen.

Die Sprintplanung verkürzte sich von 90 auf 45 Minuten. Nicht, weil sich die Arbeit geändert hatte, sondern weil der Aufwand bei der Nutzung des Tools weggefallen ist.

Das Ergebnis: Nach Drei Sprints 

Nach drei Sprints mit dem neuen Setup berichtete das Team von drei konkreten Veränderungen: 

• Die Sprintabschlussrate verbesserte sich. In ihren letzten vier Sprints mit Jira hatten sie im Durchschnitt 68 % der geplanten Story Points abgeschlossen. In den ersten drei Sprints mit Vaiz waren es 84 %. Der PM führte dies teilweise auf eine bessere Sprintplanung zurück (weniger Zeit für das Tool, mehr Zeit für das tatsächliche Abstecken) und teilweise darauf, dass das Board übersichtlich genug war, um Blocker frühzeitig zu erkennen.
• Der neue Entwickler arbeitete bereits am zweiten Tag am Board mit. Keine Einarbeitungssitzung nötig. Er schaute sich das Board an, hatte direkt alles verstanden und begann, Tickets zu verschieben.
• Die Freitagnachmittags-Reports fielen weg. Das Dashboard gab der PM in Echtzeit alle Informationen: Sprintstatus, offene Blocker, Meilensteinfortschritt – alles sichtbar ohne manuelles Zusammentragen von Daten.

Was Hat Den Unterschied Gemacht 

Die ehrliche Antwort ist: Vaiz hat nicht mehr Funktionen als Jira – hat es nicht, und für große Enterprise-Teams sind Jiras Möglichkeiten wirklich wertvoll. Der Unterschied für dieses Team war die Passform: Ein Tool, das Größe und Tempo der Arbeitsweise des Teams getroffen hat, ohne dass vieles, was nicht gebraucht wurde, erst wegkonfiguriert werden musste.

Das Setup mit den Dokumenten direkt an den Tasks war besonders hilfreich. In Vaiz kann man einen Task und ein Dokument im selben Fenster gleichzeitig öffnen – Spezifikation und Ticket sind also parallel sichtbar. Gerade für Backend-Teams mit viel technischem Kontext fiel so ein ständiger Reibungspunkt weg.

Testen Sie es mit Ihrem Team 

Wenn Ihr Team Scrum nutzt und der Aufwand für das Tooling den tatsächlichen Prozessnutzen übersteigt, lohnt es sich, ein vorkonfiguriertes Scrum-Board-Template für kleine agile Teams auszuprobieren. Die Einrichtung dauert weniger als zehn Minuten und verschafft ein funktionierendes Sprint-Board mit Story Points, Meilensteinen und Dokument-Verlinkung – alles sofort einsatzbereit.

Vaiz bietet eine 30-tägige kostenlose Testphase, keine Kreditkarte erforderlich. Das reicht, um einen kompletten Sprint zu fahren und zu prüfen, ob das Tool zu Ihrem Team passt.