Plan a sprint

A sprint is a fixed time box inside a project: a start date, an end date, and the set of tasks committed to it.

Sprints are optional. If your team pulls work continuously from a board, you can skip this page entirely. Use sprints when you want a recurring “what did we commit to, and did we make it?” conversation.

Open a sprint

Create it in the project’s sprint section: give it a name, a start date, and an end date. Two weeks is the usual length. One week works if your work is small and steady; four weeks usually means the plan is stale by the end.

Fill it

Pull work in from the backlog. From a list view you can select many tasks at once and assign them all to the sprint, or hover any single task and press C.

Two habits make the number at the end mean something:

Estimate before you commit, not after. An unestimated task counts as zero in a points-based chart, so a sprint full of unestimated work looks finished before it starts.

Commit to less than you think. The first two or three sprints are measurement, not performance. You are finding out what your team actually delivers in two weeks. That number is almost always lower than the plan, and knowing it is the entire point.

While it runs

dotby writes a snapshot of the sprint once a day, for every day it is open. That is what draws the burn-up chart: committed scope as one line, completed work as another, climbing toward it.

The daily snapshot matters more than it sounds. Because each day is frozen when it happens, work added mid-sprint stays visible as a step up in the scope line instead of quietly rewriting history. Scope creep shows up as a shape you can point at in a retro.

Reading it:

• Completed climbing steadily toward scope — healthy.
• Scope climbing too — you are taking on new work mid-sprint. Sometimes correct, always worth naming.
• Completed flat, then a cliff at the end — everything finished on the last day, which usually means tasks are too big to move.

Close it

Complete the sprint when the time box ends — not when the work ends. That distinction is what makes the number honest.

Unfinished work does not disappear. You decide, task by task, what happens to it: carry it into the next sprint, or send it back to the backlog. Anyone watching a task that ends a sprint unfinished gets told, so nothing goes quiet.

Completed sprints stay around with their charts intact. That history is the most useful planning input you will ever have — after three sprints you stop guessing your capacity and start reading it.

Sprints, modules, and initiatives

Three different ways to group work, easy to confuse:

Grouping	Answers	Lives in
Sprint	When — which time box	One project
Module	What part — which workstream	One project
Initiative	Toward what outcome	Across projects

A task can be in a sprint and a module at the same time. They are independent axes, not competing ones.

Next

• Projects and views — save a “this sprint” view so the team has one place to look.
• Core concepts — how sprints relate to everything else.