ClickUp Sprints Not Working? Here’s How to Fix It (2026)

If ClickUp sprints are not working for your team, you are not alone — this guide covers every failure pattern I’ve seen in 30+ team deployments. After debugging ClickUp Sprints across agencies, software houses, and ops teams migrating off Jira, the same failure points appear repeatedly. Most of them aren’t obvious, and ClickUp’s own documentation glosses over the edge cases that cause the most pain. This guide cuts straight to each diagnosis and gives you the exact steps to resolve it. No filler, no generic “check your internet connection” advice.

ClickUp Sprints are genuinely powerful when configured correctly — flexible sprint durations, automated rollover, velocity charts, and direct integration with the broader task hierarchy. But they have enough configuration gotchas and confirmed bugs that teams regularly give up on them within the first two weeks. Don’t be that team. The fixes below cover every recurring failure pattern I’ve seen in 2026.

Before diving in, bookmark the official ClickUp Sprints introduction and the Create and Manage Sprints reference — useful for checking whether a behavior you’re seeing is documented or a bug.

Fix 1: ClickUp Sprints Not Working — ClickApp Not Enabled

This is the single most common cause of “ClickUp Sprints not working” — and the most invisible one. If the Sprints ClickApp is not activated for a Space, the entire sprint interface simply does not exist for members of that Space. No sprint panel, no Sprint Folder option, no backlog. Team members see nothing and assume ClickUp doesn’t support sprints at all.

The critical details: the Sprints ClickApp must be enabled per Space, not workspace-wide. It requires Workspace owner or admin permissions to toggle. Regular members cannot enable it themselves and may not even know the setting exists. If you’ve inherited a workspace setup from someone else, this is the first place to look.

Here’s exactly what to do:

1. Open the Space settings — Click the ellipsis (…) next to your Space name in the left sidebar, then select Edit Space, or click the Space name and choose Settings from the dropdown.
2. Navigate to ClickApps — In the Space settings panel, click the ClickApps tab. You’ll see a grid of available ClickApps for that Space.
3. Find and enable Sprints — Scroll or search for Sprints. Click the toggle to enable it. The toggle should turn purple/active.
4. Confirm at the right level — ClickApps can be set at Workspace level (applies everywhere) or overridden per Space. If Sprints is enabled workspace-wide but overridden off at the Space level, you’ll still see no sprints. Check both levels.
5. Refresh and verify — After enabling, do a hard refresh (Ctrl+Shift+R / Cmd+Shift+R). The Sprint Folder option should now appear when you right-click a List or Folder in that Space.
6. Repeat per Space — If your project spans multiple Spaces, you need to enable the ClickApp in each one. There is no single “enable for all spaces” button for per-Space ClickApps.

Once the ClickApp is active, you’ll see the sprint interface populate. If team members still can’t see sprint options after you’ve enabled it, have them sign out and back in — ClickApp changes occasionally require a fresh session to propagate.

Fix 2: Sprint Index Number Bug and the Workaround

This one caught dozens of teams off guard in late 2025 and persists into 2026. When creating a new sprint, ClickUp previously let you set the starting index number — so you could begin with “Sprint 1”, “Sprint 5”, or whatever your project required. That field was silently removed from the Create Sprint modal due to a confirmed ClickUp bug, leaving teams with no direct way to control where numbering starts.

Why does this matter? Teams migrating from another tool mid-project, or teams that accidentally created test sprints and deleted them, end up with sprint numbering that doesn’t match their project timeline. “Sprint 7” in ClickUp doesn’t match “Sprint 7” in the retrospective doc, and the confusion compounds over time.

The workaround is not elegant, but it works reliably:

1. Create a new Sprint Folder — Right-click your Space or the Folder where you want sprints to live. Select Create Sprint Folder. Give it a name. Do not use an existing Sprint Folder for this — the workaround requires starting fresh.
2. Delete all auto-generated sprints — ClickUp automatically creates a first sprint when you create a Sprint Folder. Right-click each auto-generated sprint and select Delete. Confirm deletion. Leave the Sprint Folder itself intact — only delete its auto-populated contents.
3. Create your first sprint manually — Click + Create Sprint (or + Add Sprint) inside the now-empty Sprint Folder. When you create the first sprint in a clean folder this way, ClickUp resets the internal index counter.
4. Set the sprint name to match your desired index — While the auto-index field is broken, you can manually name the sprint “Sprint 5” or whatever number you need. Subsequent sprints created via the folder will auto-increment from that point if using default naming.
5. Verify the index before adding tasks — Check that the sprint number displayed in the sidebar matches your expectation before you start moving tasks in. Re-doing this after tasks are assigned is significantly more painful.

This is a genuine product bug, not a configuration issue. Keep an eye on ClickUp’s changelog — the index field may be restored in a future release. In the meantime, the workaround above is the only reliable approach.

Fix 3: Sprint Settings Not Applying to Existing Sprints

Here’s a gotcha that blindsides teams who try to course-correct mid-project: changing sprint settings on an existing Sprint Folder only affects sprints created after the change. Existing sprints — regardless of whether they’re active, upcoming, or not yet started — are frozen with the settings they were created with.

The most common scenario: a team starts with 2-week sprints, then decides to switch to 1-week sprints after Sprint 3. They update the Sprint Folder settings. Sprint 4 through Sprint 8 (already auto-created by ClickUp when the folder was set up) remain at 2 weeks. The team is confused because the setting “clearly shows 1 week” but existing sprints don’t reflect it.

Diagnosis first: check whether the affected sprints were created before or after your settings change. If they were created before, the fix requires manual adjustment:

1. Open the Sprint Folder settings — Click the ellipsis (…) next to your Sprint Folder name and select Edit Sprint Folder.
2. Update duration, automation, and rollover settings — Make the changes you want applied going forward. Save.
3. Identify pre-existing sprints that need updating — These are any sprints that were auto-created when the folder was set up, before your settings change. They’ll show the old duration or automation rules when you click into them.
4. Edit each affected sprint individually — Right-click the sprint name → Edit Sprint. Manually update the start date, end date, and duration to match the new settings. There is no bulk-edit option for sprint dates.
5. Delete and recreate if the volume is too high — If you have 10+ future sprints with wrong settings, it’s often faster to delete all auto-created future sprints and let ClickUp regenerate them from the updated folder settings.
6. Document this behavior for your team — Add a note to your team’s sprint process doc explaining that settings changes are not retroactive. This prevents the same confusion from recurring every quarter.

For teams that rely heavily on sprint automations, this issue compounds with Fix 4 below. An automation rule that was never applied to an existing sprint will never trigger for that sprint, regardless of how the folder settings read today.

Fix 4: Sprint Automations Not Triggering at End of Sprint

ClickUp’s sprint automation options — auto-close completed tasks, roll over unfinished tasks, notify assignees — are genuinely useful. But they require a specific trigger condition that many teams miss: the sprint must be formally completed via the Sprint Actions menu. Simply letting the sprint end date pass in the calendar does not trigger automation rules.

Additionally, as covered in Fix 3, automations set up after a sprint was created won’t apply to that sprint. And automation rules that depend on task status require the correct statuses to be in place — ClickUp’s sprint automation is status-aware, not just date-aware.

1. Check sprint automation settings — Open the Sprint Folder settings. Under Sprint Automations, verify that rollover, close, and notification automations are toggled on. If they’re off, no automation will fire regardless of how you complete the sprint.
2. Complete the sprint via Sprint Actions — Navigate to the active sprint. Click the ellipsis (…) next to the sprint name → Complete Sprint (or End Sprint in some UI versions). This is the explicit action that fires automations. Do not rely on the end date alone.
3. Review status mappings — Automation rules for “move incomplete tasks to next sprint” rely on which statuses count as “incomplete.” In your Space settings, verify that your custom statuses are correctly mapped to the Done/Not Done categories ClickUp uses internally.
4. Check automation history — Go to Settings → Automations in the left sidebar. Click Activity or History to see a log of automation runs. If an automation shows as “triggered but failed,” the error message will identify whether it’s a permission issue, status mapping problem, or API error.
5. Confirm the sprint was created after automation rules were set — If the automation was added to the Sprint Folder after the current sprint was created, it won’t apply. Create a new sprint and test the automation end-to-end before your next sprint cycle begins.
6. For integration-triggered automations, check sync status — If your sprint automations push data to external tools, review our guide on ClickUp integrations not syncing to rule out connector issues.

If sprint automation notifications specifically are broken but the automations themselves are firing, check the notification layer separately. Our guide on ClickUp notifications not working covers the full notification stack.

Fix 5: Tasks Not Appearing in Sprint Backlog

You’ve set up a sprint, but when you look at the backlog, it’s empty — even though there are clearly tasks in the Space. Or tasks you assigned to a sprint disappear from view. This has several distinct causes, and the fix depends on which one you’re hitting.

The most common cause: tasks must live within the Sprint Folder’s hierarchy to appear in the sprint backlog by default. Tasks in a different Folder or List that haven’t been explicitly assigned to the sprint won’t show up — ClickUp’s backlog view is not a workspace-wide task aggregator out of the box.

1. Check task location vs. Sprint Folder hierarchy — The sprint backlog pulls tasks from Lists within the Sprint Folder. If your tasks are in a separate List outside the Sprint Folder, they won’t appear unless explicitly added to the sprint. Drag the List into the Sprint Folder, or use the Add to Sprint option on individual tasks.
2. Use “Add to Sprint” for tasks outside the folder — Right-click any task → Sprint → Add to Sprint → select the target sprint. The task will then appear in the sprint backlog even if it lives in a different List. This is the cleanest way to manage cross-folder sprint assignments.
3. Check active filters on the backlog view — The backlog view supports filters (assignee, status, priority, etc.). If a filter was applied and saved, it may be hiding tasks that don’t match the filter criteria. Click the Filter icon in the backlog view and clear all active filters.
4. Verify the sprint is set to “Active” — Tasks assigned to a sprint that is in “Upcoming” status won’t appear in the active backlog. Confirm the sprint has been started (click Start Sprint in the Sprint Actions menu).
5. Check if tasks have a “Sprint” custom field vs. being in a Sprint List — Some teams add a “Sprint” dropdown custom field to tasks as a workaround. Tasks with a sprint value in a custom field do not appear in the sprint backlog view — only tasks that are structurally within the sprint (via List assignment or Add to Sprint) do. These are two different systems and they don’t sync automatically.
6. Review subtask display settings — If the backlog appears to have far fewer tasks than expected, check whether subtasks are set to display. In the backlog view settings (gear icon), toggle Show subtasks and choose the display mode.

Fix 6: ClickUp Sprints Not Working — Velocity Not Calculating Correctly

Velocity charts are one of the most useful features in ClickUp Sprints — when they work. The most common complaint: “velocity shows zero” or “velocity looks way lower than what we actually completed.” The root cause is almost always the same: ClickUp only counts tasks with story point estimates in velocity calculations. Unestimated tasks are silently excluded.

Velocity in ClickUp = sum of story points on tasks marked “Done” within the sprint. If your team completes 40 tasks but only 15 have story points set, the velocity chart reflects only those 15 tasks’ worth of points. This isn’t obvious from the UI.

1. Enable the Story Points ClickApp — Before velocity can work at all, the Story Points ClickApp must be enabled in the same Space as your sprints. Go to Space Settings → ClickApps → enable Story Points. Without this, there’s no points field on tasks and velocity will always read zero.
2. Audit tasks for missing estimates — In the sprint backlog, switch to List view and add the Story Points column. Sort by Story Points ascending. All tasks with empty story points will surface at the top — these are excluded from velocity.
3. Establish a team norm for estimating before sprint start — Velocity only improves as a metric when estimation is consistent. Make it a rule that no task enters a sprint without a story point value. Use the sprint planning session to enforce this.
4. Verify “Done” status mapping — Velocity only counts tasks in a “Done” status category. If your team uses custom statuses like “Deployed” or “Shipped” that aren’t mapped to the Done category, those tasks won’t count. Go to Space Settings → Task Statuses and confirm your final statuses are set to the Done category (shown in green).
5. Check the velocity chart date range — The velocity widget on sprint dashboards defaults to showing the last N sprints. If the date range or sprint count is too narrow, older sprint data won’t appear, making velocity look inconsistent. Expand the chart range to see historical trends.
6. Account for partial completions — ClickUp does not support partial story point credit. A task that is 90% done but not in a Done status counts as zero velocity. For planning purposes, split large tasks into smaller ones that can be fully completed within a sprint.

For teams also tracking billable time within sprints, our ClickUp time tracking guide for 2026 explains how time entries relate to sprint data and where the two systems diverge.

Fix 7: Sprint Dashboard Showing Wrong Data

Sprint dashboards in ClickUp pull data from widgets — and widgets have their own source, filter, and date configuration that can drift out of sync with your actual sprint setup. Wrong data on a sprint dashboard is almost always a widget configuration problem, not a data integrity issue in the underlying tasks.

The most common symptoms: burndown chart not updating, sprint progress showing 0%, velocity widget stuck on an old sprint, or task count not matching what you see in the backlog.

1. Edit each widget and verify its data source — Click the pencil/edit icon on any widget. Check the Filter or Source settings. Many widgets default to “All Spaces” or a specific List that may no longer be where your sprint tasks live. Point the widget at the correct Sprint Folder or sprint-specific List.
2. Check the sprint date filter on widgets — Burndown and velocity widgets have a date range setting. If this is set to a fixed date range (e.g., “January 2026”) rather than “Current Sprint” or “Active Sprint,” the widget will stop updating when the sprint rolls over. Set it to a dynamic sprint-relative option where available.
3. Force a widget refresh — ClickUp dashboards cache widget data. Click the refresh icon on each widget or do a full page reload (Ctrl+Shift+R). If a widget shows stale data after a hard refresh, the data source configuration is the issue, not the cache.
4. Rebuild broken widgets from scratch — If a widget was configured against a sprint that was deleted or renamed, it may be pointing to a null source. Delete the widget and recreate it, selecting the correct sprint or Sprint Folder as the source.
5. Verify dashboard permissions — Dashboards shared with guests or external collaborators may show limited data based on permission levels. If a teammate reports seeing blank widgets that you see as populated, check their access level to the underlying Sprint Folder.
6. Use ClickUp Brain for dashboard anomaly analysis — If you’re on a plan with ClickUp Brain, you can ask it to summarize sprint progress directly from task data, bypassing the widget layer entirely. See our ClickUp Brain AI guide for how to use AI-assisted sprint analysis effectively.

For sprint planning workflows that involve visual mapping before tasks enter the sprint, our ClickUp Whiteboards visual planning guide shows how to connect whiteboard planning sessions directly to sprint task creation.

Fix 8: Sprint Not Rolling Over Unfinished Tasks

Automatic rollover is one of the most-requested sprint features — and one of the most commonly misconfigured. When a sprint ends, unfinished tasks should automatically move to the next sprint or a backlog. Instead, many teams find tasks stuck in the completed sprint with no clear path forward, or tasks that vanish from their current view.

The diagnosis tree here has three branches: rollover is not configured, rollover is configured but not triggered, or rollover is triggered but moving tasks to the wrong place.

1. Verify rollover is enabled in Sprint Folder settings — Open the Sprint Folder → ellipsis → Edit Sprint Folder. Under Sprint Automations, find the rollover setting (usually labeled “Move unfinished tasks to next sprint” or similar). Toggle it on. Confirm whether it’s set to move tasks to “Next Sprint” or “Backlog” — choose based on your workflow.
2. Confirm a “next sprint” exists — Rollover to “Next Sprint” requires that a future sprint already exists in the Sprint Folder. If your folder only had one sprint and it’s now completed, there’s nowhere to roll tasks into. Create Sprint 2 (or whichever comes next) before completing the current sprint.
3. Complete the sprint via Sprint Actions, not just the date — As covered in Fix 4, rollover only fires when you explicitly select Complete Sprint from the sprint’s action menu. Go to the sprint → ellipsis → Complete Sprint. A dialog will appear asking what to do with incomplete tasks — this is where rollover options are confirmed for that specific sprint.
4. Check the incomplete task prompt options — The Complete Sprint dialog offers choices: move to next sprint, move to backlog, or leave in place. Verify you’re selecting the option that matches your team’s expectation. If you click through this dialog too quickly, tasks may be left in place (appearing to “disappear” from the active sprint view without moving anywhere).
5. Locate tasks “stuck” in a completed sprint — If tasks didn’t roll over and aren’t in the backlog, they’re likely still in the completed sprint’s List. Filter tasks by sprint status = “Completed” to find them, then manually move them using Add to Sprint on each task.
6. Test the full rollover flow on a sandbox sprint first — Before relying on automation for a high-stakes sprint, create a test Sprint Folder with two sprints, add two tasks, complete Sprint 1, and verify the rollover behavior. This five-minute test catches configuration gaps before they affect real work.

If your sprint rollover is working but the completed sprint data isn’t syncing to your reporting tools or integrations, check our troubleshooting guide for ClickUp integrations not syncing in 2026.

FAQ

Why can’t my team members see the Sprints option in ClickUp?

The Sprints ClickApp must be enabled per Space by a Workspace owner or admin. Regular members do not have access to Space-level ClickApp settings and cannot enable it themselves. Go to Space Settings → ClickApps → toggle Sprints on. If the option still doesn’t appear after enabling, ask affected team members to sign out and back in — ClickApp changes require a fresh session to take effect for existing logged-in users.

How do I fix the sprint index number not starting at the right number?

This is a confirmed ClickUp bug — the starting index field was removed from the Create Sprint modal. The workaround is to create a fresh Sprint Folder, delete the auto-generated sprint(s) inside it, then manually create your first sprint via the + Create Sprint button. This resets the internal index counter. Name the sprint manually (e.g., “Sprint 5”) if you need to match a specific number, and subsequent sprints will continue from there.

I changed the sprint duration in my Sprint Folder settings — why are existing sprints still showing the old duration?

Sprint settings changes are not retroactive. Only sprints created after the settings change will use the new duration, automation rules, or other configuration. Existing sprints — including future sprints that were auto-created when the folder was first set up — retain the settings they were created with. To fix existing sprints, edit each one individually via right-click → Edit Sprint and manually adjust the start and end dates to match the new duration.

Why is my sprint velocity showing zero even though we completed tasks?

ClickUp’s velocity calculation only counts tasks that have story point estimates assigned and are in a “Done” status category. Tasks without story points are silently excluded from the velocity total. First, confirm the Story Points ClickApp is enabled in your Space settings. Then audit your completed sprint tasks to ensure they have point values and that your final task status (e.g., “Deployed,” “Shipped”) is mapped to the Done category under Space Settings → Task Statuses.

Unfinished tasks didn’t roll over when my sprint ended — where did they go?

Rollover only fires when you explicitly complete the sprint via the Sprint Actions menu (ellipsis → Complete Sprint). Letting the end date pass in the calendar does not trigger any automation. If you already completed the sprint but tasks didn’t move, check whether rollover was enabled in the Sprint Folder settings at the time that sprint was created — settings changes don’t apply retroactively. Tasks left behind will still be in the completed sprint’s List; search for them by filtering to the completed sprint and move them manually using Add to Sprint.