Scrum Sprint Template
A ClickUp Scrum workspace template for two-week sprints. Includes a prioritized product backlog, sprint board with four stages, a Definition of Done checklist attached to each task, team capacity tracker, velocity dashboard across five sprints, and a structured retrospective space with owner-assigned action items.
Template Preview
What This Includes
- Product backlog list with story points (custom field), priority (MoSCoW: Must Have, Should Have, Could Have, Won't Have), acceptance criteria, and assignee fields
- Sprint board with To Do, In Progress, Review, and Done columns
- Definition of Done sub-task group attached to each backlog item: Code Reviewed, Tests Passing, Acceptance Criteria Verified, Documentation Updated, Deployed to Staging
- Sprint goal task pinned at the top of the active sprint board
- Team capacity tracker showing available story points per team member per sprint
- Velocity dashboard tracking completed story points across the last five sprints with trend line
- Retrospective workspace with What Went Well, What Did Not Go Well, and Action Items sections (each action item has an assignee and due date field)
Who This Is For
Software development teams
Teams running two-week feature development sprints with a prioritized product backlog and a QA or review step.
Teams adopting Scrum for the first time
Teams transitioning from ad hoc task management who need a working structure on day one without building it from scratch.
Scrum Masters setting up a new team
Scrum Masters who want a configured environment that models correct Scrum structure including the Definition of Done.
How to Use This Template
1
Copy the Template to Your Workspace
Click Use Template to add it to your ClickUp Space or Folder. All views (Sprint Board, Backlog List, Workload, and Velocity Dashboard) import automatically with their configurations. The sample tasks in the backlog show the recommended field structure before you replace them with your own stories.
2
Build Your Product Backlog
Create tasks in the Product Backlog list. Write each task title as a user story: As a [type of user], I want to [action], so that [outcome]. Fill in the Story Points estimate, MoSCoW priority, and Acceptance Criteria for each story. Drag items into priority order with the highest-priority items at the top. Stories at the top of the backlog should be fully refined (estimated, with clear acceptance criteria) before sprint planning. Stories lower in the backlog can remain rough until you get closer to working on them.
3
Set Team Capacity
Open the Team Capacity tracker and enter each team member's name, their available working days for the sprint, and their average story points per day based on past performance. For a new team with no velocity history, use a conservative estimate of 3 story points per developer per day and adjust after the first two sprints. The tracker calculates total sprint capacity automatically.
4
Run Sprint Planning and Move Stories to the Board
During sprint planning, drag stories from the Backlog into the To Do column of the sprint board, stopping when you reach team capacity. Assign each story to a team member. Update the Sprint Goal task at the top of the board with a single sentence describing what a successful sprint looks like. The sprint goal is more important than the individual story list: it gives the team a shared decision-making framework when unexpected issues arise mid-sprint.
5
Attach and Use the Definition of Done
Each task in the sprint board has a Definition of Done sub-task group with five default items: Code Reviewed, Tests Passing, Acceptance Criteria Verified, Documentation Updated, and Deployed to Staging. A task cannot move to Done until all five items are checked. Customize the DoD items to match your team's actual quality standards. If your team does not do formal code review yet, remove that item rather than leaving it unchecked, which creates confusion about whether Done means done.
6
Update the Board Daily and Run Standups
At each standup, walk the board from right to left: check tasks in Review first, confirm they meet DoD and move them to Done, or identify what they still need. Then review In Progress tasks for blockers. Use the Blocked status on any task that cannot move without external input. A task that is Blocked is not In Progress: it should be flagged immediately rather than sitting in an active stage with no movement.
7
Close the Sprint and Run the Retrospective
At sprint end, hold the sprint review before closing anything. Move incomplete stories back to the backlog for re-prioritization rather than automatically carrying them forward. Close the sprint in ClickUp to record the velocity. Then open the Retrospective workspace, run the team through What Went Well, What Did Not, and Action Items, and assign each action item to a named person with a due date. Check the previous sprint's action items at the start of the next retrospective to confirm they were completed.
This template is built for teams adopting Scrum for the first time or teams that want a clean starting point after outgrowing an informal sprint setup. The Definition of Done checklist attached to each task is the most important feature: without a shared standard for what done means, teams regularly discover that sprint-closed tasks still require QA, documentation, or deployment work. See the Scrum overview for the principles this template operationalizes.
Common Questions About Scrum Sprint Template
What is the Definition of Done and why is it in the template?
The Definition of Done (DoD) is a team agreement on the quality criteria that every completed task must satisfy before it can be called done. Without it, done means different things to different people: a developer might call a feature done when the code is written, while the product owner expects it to be tested, documented, and deployed. The DoD sub-task group in this template makes the agreement explicit and enforced at the task level rather than assumed.
How do I track velocity with this template?
The Velocity Dashboard widget pulls story point totals from closed sprint tasks automatically. After your first sprint close, the dashboard starts populating. After three to five sprints, the average velocity trend becomes reliable enough to use for sprint capacity planning. Enter your average velocity into the Team Capacity tracker to calculate how many story points to commit per sprint.
Can I adapt this template for a one-week sprint?
Yes. Change the sprint dates to a one-week cycle in ClickUp's sprint settings. The board structure and DoD checklist work regardless of sprint length. The main adjustment is sprint capacity: a one-week sprint typically supports about half the story points of a two-week sprint for the same team. You may also want to shorten the retrospective format to 30 minutes given the faster cadence.