Sprint-Board-App-Design

Northwind Sprint-Board

Dieses offizielle OpenDesign-Beispiel zeigt den Northwind Growth Squad in Sprint 38, Tag 6 von 10. Der Desktop-Arbeitsbereich stellt das Board in die Mitte und hält rechts eine Sprint-Pulse-Seitenleiste sichtbar, sodass operative Arbeit und zusammenfassender Kontext gemeinsam gelesen werden können.

Die obere Leiste legt den Rahmen fest, bevor die Karten beginnen: „NORTHWIND / GROWTH SQUAD“ steht neben „Sprint 38 · Day 6 of 10“. Search tickets, Filter und New liegen am gegenüberliegenden Rand. Diese Anordnung unterstützt den schnellen Übergang vom Erkennen des aktuellen Sprints zum Finden oder Hinzufügen von Arbeit und hält den Hauptbereich für den Aufgabenvergleich frei.

Eine Filterleiste trennt die Steuerelemente vom Aufgabeninhalt. Initialen der Mitglieder, die Labels Active sprint, Bug, Feature und Research sowie die Steuerungen Group · Status und Sort · Priority machen die beispielhafte Organisation des Boards explizit. Der Kompromiss ist die Dichte: Viele Optionen bleiben sichtbar, doch die beabsichtigte Gruppierung ist verständlich, ohne eine weitere Ansicht zu öffnen.

Auslastung und Blocker prüfen

Das Design eignet sich für Teams, die prüfen, was wartet, in Arbeit ist, im Review steckt oder erledigt ist. Die Karten folgen einem wiederkehrenden Aufbau: ein farbiges Band für den Arbeitstyp, ein Aufgabentitel, ein Avatar der verantwortlichen Person, eine Punkteschätzung und eine Issue-ID wie NW-241. Diese Wiederholung erlaubt es, unterschiedliche Arbeit zu vergleichen, ohne die Identität des Tickets zu verlieren.

Die Beispieldaten zeigen außerdem verschiedene Arten von Arbeit in einer Warteschlange. „Add empty-state illustration to onboarding step 2“ steht neben „Interview 5 new Enterprise admins about 2FA enforcement“, während „CSV export drops emoji from project names“ einen Defekt als eigene Klasse sichtbar macht. Die Typbänder unterscheiden Feature, Design, Research, Chore und Bug, doch der gemeinsame Kartenaufbau hält diese Kategorien vergleichbar.

Diese Anordnung begünstigt schnelles Überfliegen gegenüber detaillierter Ticketdiskussion. Ein Team sieht, dass der Research-Eintrag 5 Punkte trägt und das CSV-Export-Problem 1 Punkt, doch das Board erklärt weder Schätzregeln noch Akzeptanzkriterien. Diese Details bräuchten in einer Produktivanwendung eine tiefere Aufgabenansicht; sie liegen außerhalb des sichtbaren Designs.

Vom Board zum Sprint Pulse

Der Arbeitsbereich wird von links nach rechts über Backlog, In progress, In review und Done gelesen. Die angezeigten Badges lauten 5, 4, 3 und 6. Die ersten drei entsprechen der Zahl der sichtbaren Karten, doch Done enthält nur vier Karten trotz des Badges 6. Die Abfolge von links nach rechts unterscheidet die Workflow-Phasen weiterhin; die Abweichung in den Beispielzahlen sollte geklärt werden, bevor das Board als operative Datengrundlage dient.

Fortschrittsbalken erscheinen nur auf einigen In-progress-Karten, darunter TOTP enrollment UI in member settings, Recovery codes, Fix focus-trap regression in command bar und 2FA challenge step. Ihr Vorhandensein trennt aktive Arbeit visuell von Karten, denen lediglich ein Status zugewiesen ist. Da die Grafik nicht definiert, was der Balken misst, ist er als illustrativer Fortschrittshinweis zu lesen und nicht als verifizierte Abschlusskennzahl.

Die Seitenleiste wechselt den Maßstab von einzelnen Tickets zu einer beispielhaften Sprint-Zusammenfassung. Sie zeigt Completed 22 of 38 pts und listet Devon Park mit 9 Punkten, Mira Reddy und Priya Banerjee mit je 5 Punkten sowie Caleb Renner mit 3 Punkten. Diese Werte ergeben zusammen 22, doch die vier sichtbaren Done-Karten ergeben nur 11 Punkte. Die Quelle erklärt diesen Unterschied nicht, daher sollten Seitenleiste und Board nicht als abgeglichener Leistungsbericht behandelt werden.

Der letzte Block der Seitenleiste macht die Beziehung zwischen Status und Abhängigkeit explizit. „1 ticket needs unblock“ verweist auf NW-205, beschrieben als wartend auf eine Copy-Prüfung durch Brand, mit „Mention @Sasha or move it back to backlog“ als sichtbarer Handlungsanweisung. Neben dem Board ist die Abhängigkeit schwerer zu übersehen, auch wenn die Seitenleiste dauerhaft Platz belegt, der sonst den Aufgabenbereich verbreitern könnte.

Sichtbare Grenzen des Designs

Dieses Artefakt ist ein reines Design-Beispiel für eine Desktop-App mit illustrativen Namen, Zahlen, Aufgabeninhalten und Aussagen. Die Aufnahmen belegen die sichtbare Komposition, Labels, Farbcodierung, Reihenfolge und den Beispielzustand. Sie belegen weder einen angebundenen Produktivdienst noch dauerhafte Speicherung, funktionierende Suche, Filterung, Ticketerstellung oder Echtzeit-Updates.

Bei einer Adaption sollte die spezifische Beziehung zwischen den vier Workflow-Spalten und der Sprint-Pulse-Seitenleiste erhalten bleiben. Eine brauchbare Umsetzung bräuchte eine ausdrückliche Definition für Punktsummen, Fortschrittsbalken, Blocker-Aktionen und Statuswechsel, bevor sie als operative Daten präsentiert werden. Die Quelle zeigt den Schnittstellenvertrag klar genug, um diese Zustände zu prototypisieren, aber nicht genug, um zu behaupten, dass die Steuerelemente sie bereits ausführen.