You set up sprints in monday.com through monday dev, not standard work management. Install monday dev, open the Tasks board it creates, click the arrow beside New Task, choose New Sprint, set dates and goals, then drag backlog items in. Enable automatic start and complete under Sprint setup so burndown and reporting actually work.
I have moved a few engineering teams onto monday dev, usually off spreadsheets or an overloaded Jira instance, and the setup itself takes under an hour once you go in the right order. The mistakes are almost never in creating the sprint. Teams pick the wrong monday product, break the solution folder, or misconfigure what happens to unfinished work at sprint close. This guide walks the setup and those traps, using monday’s own current documentation.
Decide first: monday dev or monday work management
Sprints live in monday dev. Since monday.com split its platform into separate products, work management has no sprint object: no start and complete lifecycle, no burndown chart, no velocity tracking. You can fake sprints in work management with groups named “Sprint 14” and a status column, and plenty of teams do, but you are rebuilding by hand what monday dev ships preconfigured. And per monday’s own sprint management documentation, sprint automation templates are only available on monday dev boards and are not supported anywhere else, so your imitation will never automate a sprint start, completion, or rollover.
My rule: if your team estimates work, commits to iterations, and reviews velocity, buy monday dev. If you just want a task list grouped into two-week blocks, work management is fine and you can stop reading here.
| Capability | monday dev | monday work management |
|---|---|---|
| Sprint lifecycle (start, complete, active indicator) | Yes, from the Standard plan | No; manual groups only |
| Burndown chart per sprint | Yes, on automated sprints | No |
| Velocity and planned vs. unplanned charts | Yes, via Agile Insights (Pro plan) | No |
| Estimated SP and Actual SP columns | Preconfigured on the Tasks board | Build your own Numbers columns |
| Sprint automation templates | Yes, on dev boards only | Not supported |
Plans and what sprints actually cost
Per monday dev’s pricing page, annual billing runs $9 per seat per month on Basic, $12 on Standard, and $20 on Pro, with a 3-seat minimum and Enterprise on a custom quote. The line that matters: sprint management sits on the Standard tier, not Basic. Standard is also where you can build a dashboard that combines up to 5 boards. Pro raises the ceiling to time tracking, agile reporting, and dashboards spanning up to 10 boards, and it is the tier that carries Agile Insights.
Two budgeting notes. Seats are sold from a 3-seat floor and in fixed tiers rather than one user at a time, so a team of twelve rounds up to the next tier and pays for the empty seats. And the 5-board dashboard cap on Standard bites the moment you run more than a handful of squads, each on its own Tasks board, and want one program-level rollup. If that is your situation, price Pro from the start rather than discovering the wall later.
Set up your first sprint in monday dev
- Install monday dev. The Tasks board is created automatically on a new dev account. If you deleted it or want a second one, click + in the left pane, select Dev templates, then Scrum Team, which adds the whole solution folder including the Tasks board.
- Open the Tasks board. Each group here is a sprint: one group holds the backlog of unassigned tasks, and the active sprint carries an active-indication bar. Do not restructure these groups into something else.
- Load your backlog. Create an item per task and fill in the Owner, Estimated SP (story points), and Status columns, and connect each task to an epic through the Epic column if you want roadmap reporting later.
- Click the drop-down arrow beside the New Task button and select New Sprint.
- In the pop-up, name the sprint, set start and end dates, and record the sprint goals. Click Create Sprint. It appears as the top group on the board, with its tasks linked automatically through the Connect Boards column.
- Drag tasks from the backlog group into the new sprint group. Watch the Estimated SP group summary as you go so you commit to a realistic total rather than an optimistic one.
- Click the three-dot menu on the sprint group header and open Sprint setup. Toggle on Enable automatic Sprint start and complete, then set the current sprint’s Complete time and the next sprint’s Start time. The current sprint must complete before the next one begins.
- In that same menu, choose what happens to leftover tasks at completion: keep them in the completed sprint, move them to the next sprint, or move them to the backlog. You can also leave the auto-generated sprint summary toggled on here.
- Let the automation start the sprint at the scheduled time. During the sprint, track progress with the Performance button (shown as Burndown on some boards) beside the sprint’s status bar, or switch to Kanban view and filter it by sprint for stand-ups.
- At the end date the sprint completes on its own and monday generates the sprint summary. Review it, run your retro, and the next sprint starts on the schedule you set in step 7. If no upcoming sprint is queued, monday creates a fresh one automatically.
The manual-start trap and other rollover gotchas
There is a Start button on every sprint group, and pressing it feels natural. Don’t. Monday’s documentation is explicit: if you start and complete a sprint manually, you lose access to the automated features, including the auto-generated sprint summary, the burndown chart, and Agile Insights. Start a sprint by hand and you have quietly switched off most of what you are paying monday dev for. Configure automatic start and complete in Sprint setup even if the automation fires five minutes after you would have clicked the button yourself.
On rollover, of the three leftover-task options I set new teams to move to backlog, not move to the next Sprint. Auto-forwarding unfinished work pre-fills the next sprint before planning happens, which turns planning into rubber-stamping and hides chronic over-commitment. Forcing spillover back through the backlog makes the team consciously re-commit to it, and it keeps your planned vs. unplanned data honest.
Two more constraints worth knowing before they bite. You can only delete a sprint that has not started yet; sprints in progress or completed cannot be deleted at all, which protects your velocity history. And if you delete an unstarted sprint that still holds incomplete items, monday prompts you to relocate them and confirm with Move tasks and delete, so nothing is silently lost.
Do not touch the solution folder
The monday dev solution is four connected boards: Tasks, Sprints, Epics, and a hidden Capacity board that powers sprint capacity planning. They are wired together with Connect Boards columns that each store a specific board ID, so a broken connection breaks sprint management with it. Monday’s docs are blunt here: duplicating or copying individual boards out of the solution folder produces broken connections that cannot be repaired without developer intervention, and deleting the solution folder permanently destroys the hidden Capacity board, which cannot be recovered from the trash. Build the solution only through the official monday dev setup flow.
The Tasks board also has columns that cannot be deleted because the workflow depends on them: Owner, Status, Priority, Type, Estimated SP, Actual SP, Sprints, Epic, and Bugs Queue. Everything else is fair game to customize. Since granular board permissions are an Enterprise feature, on Standard or Pro you cannot technically stop a well-meaning admin from “cleaning up” the structure, so brief anyone with member access before they find the folder. If you are planning capacity across sprints too, the same discipline applies to workload data; our monday.com workload management setup guide covers that side in detail.
Reporting: burndown, velocity, and dashboards
The burndown chart tracks a sprint’s progress against plan by work days, hours, or story points, and it works on both active and completed sprints, provided they ran on automatic start and complete. The green dashed line is the ideal burn rate; the blue line is remaining estimated effort. Agile Insights, a board view on the dev Tasks board, adds a velocity chart and a planned vs. unplanned chart, and monday gates it to the Pro plan. Dashboards then aggregate across boards, capped at 5 boards on Standard, 10 on Pro, and 50 on Enterprise. That 5-board cap is the one that surprises people running multiple squads. For contrast on how far dashboard-driven agile reporting goes in a competing tool, see our ClickUp dashboards setup guide.
Where monday dev lags Jira and Linear
Being honest about the ceiling: monday dev’s backlog is a board group, nothing more. There is no ranked backlog view, no estimation workflow beyond typing numbers into a column, and nothing close to Jira’s JQL for querying issues across projects. The sprint automations menu still ships a single template, per monday’s own docs, with more promised. For an active dev team, the automation and integration action limits on Standard are also tight; a busy GitHub sync eats into them faster than the pricing page suggests, which pushes you toward Pro sooner than you planned.
The comparison that stings most is Linear, where cycles generate automatically on a cadence and unfinished issues roll forward without any per-board configuration. Monday makes you set sprint timing board by board. If iteration mechanics are the core of your workflow, read our guide to Linear’s cycle-based sprint planning before committing. Engineering-led teams that live in pull requests should also weigh Jira against GitHub Projects, since both keep sprints closer to the code than monday does.
Where monday dev earns its seat price is the mixed organization already running monday.com, where product, marketing, and support sit in the same workspace as engineering and non-technical stakeholders actually open the boards. That cross-functional visibility is the thing Jira and Linear are worst at, and it is the honest reason to choose monday dev despite the thinner agile mechanics. If your engineers are the only people who will ever touch the tool, that advantage disappears and you should look at Linear or Jira instead.
Common questions about monday.com sprints
Which monday dev plan includes sprint management?
Sprint management starts on the Standard plan at $12 per seat per month with annual billing, per monday dev’s pricing page. Basic, at $9 per seat, does not include the sprint lifecycle. Agile Insights, with the velocity and planned vs. unplanned charts, requires the Pro plan at $20 per seat per month.
Can I run sprints in monday work management without monday dev?
Only by imitation. You can name groups after sprints and add your own story point columns, but there is no sprint lifecycle, burndown chart, velocity reporting, or automatic rollover, and monday’s sprint automation templates are not supported outside dev boards. Teams that estimate work and review velocity should use monday dev.
What happens to unfinished tasks when a sprint ends?
You choose in Sprint setup: keep them in the completed sprint, move them to the next sprint, or move them to the backlog. The setting applies at automatic completion. I recommend moving spillover to the backlog so the team consciously re-commits during planning instead of inheriting a pre-filled sprint.
Why is my burndown chart or sprint summary missing?
Almost always because the sprint was started or completed manually with the Start and Complete buttons. Monday only generates the burndown chart, the auto sprint summary, and Agile Insights for sprints running on automatic start and complete, which you enable per board under Sprint setup.
Can I delete a sprint in monday dev?
Only if it has not started yet. Sprints in progress or completed cannot be deleted, which protects your velocity history. When you delete an unstarted sprint that still holds incomplete items, monday asks where to move them and you confirm with Move tasks and delete, so tasks are never silently discarded.
