Tutorial
Plan and start a sprint
From backlog to running sprint: create the sprint, pull issues in, start it — and see what Zuuna carries over for you automatically.
Last updated:
A sprint in Zuuna is not a label on a filter — at start it becomes a real board with its own progress and time remaining. This guide goes from an empty backlog to a running sprint. Sprints belong to the Developer plan.
What you need
- The Developer plan — see pricing.
- A group with a few issues in the backlog. None yet? Create a board first.
1. Check your plan
Sprints, backlog, poker and releases form the Developer plan's agile layer. On other plans the backlog tab does not appear.
2. Understand the backlog view
The backlog view is one list in sections, top to bottom: the active sprint, your boards, the planned sprints, and at the bottom the group's backlog — board-less issues not yet promised to any sprint. Planning means dragging issues upwards.
3. Create the sprint
Create a new sprint: a name ("Sprint 12"), optionally a goal ("onboarding flow done"), a date range. It appears as a planned sprint — a holding box, not yet a board.
4. Pull issues into the sprint
Drag the prepared issues in; multi-select works for batches. If you use the refinement board, its "ready for sprint" tab is the natural source: only discussed, estimated work lives there.
The story-point total updates as you go — together with capacity it is your early warning against over-commitment.
5. Start the sprint and map the columns
Starting is where the interesting part happens: the planned sprint becomes a board. Zuuna copies columns, views, custom fields and automations from the previous sprint board — your process moves house instead of being rebuilt every two weeks. All you do is choose which column each issue starts in.
The running sprint shows purple in the sidebar, with progress and days remaining at the top. And an existing board can be started as a sprint directly — it stays in place and no card moves.
6. Set the sprint settings once
In the group's sprint settings you fix the sprint length, the board template and the estimation scale (Fibonacci or your own values — the same scale planning poker uses later). Set once, every new sprint proposes itself correctly.
Troubleshooting
- "This group already has an active sprint." Exactly one runs per group. Close the current one first.
- No backlog tab. Your plan has no sprints — the Developer plan is required.
- Issues missing while planning. Check the section: cards already on a board sit under that board, not in the backlog.
- Wrong columns in the new sprint. The template comes from the last sprint board. Tidy it there once — the next sprint inherits it right.
Next steps
- Plan sprint capacity — before you promise too much.
- Close a sprint and read the burndown.
- Project management for developers · Zuuna vs Jira.
FAQ
Can I run several sprints at once?
No — exactly one sprint runs per group. You can stack up as many planned sprints as you like, but only one is active. That is deliberate: two parallel sprints in one group are two competing truths about what the team is doing.
What happens to my automations?
They travel. Starting a planned sprint copies columns, views, custom fields and automations from the previous sprint board — you set your process up once, not every two weeks.
Do I have to use story points?
No. Estimate in points, in hours, in both, or not at all. Capacity and the burndown work with any of the three.
Do I need a new board for every sprint?
No — Zuuna creates it at start. You can also start an existing board as a sprint: everything stays in place and no card moves.
Which plan?
Sprints and the backlog are included in the Developer plan.