How to Create Custom Sprints in ClickUp

What a custom Sprint means in ClickUp

A custom Sprint in ClickUp is a time-boxed planning period with a duration chosen by the team. The Sprint may contain tasks, estimates, assignees, priorities and statuses, but its defining feature is the agreed start and end boundary.

For example, a team might choose a 10-day Sprint because its working calendar excludes weekends, or choose a three-week cycle because its work requires more coordination before review. The number is less important than whether the team can repeat the cadence consistently and make a meaningful decision at the end of each cycle.

Custom duration is useful when different teams have different constraints. It is less useful when the team is changing the duration frequently to accommodate unplanned work. In that case, the underlying issue may be intake control, prioritisation or capacity planning rather than ClickUp configuration.

Choose the Sprint cadence before changing ClickUp

Before opening Sprint settings, define what the cadence needs to support. A simple decision sequence helps:

A shorter Sprint can create more frequent feedback, but it also increases the overhead of planning and review. A longer Sprint can provide more room for complex work, but it may delay feedback and make it harder to identify blocked tasks. The right choice is the shortest cadence that supports useful work and useful decisions.

Set up the Sprint structure in ClickUp

ClickUp Sprints are commonly organised in a Sprint Folder within a Space. The exact labels and available options can vary as ClickUp updates its interface and workspace configuration, but the underlying setup is consistent.

1. Open the Space where the team manages its Agile work.

2. Create or select a Folder dedicated to the team’s Sprints.

3. Enable or configure the Sprint features available for that Folder.

4. Confirm how Sprint Lists will be named, dated and used by the team.

Keep the structure understandable to someone who was not involved in setting it up. A Sprint Folder should make it obvious where current work, upcoming cycles and completed cycles belong. Avoid creating multiple Sprints structures for the same team unless there is a clear ownership or reporting reason.

Create a custom-duration Sprint in ClickUp

Once the Sprint Folder is ready, use the Sprint settings or the relevant Sprint management view to configure the first cycle.

1. Open the Sprint settings

Navigate to the Sprint Folder and open its Sprint settings. Depending on the current ClickUp interface, these controls may be available from Folder options, a Sprint view or a related configuration panel. Look for settings that control duration, start dates and future Sprint creation.

2. Select a custom duration

Find the duration or Sprint length setting and choose the custom option if one is available. Enter the number of days or weeks that matches the cadence agreed by the team. Do not choose a duration merely because it makes a calendar look tidy. A 10-day Sprint, for example, is only useful if the team understands whether that means working days, calendar days or another defined convention.

3. Set the first start date

Choose the date on which the first Sprint begins. Check the calculated end date and confirm that it matches the team’s working calendar. If the workspace uses a shared time zone or teams work across regions, document which date and time define the boundary.

4. Save and inspect the generated schedule

Review the first Sprint and any future Sprints created from the settings. Check names, dates and the location of the Sprint Lists. Correct the schedule before tasks are committed to it. A small date error at the start can create repeated confusion across later cycles.

Decide how future Sprints are created

ClickUp can support different approaches to generating future Sprints. The right choice depends on how stable the team’s cadence is and how much control it needs over upcoming work.

Automatic creation

Automatic creation can maintain a predictable sequence of future Sprints. It is appropriate when the duration, naming convention and ownership are stable. Review the generated dates rather than assuming they are correct, especially after a change to the start date or working calendar.

Manual creation

Manual creation gives the team more control when work is seasonal, dependent on external events or likely to pause. It also creates an ownership requirement: someone must create the next Sprint before planning begins. If that responsibility is unclear, manual creation can lead to missing cycles and work being placed in the wrong List.

The choice is not permanent. A team can begin manually while it stabilises its process, then use automatic creation once the cadence and naming rules are proven.

Manage work inside a custom Sprint

Creating the Sprint is only the scheduling step. The team still needs rules for selecting, owning and finishing work.

Define what belongs in the Sprint

Move existing tasks into the relevant Sprint List or create new tasks there. Each task should have enough information for the assignee to understand the expected outcome, priority and dependencies. Estimates can support capacity conversations, but an estimate is not a commitment unless the team uses it in planning.

Make ownership visible

Assign each active task to an accountable person or explicitly mark it as awaiting assignment. A Sprint that contains many unowned tasks may appear well organised while hiding a handoff problem. Use statuses to show meaningful business states such as ready, in progress, blocked, ready for review and complete. Status names should describe the state of the work, not simply the action someone last performed.

Handle incomplete work deliberately

At the end of a Sprint, do not move every unfinished task forward automatically without review. Ask why the task is incomplete. It may be blocked, too large, no longer important, missing information or incorrectly estimated. Then decide whether to carry it forward, split it, return it to the backlog or close it.

That decision creates better planning information than simply treating unfinished work as a new commitment.

Track progress and review the cadence

Use ClickUp views, filters and reporting features to answer specific management questions. For example: Which committed tasks are blocked? How much work is awaiting review? Which items were carried over? Does the team have enough capacity for the next cycle?

Do not measure activity when the decision concerns outcomes. The number of comments or status changes may show system usage, but it does not necessarily show completed work. Choose reporting fields and views that support the team’s planning and delivery decisions.

Consistent Sprint lengths make comparison easier, but comparison is meaningful only when scope, staffing and work type are reasonably comparable. A custom duration should create a stable observation period, not pressure the team to optimise a metric that does not represent value.

Common mistakes with custom ClickUp Sprints

• Changing the duration to hide missed commitments. If the team repeatedly needs more time, inspect scope, dependencies and capacity before extending the Sprint.
• Mixing unrelated work in one Sprint. Support, project delivery and exploratory work may need different planning rules or clear work types.
• Creating Sprints without ownership. A recurring schedule still needs someone responsible for checking dates, names and planning readiness.
• Using statuses as activity labels. A status should represent a real state of the work so that a report can be interpreted consistently.
• Automating before the rule is clear. Automatic task movement, notifications or Sprint creation can spread a weak process faster. Clarify the decision and ownership first.

For a broader implementation, the ClickUp consulting service can help connect workspace structure, workflow rules, dashboards and automation to the way the team actually operates.

Example: a team choosing a 10-day Sprint

Consider a hypothetical product team that plans on Mondays, reviews completed work every second Friday and has regular support duties during the week. The team chooses a 10-day Sprint so it can preserve a predictable review point while accounting for its working calendar.

Before configuring ClickUp, the team defines a capacity limit, identifies who owns Sprint planning and agrees that blocked tasks will be reviewed rather than silently carried forward. It then creates the Sprint Folder, sets the start date, checks the generated end date and uses a dashboard to review committed, completed, blocked and carried-over work.

The value does not come from the number 10. It comes from the shared operating rule around that number. If the team later changes its support rota, it can review the cadence using evidence rather than changing settings reactively.

When the structure is stable, the team can consider automation for reminders, recurring setup or reporting. Automation should follow the agreed process, and AI should have a defined job such as helping classify incoming work or summarise review information. Neither replaces the need for clear states, ownership and decisions.

For an example of a ClickUp-based operational workflow, see the ClickUp hiring workflow portfolio page. The relevant lesson is to design the workflow around real handoffs and ownership rather than adding tools without a process model.