Sprint Planning with monday Dev – the 2026 Deep Dive

Till Freitag30. April 20266 min Lesezeit

TL;DR: „Sprint planning in monday Dev works with three boards (backlog, sprint, roadmap), clear roles (PO, SM, Dev, stakeholder) and 5 core automations. Plus: a concrete weekly routine for planning, daily, review and retro."

— Till Freitag

Why sprint planning often fails

Sprint planning is where strategy meets reality. If planning is bad, the sprint fails before it starts. The most common problems:

Backlog is chaos: Nobody knows what comes next
Estimates are wishful thinking: Story points are guessed, not referenced
Tickets are black boxes: Acceptance criteria missing, Definition of Done unclear
Stakeholders are blind: PO and business only see at demo time
Tools get in the way: 4 tabs open for 1 sprint planning – velocity dies

This deep dive shows how monday Dev addresses all of this – with concrete setups we've rolled out across 50+ engineering teams.

The 3-board setup

We recommend three boards per squad in one workspace:

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

Each board has one clear purpose, no mixing.

Board 1: Backlog

Purpose: Refinement, prioritization, prep for next sprint.

Column	Type	Purpose
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	Connects to roadmap item
Owner	People	PO or Tech Lead
Acceptance Criteria	Long Text	"When... then..."
Sprint	Connect	Link to sprint board

Rule of thumb: Only items with status "Ready" qualify for next sprint.

Board 2: Sprint Board

Purpose: Current sprint execution, daily updates.

Column	Type	Purpose
Item	Name	Story / Task
Status	Status	To Do, In Progress, In Review, Done
Assignee	People	Who's working on it
Story Points	Numbers	Pulled from backlog
Sprint Day	Date	When moved to in-progress
GitHub PR	Link	Link to the PR
Blocker	Status	Yes / No
Time Spent	Time Tracking	Optional, for spillover analysis

Sprint groups in monday Dev: one board, one group per sprint (e.g. "Sprint 47", "Sprint 48"). Old sprint groups are never deleted – velocity history stays.

Board 3: Roadmap

Purpose: Strategic view across quarters, initiative tracking, stakeholder comms.

Column	Type	Purpose
Initiative	Name	Quarterly theme or 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	Backlog connection
Outcome	Long Text	Business goal, KPI
Risk	Status	Low, Medium, High

The role model

Clear roles are the prerequisite for good planning. Our standard for Scrum teams:

Product Owner (PO)

Owner of the backlog board
Defines acceptance criteria
Prioritizes before every refinement
Speaks with stakeholders during reviews

Scrum Master / Tech Lead

Owner of the sprint board
Moderates planning, daily, retro
Removes blockers
Maintains velocity dashboard

Engineers (Dev / QA)

Estimate effort together (planning poker)
Pull tickets into "In Progress"
Update status & GitHub PR links
Add short notes on blockers

Stakeholders (Business, Sales, Marketing)

Read-only on the roadmap board
Submit requests via "Stakeholder Inbox" board
Do NOT interfere directly in the sprint board

💡 Pro tip: Set stakeholder permissions in monday Dev to read-only. Prevents "drive-by tasks" mid-sprint.

Example workflow: one sprint week

Monday – Sprint Planning (90 min)

0–15 min: Define sprint goal

PO presents the sprint goal in one sentence
Example: "We ship the new onboarding flow including email verification."

15–60 min: Story selection

Team walks through "Ready" stories from backlog
Effort gets estimated (planning poker) if still open
Stories get linked to sprint board via "Sprint" connect column
Capacity check: Sum(Story Points) ≤ velocity of last 3 sprints

60–80 min: Task breakdown

Complex stories get sub-items in monday Dev
Sub-items have owner & estimate

80–90 min: Commitment & risks

Team commits
Risks documented in "Sprint Notes" update

Tuesday to Thursday – Daily (10 min)

monday Dev's sprint board as single source of truth:

Each person: yesterday, today, blockers
Status updates happen live on the board (no "I'll update later")
Blockers get red status column → SM triggers resolution

Friday – Sprint Review + Retro (60 + 30 min)

Review (60 min):

Stories with status "Done" are validated against acceptance criteria
PO + stakeholders give feedback
monday Dev dashboard shows: burndown, velocity, spillover

Retro (30 min):

Dedicated retro board: "What went well", "What didn't", "Action items"
Action items become tickets in next sprint immediately

The 5 core automations

These five automations deliver the most value – build them first:

1. Status-Driven Sprint Movement

When status changes to "In Progress" → set "Sprint Day" to today, notify Scrum Master.

2. PR linking

When a GitHub PR with PACTA-123 in the title appears → find item with ID 123, link PR URL automatically.

(Works natively via monday-GitHub integration.)

3. Blocker escalation

When status "Blocker = Yes" for > 24h → notify Scrum Master & PO in Slack channel #sprint-alerts.

4. Velocity auto-reporting

Every Friday 5pm → create weekly report with completed story points, spillover, cycle time → post to #squad-alpha-updates.

5. Definition-of-Done check

When status moves to "Done" but "Acceptance Criteria" column is empty → block status change, request update.

Measuring velocity & cycle time

monday Dev provides dashboards out of the box. These three are mandatory:

Sprint Burndown

Y-axis: remaining story points
X-axis: sprint days
Line should drop steadily to 0
Steep drops on the last day = classic spillover risk

Velocity (rolling 6 sprints)

Bar chart per sprint
Mean = realistic capacity for next planning
Downward trend? → discuss tech debt or team change

Cycle Time per story type

Bug: median should be < 3 days
Story: median should be < 5 days
Spike: hard-cap at 8 hours, otherwise re-cut

📊 Realistic value: Teams that look at these three dashboards weekly improve velocity by 15–30% in 8 weeks. Teams that don't, stagnate.

Common anti-patterns (and how monday Dev prevents them)

Anti-pattern	Symptom	Fix in monday Dev
Sprint stuffing	More stories than velocity	Capacity column with auto-sum vs. velocity
"I'll update later"	Sprint board never current	Daily on the board, not in Slack
Silent blockers	Stories stuck for 5 days	Auto-escalation after 24h
Ghost tickets	Status "Done" without PR	DoD check automation
Endless spikes	3-day research becomes 2 weeks	Hard cap + time tracking

Kanban instead of Scrum?

monday Dev also works for pure Kanban teams – with small adjustments:

No sprint board, instead a flow board with WIP limits per column
WIP limits enforced via automation ("if > 3 items in 'In Progress' → block new")
Cycle time matters more than velocity
Reviews are continuous, no fixed time

Hybrid setups (Kanban for maintenance + Scrum for features) work too – one workspace, two boards.

Setup checklist

Workspace per squad created
3 boards (Backlog, Sprint, Roadmap) configured
Column schema applied as per template (above)
Roles & permissions set (PO, SM, Dev, stakeholder)
5 core automations activated
GitHub integration installed
Slack channels #sprint-alerts & #squad-updates connected
Dashboards (burndown, velocity, cycle time) configured
First refinement meeting done with backlog
Sprint planning template linked as doc

Bottom line

Good sprint planning is not a tool problem, but the right tool is the difference between a 30% and 80% sprint success rate. monday Dev offers the right mix of structure, flexibility and automation – without the plugin overhead of Jira or the engineering bubble of Linear.

🚀 We set up sprint planning in monday Dev regularly – including board configuration, role workshop and automation build in a 2-week sprint. Book a free intro call.

Read more: