Run and complete a sprint

Once a sprint is active, the Sprints tab becomes the team’s daily board, and the Burndown tab shows whether the sprint is on track. This article covers the running phase and what actually happens when you complete a sprint. To set one up first, see planning a sprint.

Work the sprint board

Selecting a sprint shows its tasks as a board with five columns: To Do, In Progress, Review, Done, and Blocked. Drag a card to a new column to change its status; dropping a task in Done also sets its progress to 100%.

The toolbar lets you search the board, filter by priority or assignee, and sort each column by priority, due date, or title. Columns can be collapsed to keep the board compact, and each column header has a quick add button for capturing tasks straight into that status.

You can keep adjusting scope mid-sprint: From Backlog stays available while the sprint is active, and each card has a Move to Backlog action.

Read the burndown chart

Open the project’s Burndown tab and pick your sprint from the buttons at the top (the Project button shows the all-tasks burndown instead). The chart plots two lines:

• Actual (solid): how many tasks were still open on each day. A task burns down on the day it reaches Done.
• Ideal (dashed): a straight line from the sprint’s total task count down to zero at the end date, the pace you would need for a perfectly even sprint.

A dashed Today marker shows where you are in the sprint, and hovering any point shows the remaining count, the ideal value, and how many tasks were completed that day.

Above the chart, four stat chips summarize the same data: Done, Remaining, Velocity, and Projected. Velocity here is tasks completed per day so far, and Projected extrapolates that pace into an estimated finish date.

Tip

Burndown counts tasks, not hours or story points. If your tasks vary wildly in size, split the big ones into subtasks so the line reflects real progress.

Complete the sprint

1. Select the sprint on the Sprints tab. Active sprints show a Complete Sprint button (only an active sprint can be completed).

2. Select Complete Sprint. The sprint’s status changes to Completed.

3. Every task that did not reach Done moves back to the backlog, ready to be pulled into your next sprint. Tasks that are Done stay on the completed sprint as its permanent record.

Completed sprints stay available: enable the Completed status chip at the top of the Sprints tab to see them, and the Burndown tab keeps their charts for retrospectives.

Reading sprint velocity

Onplana doesn’t render a separate “velocity widget” on the dashboard, but a get_project_velocity signal is available to the AI assistant and to MCP-connected agents. It returns the last 7 days of completed tasks, a 4-week rolling average, and a drift percent (negative means the team is slowing down, positive means accelerating), plus a 5-bucket breakdown of completion counts over the past 35 days.

Two practical ways to read it:

• Ask the AI assistant (“is this project slowing down?” or “what is the velocity trend on <project>?”). It pulls the same signal and renders a short narrative. See Chat with Onplana AI.
• Save a Report grouped by sprint with a closed-task count, so you can chart velocity sprint-over-sprint visually. See Run cross-project reports.

Onplana tracks velocity as a task count, not a story-point sum — the platform doesn’t model story points as a separate primitive. If your team uses points, the closest stand-in today is estimatedHours, which Reports can group on the same way.

Best practices

1. Update status the moment a task moves, not at end of day. A burndown that updates throughout the day shows the team’s real pace; a burndown updated in a Friday evening batch shows a cliff that reads as overcommitment when the work was actually steady. Train the team to drag the card the moment they pick it up or finish it.
2. Read the burndown shape, not just the position. “Behind ideal” is bad; flat-for-a-week-then-cliff is worse. The cliff means statuses were updated in a batch, which kills the chart’s predictive value. The fix is the same as #1 — keep status fresh as work happens.
3. Hold the standup against the board, not the calendar. The board makes “what’s moving” and “what’s stuck” visible in seconds. A 15-minute standup against the board gets through 12-15 cards; against the list, the same ground takes 25 minutes because changes require clicks.
4. Use Blocked as the team’s attention signal. Blocked tasks should be the first thing addressed at every standup, not the last. The discipline that makes Blocked useful: drag to Blocked the moment something stalls (not end-of-day); close out Blocked at every standup (drag out or escalate).
5. Don’t let “Complete Sprint” become “extend the dates”. The end date is the end date. Carrying tasks back to the backlog and learning from that signal is how velocity matures. Extending dates to “finish committed work” hides the overcommit pattern from the team’s mental model.
6. Capture a retro note in the sprint’s last comment. What worked, what didn’t, what to change next sprint. Onplana doesn’t have a dedicated retro tool — the sprint’s comment thread or a wiki page does the job without a separate ceremony tool.

Troubleshooting / common pitfalls

• The burndown shows a cliff today. Statuses were updated in a batch (often Friday afternoon). The cliff is honest about when the data hit the chart, but it hides when the work actually happened. Switch the team to in-the-moment updates and the cliff stops appearing.
• Velocity says “0 tasks per day” but tasks are getting done. Three causes: (a) the velocity reading is per active project, not per sprint — switch to the per-sprint burndown; (b) the calculation walks the last 7 days of Done timestamps, which excludes very recent moves; (c) the project hasn’t been active for 7 days yet.
• “Complete Sprint” button is missing. The button only appears for Active sprints. Planning sprints don’t need completing; complete the active one first, then start the next.
• A task moved to Done came back to the backlog after I completed the sprint. It didn’t — Done tasks stay on the completed sprint as its permanent record. Check the Completed status chip at the top of the Sprints tab; the task is there.
• I see two Active sprints somehow. A project should only have one active sprint at a time. If you see two, one of them was probably re-opened from Completed via the edit menu. Pick one as canonical, complete (or delete) the other.

How this combines with other features

• Sprint + Capacity planner. The capacity planner shows whether the team has enough hours for the sprint’s estimated work. Check it during planning to avoid overcommitment that the burndown will reveal later. See Plan team capacity.
• Sprint + Timesheets. Time logged against sprint tasks feeds the per-sprint timesheet roll-up. Combined with rate cards, this gives you actual labor cost per sprint for billing or budgeting. See Log and submit timesheets.
• Sprint + AI assistant. Ask “summarize the active sprint”, “what’s blocked in Sprint 5”, or “is velocity trending down?”. The assistant reads the sprint data in-context. See Chat with Onplana AI.
• Sprint + Burndown chart export. Save a per-sprint Report including the burndown shape for retrospectives with stakeholders who don’t open Onplana. See Run cross-project reports.

Coming from another tool

Tool	Mapping
Jira sprint workflow	Direct: same Start/Complete lifecycle
Linear cycles	Cycle ≈ sprint; cycles auto-create whereas Onplana sprints are explicit
Asana (no sprints)	Asana approximates sprints with sections + custom workflows; Onplana has them as first-class
Azure DevOps Iterations	Direct mapping
ClickUp Sprint Folder	Same lifecycle

FAQs

Do unfinished tasks disappear when I complete a sprint? No. Anything not marked Done returns to the backlog with all its details intact. From there you can pull it into the next sprint during planning.

Why can’t I complete my sprint? Only active sprints can be completed. A sprint still in Planning has nothing to close out; start it first, or delete it if it was created by mistake.

Where does the carry-over go if I already created the next sprint? Into the backlog, not the next sprint. Use the backlog’s bulk Move to sprint action to pull the carry-over into the new sprint in one step; see grooming the backlog.

Can I re-open a completed sprint? You can edit a completed sprint’s state from the actions menu, but re-opening defeats the point of the completion event. The cleaner pattern: create a new sprint for whatever work needs to continue.

Does the burndown account for tasks added mid-sprint? Yes — added tasks raise the remaining count, so the line goes up. That’s honest scope-growth tracking; teams that hide scope by not creating tasks for new requests have a burndown that lies.

What’s a healthy sprint completion rate (% of commitment Done)? 80-95% is the typical healthy range. Below 70%, the team is consistently overcommitting (plan smaller). Above 95% sustained, the team is consistently undercommitting (plan more).

Can I delete a completed sprint? Yes, but Onplana asks for confirmation because deletion moves any Done tasks back to the backlog (orphaning the historical record). Generally don’t delete completed sprints — they’re the team’s history.

Related

• Plan a sprint — the planning phase that precedes this
• Groom the backlog — what to do with carry-over tasks
• Use the calendar and burndown views — burndown deep-dive