Prepare the plan
Open the team's Scrum board and its backlog. The board's creator, a Company administrator or someone who manages boards in every scoped project can create, start and close sprints. Planning an individual issue requires permission to rank that issue and access to the board. You need an assigned seat to create or change a sprint or its issue list.
- Create a sprint with a name and goal.
- Select backlog issues and add them to the planned sprint.
- Review original estimates and the issue list before starting.
You can plan only issues within the board's scope. Product boards allow an issue in one open sprint within the product; standalone boards enforce that rule within the board. See Boards and products for shared ordering and project scope.
Start and run a sprint
Start a planned sprint and set its dates. The end must follow the start. Quevell captures the initial issue list, original estimates and states when the sprint starts. A product board also captures the current Product Goal and Definition of Done revision. The Sprint Goal describes the team's own work.
After the sprint starts, you can add issues or return them to the backlog. These actions enter the history. Original-estimate changes and status transitions are also recorded in the sprint history. Change status through the permitted workflow transitions.
Setting a start date in the past does not add data for earlier days. The baseline records the issues as they are when the sprint starts.
Close and carry unfinished work
Open the active sprint's completion action and review the result. Choose where unfinished issues go: back to the backlog or into an existing planned sprint on the same board. Once you confirm, unfinished issues appear in the backlog or destination sprint.
Issues in the "Done" category count as completed unless their outcome is "Cancelled". Cancellations are reported separately. Unfinished issues remain in the closed sprint's history even after being carried forward. A closed sprint is not available for new planning or scope changes through returning an issue.
Closure history uses the actual completion time. Closing early or late changes the observation period without retrospectively stretching or compressing the original plan.
Baseline and outcome
Open board reports and choose a sprint. Compare its original plan, additions, removals, final scope and outcomes. Each issue shows its baseline estimate and last recorded estimate, with an outcome such as completed, cancelled, returned or removed from scope.
Addition and removal operations can outnumber unique issues: the same issue may leave and re-enter. The baseline stays unchanged. An issue added after the sprint starts with no issues does not become part of the original zero plan.
Historical estimates and states come from recorded events. Reports show each issue's current key and summary. Current project permissions and issue security filter the history, so readers with different access can see different totals. Changing the current board filter does not rewrite the recorded sprint scope.
Older sprints without a baseline show an unknown plan. Missing estimates also remain unknown and are not treated as zero. This is a historical-data limitation, not evidence of zero work.
Burndown
Choose Burndown in the report. It shows unfinished scope by day, as an issue count or original-estimate duration. Estimates are stored in minutes and displayed as durations. The chart does not sum remaining-estimate fields or subtract worklogs.
Report days use UTC. Each day's value uses the last recorded issue state before that day ends. Remaining work includes issues still in scope whose category is not "Done". Cancellation reduces remaining scope but is shown separately and does not become completed work.
Adding an issue increases scope and can increase the remaining scope. Removing it reduces both. Revising the original estimate changes the duration series from the recorded change onward. Moving an issue to another project records its departure from the earlier sprint; the reader's permissions still restrict what appears.
The ideal line falls linearly from the baseline to zero by the planned end date. New issues do not change its starting point. If the sprint closes late, the ideal line stays at zero after the planned end. There is no data for future days or days before the sprint actually started. Missing historical data is not replaced with calculated values.
For example, two initial issues estimated at 2h each give a 4h plan. Adding another 1h issue increases current scope to 5h while the baseline stays 4h. Completing an initial issue leaves 3h of unfinished scope. Recording 1h of work without changing status or the original estimate does not reduce this chart.
Velocity
The board's Velocity chart compares the baseline with completed work in closed sprints. Completed duration sums the original estimates at closure for issues completed with an outcome other than cancellation. An issue added during the sprint and completed can therefore raise the result above the initial plan.
Average velocity uses the last three sprints with known actual closure times, ordered by actual closure. If fewer exist, it uses those available. Completed minutes are summed and divided by the number of sprints; fractional minutes are discarded. Results of 4h, 6h and 8h, for example, give a 6h average.
If a completed issue has an unknown estimate in that window, the average is unknown. That sprint stays in the calculation; an earlier sprint is not used in its place. A known zero participates in the average. Legacy records without an actual closure date remain visible but are excluded from the average velocity calculation.
Velocity describes a particular board and the issues visible to its reader. It is not a release-date prediction or a comparison of individual productivity. Use Time tracking for actual effort.