AWRA OpsHub Search
Intermediate Certificate on pass

Projects: Agile Delivery

Run sprints on the same tasks you already track: a backlog and planning board, a per-sprint Kanban, story points, and velocity and burndown computed from real completion — with unfinished work carried back to the backlog on close.

3 lessons 30 min 5-question assessment 75% to pass
Take the assessment

What you’ll learn

  • Groom a backlog and plan a sprint with story points
  • Run the per-sprint board and the sprint lifecycle
  • Interpret velocity and burndown as computed metrics
  • Explain carry-over and why sprint metrics stay honest

Course content

3 lessons · 30 min of reading
01
Lesson 1 of 3 Reading 9 min

Backlog, sprints, and one source of truth

Agile in AWRA is a lens over the tasks you already have, not a separate world. There are no special "agile items": a sprint simply organises existing tasks. On the sprint-planning screen you see the project backlog beside your sprints, and you pull work into a sprint or send it back to the backlog. This "one source of truth" design means sprint metrics and project progress never disagree, because they are counting the same tasks.

A sprint has a goal and start/end dates, and it holds a set of tasks sized in story points. Story points express relative effort; the planning view totals them so a team can weigh what it is committing against what it has historically delivered. Sizing is a team judgement, and the value is in the conversation and the trend, not in any single number being "correct".

The sprint moves through a simple lifecycle: planning, active, then completed. Only that clean flow exists — there is no tangle of intermediate states — and every transition is audited like the rest of the platform. Keeping the lifecycle minimal is deliberate: the discipline lives in how the team works, not in configuring a complex state machine.

Key takeaways

  • Sprints organise existing tasks — there are no separate "agile items".
  • One source of truth: sprint metrics and project progress count the same tasks.
  • A sprint has a goal, dates, and tasks sized in story points.
  • Lifecycle is planning → active → completed, fully audited.
02
Lesson 2 of 3 Reading 8 min

The sprint board and carry-over

During a sprint the team works a board scoped to just that sprint's tasks, grouped by status. Narrowing the board to the sprint keeps focus on the current commitment rather than the whole project backlog — the point of timeboxing in the first place. It is the same Kanban interaction as the project board, only filtered.

The defining moment is closing the sprint. When you complete a sprint, any unfinished tasks are automatically carried back to the backlog. Nothing is lost, and — crucially — nothing that was not actually finished is counted as finished. This is what keeps the metrics honest: velocity reflects only completed work, and the backlog transparently regains what did not get done, ready to be pulled into the next sprint.

A common anti-pattern elsewhere is quietly marking spillover as "done" to make a chart look good; AWRA's carry-over makes that unnecessary and visible. If a sprint routinely carries a lot back, that is a planning signal — the team is over-committing — and the honest numbers are exactly what surfaces it.

Key takeaways

  • The sprint board is a Kanban scoped to the sprint's tasks, for focus.
  • Completing a sprint carries unfinished tasks back to the backlog automatically.
  • Only genuinely completed work counts — metrics are not inflated by spillover.
  • Frequent carry-over is a planning signal (over-commitment), made visible by honest numbers.
03
Lesson 3 of 3 Reading 8 min

Velocity and burndown, computed

Velocity is the sum of story points completed in each finished sprint, plus a rolling average across sprints. Because it is derived from the tasks a sprint actually completed, it needs no manual entry and cannot be fudged. The rolling average is the useful forecasting input: it tells a team roughly how much it tends to deliver, which grounds the next sprint's commitment in evidence rather than optimism.

The burndown chart plots remaining work against an ideal straight line from the sprint's start to its end. AWRA computes it from task completion timestamps, so there is no nightly snapshot job to schedule, maintain, or have silently fail — the chart is always consistent with the underlying data. Reading it is intuitive: above the ideal line means behind, below means ahead.

Together these give a team a feedback loop without administrative overhead: burndown for in-sprint pacing, velocity for cross-sprint forecasting. And because everything is computed from the same tasks that planning, the Gantt, and time tracking use, there is never a reconciliation step between "the agile numbers" and "the project numbers".

Key takeaways

  • Velocity = completed story points per finished sprint, plus a rolling average for forecasting.
  • Burndown is computed from completion timestamps — no snapshot job to maintain.
  • Above the ideal line = behind; below = ahead.
  • All metrics derive from the same tasks — no reconciliation with project numbers.

Finished the material?

Take the 5-question assessment and earn your certificate — 75% to pass.

Take the assessment

More in this path

Point of Sale Fundamentals

Open course

Asset Tracking Essentials

Open course

Vendor Portal Foundations

Open course

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center