Goals, burndown and insights
What this page is — What a time box is for — its goal and success criteria — and the ways the committed plan is watched afterwards: an AI goal check, a daily burndown, five Risk radar signals, a delivery forecast that follows the plan's links, and new report fields. What it is for — Writing a sprint goal that the sprint review can be judged against, and finding out mid-sprint, not at the end, that it is slipping. The problem it solves — A sprint filled to capacity can still miss its point. Goals lived in meeting notes, burndowns in spreadsheets, and nobody noticed that the work added after planning had quietly outgrown the sprint.
Routes: /org/tasks/planning?tab=goals · ?tab=live · /org/tasks?panel=risk · /org/tasks/reports · Permissions: View planning (goals, burndown), Manage planning (edit goals), Planning AI (goal check — spends credits), View risk radar, the report builder permissions
Module: Planning · Entry points: Planning → Goals · Planning → Live → a time box's burndown · Tasks → Risk · Tasks → Reports
1. Goals and success criteria — field reference
Each time box in a scenario carries its own goal. On the Goals tab every sprint or phase shows:
| Field | Type | Notes |
|---|---|---|
| Goal | Text | One or two sentences of what will be true when the box is done; Seeded from: shows the committed wording when you change it |
| Success criteria | Checklist | Add a measurable criterion with Enter; tick it done; remove it |
| Focus factor | Stepper 0.10 – 1.00 | Blank uses the project default; Use project default clears it. Changes recompute this box's capacity |
| Include in commit | Toggle | Off = this box's plan and capacity are not written when the scenario is committed; the Plan tab shows Not in commit |
| Committed plan | Read-only | The committed goal, N h committed of M h net and the date; Goal differs when your wording has moved; underneath, the last goal-check verdict with its time (or Goal not checked yet); Never committed. otherwise |
Goals are committed with the scenario and then appear on the Roadmap beside the sprint, in the commit history under Goals written, and in the Live tab.
Suggest a goal with AI
On a draft scenario, Suggest goal beside the Goal label proposes a goal and three to five success criteria. It needs the Planning AI permission.
| Box | What the suggestion is built from |
|---|---|
| Sprint (or a phase with no sprints) | The stories this scenario places in it: key, title, a short description, size, assignee and category (up to 60, largest first), the dates, the planned load against capacity, the goal of its phase and the current goal |
| Phase with sprints | The goals and success criteria of its sprints. The phase goal is what they add up to, so every sprint needs a goal first: until then the button is disabled and names the sprints without one |
The proposal shows the goal, the criteria, a one-line reason and the stories or sprints it rests on. Use this replaces the goal and criteria of the box and saves them in the scenario — nothing reaches the live sprint until you commit. Try again runs it once more, with optional guidance such as focus on what the customer can do; Discard drops it. A box that has not changed answers from its last suggestion without spending credits; a new run costs about 3,600 AI credits (more for a sprint with many long stories), and your organisation needs at least 9,000 in its balance to start one.
For example, Sprint 4 holds five checkout stories. Suggest goal proposes A customer can pay by card or UPI and gets a receipt by e-mail, with the criteria Card payment succeeds end to end on staging, UPI collect request completes and Receipt e-mail arrives within one minute. After Sprint 5 and Sprint 6 have goals too, Suggest goal on their phase combines the three into one phase goal.
A sprint with no tasks in the scenario answers This sprint has no tasks in the scenario yet: plan some work into it first.
2. Why you would write goals here
- The goal is stored with the capacity and load it was promised against, so "we said we would ship X with 240 hours" is a fact later, not a memory.
- Success criteria give the AI check and the sprint review something concrete to test.
- A box without a goal is a
goal_missingwarning at commit — a gentle nudge, not a block.
3. The AI goal check
Open the Live tab. Under Time box focus — burndown & goal, choose a box in Pick a committed time box; the Goal check card sits beside its burndown. Check goal runs the Time-box Goal Check utility — Add guidance for the check (optional) opens a text box first if you want to steer it. Once a result exists the button becomes Re-run, which ignores the stored result and spends credits again. The Goals tab only shows the last verdict; it cannot run a check. It reads the goal and criteria, the done and open tasks in the box, load against committed capacity and the last seven days of burndown, and answers:
| Output | Meaning |
|---|---|
| Verdict | on track · at risk · off track, with a confidence |
| Evidence | The facts the verdict rests on — counts and hours, computed before the model sees them |
| Gaps | What the criteria ask for that the tasks do not cover |
| Suggested actions | Next steps, named against real tasks |
The result is cached per time box until the goal, its criteria, its open tasks or their progress, or the latest burndown snapshot change, so opening the card again costs nothing (a Cached chip says so). A verdict of at risk or off track feeds the Risk radar's goal_at_risk signal for seven days. The check needs Planning AI and about 400 credits (ceiling 1,600).
4. Burndown
A platform job — Planning Burndown Snapshot Daily, early each morning before the Risk radar runs — records one row per active sprint or phase: tasks total, open and done; remaining hours and points; done points; scope (the sum of every estimate in the box); net capacity when a plan is committed; load; and the hours planned on hires. The Live tab draws the last 30 days of these as a burndown for the box picked under Time box focus: Remaining hours, the dashed Ideal line from scope to zero at the end date, the Scope line, and Hire load bars when work sits on planned hires. Today's point is always computed live, so a newly committed box shows one point straight away.
Two consequences worth knowing:
- The first stored point appears the morning after the job is enabled or the box starts — there is no backfill; until then the chart shows only today's live point.
- A rising scope line while remaining stays flat is scope creep; the radar says so too.
5. Risk radar signals from the plan
Once a time box has a committed plan, the Risk radar gains five signals. Projects without a committed plan never see them.
| Signal (as the radar labels it) | Code | Fires when | Notes |
|---|---|---|---|
| Time box overcommitted | timebox_overcommit | Open load ÷ net capacity of a committed sprint or phase crosses the bands — low at 1.0, medium at the project's overload ratio (1.2 by default), high at 1.5 | The same ratio that flags a person flags a box |
| Scope creep since commit | timebox_scope_creep | Open load is more than 15% above the hours committed at plan time | Work was added after the commit |
| Overloaded within sprint | member_timebox_overload | One member's open load in an active sprint exceeds their committed capacity for what is left of the box | Uses committed net hours instead of daily capacity × workdays |
| Goal at risk | goal_at_risk | The last goal check, no older than seven days, said at risk or off track | Run a fresh check to clear it |
| Unfilled planned hire | unfilled_hire | Open tasks are planned on a hire, nobody is assigned, and the box has started or starts within the due soon window | Replace the hire with the real member |
A milestone card carrying one of these shows Open in Planning → Live, which opens the Live tab focused on that time box; the team-load row for an overloaded member links Open in Planning. The codes are what the alert digest and the API carry.
Phase-level views include the child sprints' findings.
The delivery forecast follows the plan
The Delivery forecast on each milestone card now counts the work the plan links to it, not only the tasks placed directly in it:
- a milestone is forecast from the tasks that contribute to it (the Contributes to value set on the Plan tab or the task), wherever those tasks sit;
- a phase is forecast from its own tasks and the tasks of every sprint inside it;
- a sprint keeps counting the tasks placed in it.
Only open tasks count. A project that never uses Contributes to or parent phases sees exactly the forecast it saw before.
6. Report builder
The Report builder gains fields on the task dataset and two datasets of its own:
| Where | Field / dataset | Meaning |
|---|---|---|
| Tasks | Contributes to Milestone | The milestone a task feeds |
| Tasks | Phase | The parent phase of the task's sprint (or the phase itself) |
| Tasks | Sprint / Phase | The time box (renamed from Milestone) |
| Tasks | Story Points · Estimate Source | Points, and whether hours are manual or derived from points |
| Tasks | Planned hire | The hire a task is planned on while unassigned |
| Dataset | Committed capacity | One row per person per time box as committed: net hours, overrides, focus |
| Dataset | Planning commits | One row per commit: who, when, tasks changed, moved, reassigned, warnings |
7. Worked example
The goal of R3-S2 reads "Beta customers can pay by card" with three criteria: retries handled, refunds reconciled, dashboards updated. Committed at 212 h against 224 h net. A week in, the burndown shows remaining hours flat for three days while scope has risen by 30 h — two tasks were added after the commit. The radar flags Scope creep since commit (medium); the lead follows Open in Planning → Live and runs Check goal: at risk, confidence 0.7 — evidence: 4 of 11 tasks done, load now 108% of net; gap: no task covers "refunds reconciled"; suggested action: descope the two added tasks or move "Refund matching" up. She moves the added tasks to the next sprint in a fresh scenario and commits; the next morning's snapshot shows scope back at 212 h and Re-run says on track.
8. The admin contract
- Time-box Goal Check must be enabled by your platform operator (it is an AI utility with its own persona and model) and needs credits on the organisation; without it, Check goal reports that the utility is unavailable.
- Planning Burndown Snapshot Daily is a platform job, disabled by default — ask your operator to enable it; the radar's own daily job runs after it.
- Risk signal thresholds live in Project settings → Risk Radar; the commit band's medium value follows the overload ratio unless set explicitly.
- Report fields need no configuration; the datasets appear once the first scenario is committed.
9. Don't confuse this with…
- Progress reports — narrative for stakeholders; the goal check is a verdict on one time box.
- Delivery forecast — a probabilistic finish date that now follows contributions and phases; the burndown is the recorded daily fact for one box.
- Roadmap progress bar — share of tasks done; the goal check reads criteria, not counts.
10. Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| No burndown line | The job is disabled, or the box started today | Ask your operator; check tomorrow |
| No Check goal button | You lack Planning AI, or the box has no committed plan (the card says Commit a plan for this time box first) | Ask for the permission; commit first |
| The box is not in Pick a committed time box | Only committed sprints and phases are listed | Commit a scenario that includes it |
| A milestone's forecast jumped after planning | Tasks now contribute to it, or sprints were placed under its phase | Expected — the forecast counts linked work |
| The verdict does not change after fixing tasks | The cached result is still valid until progress changes | Progress the tasks, then check again |
goal_at_risk persists on the radar | The last check is under seven days old | Run a new check |
| Planning signals never appear | The project has no committed plan | Commit a scenario |
| Committed capacity dataset is empty | Nothing committed yet | Commit; the dataset fills from that commit |