Sprint Planning mit monday Dev – der Deep-Dive für 2026

Warum Sprint Planning oft scheitert

Sprint Planning ist die Stelle, an der Strategie auf Realität trifft. Wenn Planning schlecht läuft, scheitert der Sprint, bevor er angefangen hat. Die häufigsten Probleme:

• Backlog ist Chaos: Niemand weiß, was als Nächstes kommt
• Schätzungen sind Wunschdenken: Story Points werden geraten, nicht referenziert
• Tickets sind Black Boxes: Acceptance Criteria fehlen, Definition of Done unklar
• Stakeholder sind blind: PO und Business sehen erst beim Demo, was passiert ist
• Tools sind im Weg: 4 Tabs offen für 1 Sprint Planning – Velocity stirbt

Dieser Deep-Dive zeigt, wie monday Dev all das adressiert – mit konkreten Setups, die wir in 50+ Engineering-Teams ausgerollt haben.

Das 3-Board-Setup

Wir empfehlen pro Squad drei Boards in einem Workspace:

┌─────────────────────────────────────────────────────┐
│  Workspace: Squad Alpha                             │
├─────────────────┬──────────────────┬────────────────┤
│  📋 Backlog     │  🏃 Sprint Board │  🗺️ Roadmap   │
│  (Refinement)   │  (Execution)     │  (Strategy)    │
└─────────────────┴──────────────────┴────────────────┘

Jedes Board hat einen klaren Zweck, kein Mix.

Board 1: Backlog

Zweck: Refinement, Priorisierung, Vorbereitung für nächsten Sprint.

Spalte	Typ	Zweck
Item	Name	Story / Task / Bug
Status	Status	New, Refined, Ready, Blocked
Type	Dropdown	Story, Bug, Spike, Tech Debt
Priority	Status	Critical, High, Medium, Low
Effort	Numbers	Story Points (Fibonacci: 1, 2, 3, 5, 8, 13)
Epic	Link	Verbindet zu Roadmap-Item
Owner	People	PO oder Tech Lead
Acceptance Criteria	Long Text	"When... then..."
Sprint	Connect	Verlinkung zum Sprint-Board

Faustregel: Im Backlog sind nur Items mit Status "Ready" für den nächsten Sprint kandidatur-fähig.

Board 2: Sprint Board

Zweck: Aktuelle Sprint-Execution, daily updates.

Spalte	Typ	Zweck
Item	Name	Story / Task
Status	Status	To Do, In Progress, In Review, Done
Assignee	People	Wer arbeitet daran
Story Points	Numbers	Übernommen aus Backlog
Sprint Day	Date	Wann ins Doing gewandert
GitHub PR	Link	Verlinkung zum PR
Blocker	Status	Yes / No
Time Spent	Time Tracking	Optional, für Spillover-Analyse

Sprint-Gruppen in monday Dev: ein Board, eine Gruppe pro Sprint (z. B. "Sprint 47", "Sprint 48"). Das alte Sprint-Board wird nie gelöscht – Velocity-Historie bleibt erhalten.

Board 3: Roadmap

Zweck: Strategische Sicht über Quartale, Initiative-Tracking, Stakeholder-Communication.

Spalte	Typ	Zweck
Initiative	Name	Quartalsthema oder Feature
Status	Status	Discovery, Building, Shipped, Cancelled
Quarter	Dropdown	Q1, Q2, Q3, Q4
Owner	People	PO / Product Lead
Squad	Dropdown	Alpha, Beta, Charlie ...
Linked Stories	Connect	zum Backlog
Outcome	Long Text	Geschäftsziel, KPI
Risk	Status	Low, Medium, High

---

Das Rollenmodell

Klare Rollen sind die Voraussetzung für gutes Planning. Hier unser Standard für Scrum-Teams:

Product Owner (PO)

• Owner des Backlog-Boards
• Definiert Acceptance Criteria
• Priorisiert vor jedem Refinement
• Spricht in Reviews mit Stakeholdern

Scrum Master / Tech Lead

• Owner des Sprint-Boards
• Moderiert Planning, Daily, Retro
• Räumt Blocker weg
• Pflegt Velocity-Dashboard

Engineers (Dev / QA)

• Schätzen Effort gemeinsam (Planning Poker)
• Pullen Tickets in "In Progress"
• Updaten Status & GitHub-PR-Links
• Schreiben kurze Notes bei Blockern

Stakeholder (Business, Sales, Marketing)

• Read-only auf Roadmap-Board
• Können Wünsche im "Stakeholder Inbox"-Board einreichen
• Greifen NICHT direkt im Sprint-Board ein

💡 Pro-Tipp: Setzt Stakeholder-Permissions in monday Dev so, dass sie zwar lesen, aber nicht schreiben können. Verhindert "Drive-by-Tasks" mitten im Sprint.

---

Beispiel-Workflow: Eine Sprint-Woche

Montag – Sprint Planning (90 Min)

0–15 Min: Sprint Goal definieren

• PO präsentiert das Sprint-Ziel in einem Satz
• Beispiel: "Wir liefern den neuen Onboarding-Flow inkl. E-Mail-Verifikation."

15–60 Min: Story-Selection

• Team geht "Ready"-Stories aus dem Backlog durch
• Effort wird (falls noch offen) im Planning Poker geschätzt
• Stories werden via "Sprint"-Connect-Spalte ins Sprint-Board verlinkt
• Capacity-Check: Sum(Story Points) ≤ Velocity der letzten 3 Sprints

60–80 Min: Task-Breakdown

• Komplexe Stories bekommen Sub-Items in monday Dev
• Sub-Items haben Owner & Estimate

80–90 Min: Commitment & Risiken

• Team committet sich
• Risiken werden im "Sprint Notes"-Update dokumentiert

Dienstag bis Donnerstag – Daily (10 Min)

monday Dev's Sprint-Board als Single Source of Truth:

• Jede:r erklärt: was gestern, was heute, was blockt
• Status-Updates passieren live im Board (nicht "ich update später")
• Blocker bekommen rote Status-Spalte → Scrum Master triggert Auflösung

Freitag – Sprint Review + Retro (60 + 30 Min)

Review (60 Min):

• Stories mit Status "Done" werden gegen Acceptance Criteria geprüft
• PO + Stakeholder geben Feedback
• monday Dev Dashboard zeigt: Burndown, Velocity, Spillover

Retro (30 Min):

• Eigenes Retro-Board: "What went well", "What didn't", "Action Items"
• Action Items werden direkt als Tickets im nächsten Sprint angelegt

---

Die 5 Kern-Automations

Diese fünf Automations holen den meisten Wert raus – baut sie als Erstes:

1. Status-Driven Sprint-Movement

Wenn Status auf "In Progress" wechselt → setze "Sprint Day" auf heute, benachrichtige Scrum Master.

2. PR-Verlinkung

Wenn GitHub PR im Format PACTA-123 im Titel auftaucht → finde Item mit ID 123, verlinke PR-URL automatisch.

(Funktioniert via monday-GitHub-Integration nativ.)

3. Blocker-Eskalation

Wenn Status "Blocker = Yes" für > 24h → benachrichtige Scrum Master & PO in Slack-Channel #sprint-alerts.

4. Velocity-Auto-Reporting

Jeden Freitag 17:00 → erstelle Wochenreport mit erledigten Story Points, Spillover, Cycle Time → poste in #squad-alpha-updates.

5. Definition-of-Done-Check

Wenn Status auf "Done" wechselt aber Spalte "Acceptance Criteria" leer ist → blockiere Status-Wechsel, fordere Update.

---

Velocity & Cycle Time messen

monday Dev liefert Dashboards out-of-the-box. Diese drei sind Pflicht:

Sprint Burndown

• Y-Achse: verbleibende Story Points
• X-Achse: Sprint-Tage
• Linie sollte gleichmäßig auf 0 fallen
• Steile Drops am letzten Tag = klassisches Spillover-Risiko

Velocity (rollende 6 Sprints)

• Säulendiagramm pro Sprint
• Mittelwert = realistische Capacity für nächstes Planning
• Trend nach unten? → Tech Debt oder Team-Wechsel diskutieren

Cycle Time pro Story-Typ

• Bug: Median sollte < 3 Tage sein
• Story: Median sollte < 5 Tage sein
• Spike: Hard-Cap bei 8 Stunden, sonst neu schneiden

📊 Realistischer Wert: Teams, die diese drei Dashboards wöchentlich anschauen, verbessern ihre Velocity in 8 Wochen um 15–30 %. Teams, die es nicht tun, stagnieren.

---

Häufige Anti-Patterns (und wie monday Dev sie verhindert)

Anti-Pattern	Symptom	Fix in monday Dev
Sprint-Stuffing	Mehr Stories als Velocity	Capacity-Spalte mit Auto-Sum vs. Velocity
"Ich update später"	Sprint-Board nie aktuell	Daily im Sprint-Board, nicht in Slack
Stille Blocker	Stories hängen 5 Tage	Auto-Eskalation nach 24h
Ghost-Tickets	Status "Done" ohne PR	DoD-Check-Automation
Endlose Spikes	3-Tage-Recherche wird 2 Wochen	Hard-Cap + Time Tracking

---

Kanban statt Scrum?

monday Dev funktioniert auch für reine Kanban-Teams – mit kleinen Anpassungen:

• Kein Sprint-Board, stattdessen ein Flow-Board mit WIP-Limits pro Spalte
• WIP-Limits werden via Automation enforced ("wenn > 3 Items in 'In Progress' → blockiere neue")
• Cycle Time wird wichtiger als Velocity
• Reviews sind kontinuierlich, kein fester Termin

Hybrid-Setups (Kanban für Maintenance + Scrum für Features) sind ebenfalls möglich – ein Workspace, zwei Boards.

---

Setup-Checkliste

• Workspace pro Squad angelegt
• 3 Boards (Backlog, Sprint, Roadmap) konfiguriert
• Spaltenschema gemäß Vorlage (oben) übernommen
• Rollen & Permissions gesetzt (PO, SM, Dev, Stakeholder)
• 5 Kern-Automations aktiviert
• GitHub-Integration installiert
• Slack-Channel #sprint-alerts & #squad-updates verbunden
• Dashboards (Burndown, Velocity, Cycle Time) eingerichtet
• Erstes Refinement-Meeting mit Backlog durchgeführt
• Sprint Planning Template als Doc verlinkt

---

Fazit

Gutes Sprint Planning ist kein Tool-Problem, aber das richtige Tool macht den Unterschied zwischen 30 % und 80 % Sprint-Erfolgsquote. monday Dev liefert die richtige Mischung aus Struktur, Flexibilität und Automation – ohne den Plugin-Overhead von Jira oder die Engineering-Bubble von Linear.

🚀 Wir setzen Sprint-Planning-Setups in monday Dev regelmäßig auf – inklusive Board-Konfiguration, Rollen-Workshop und Automation-Bau in einem 2-wöchigen Sprint. Erstgespräch buchen.

Weiterlesen:

• monday Dev: Das am meisten unterschätzte Dev-Tool 2026
• monday Dev vs. Jira – ehrlicher Vergleich
• monday Dev vs. Linear – wer gewinnt 2026?
• Von Jira zu monday Dev migrieren – der Schritt-für-Schritt-Leitfaden