Scrum and Agile app: backlog, sprints, epics, and burndown

The Scrum and Agile app turns any circle in your workspace into a lightweight agile team. You get a backlog, a sprint kanban, epics that group stories across iterations, and a burndown chart that updates itself as stories close out. Nothing else about your circle changes, so you can keep meetings, metrics, and projects running alongside.

This guide walks through enabling the app, what changes on the circle, how user stories, sprints, and epics fit together, the burndown mechanics, and how to customise the app for your team's process.

Enable the app

Two switches need to be on for Scrum to show up: one at the workspace level and one on each circle that should run sprints.

Step 1: Enable Scrum on the workspace

1. Open Workspace settings → Applications.
2. Find the Scrum / Agile card.
3. Flip the switch on.

This unlocks the Scrum labels (user story, sprint, epic) for the whole workspace and reveals the per-circle opt-in on every circle.

[SCREENSHOT: The Applications tab in workspace settings with the Scrum / Agile card and its toggle visible.]

Step 2: Enable Scrum on a circle

Scrum is opt-in per circle so that only the teams that run sprints get the extra behaviour. A design circle and a product circle in the same workspace can both run their own sprints without interfering, while finance can stay on plain projects.

1. Open the circle.
2. Open the circle's settings panel (the gear icon).
3. Scroll to the Scrum enabled checkbox.
4. Tick it.

The circle's Projects tab updates as soon as the box is ticked.

[SCREENSHOT: A circle's admin settings panel with the Scrum enabled checkbox ticked.]

The Projects tab is your Scrum board

When a circle has Scrum enabled, its existing Projects tab becomes the Scrum board. There is no separate Scrum tab group: keeping everything on the Projects tab means a Sprint, an Epic, and a regular project (a user story not yet in a sprint) all coexist in the same place.

Three things change on the Projects tab:

• A Sprint groupBy option appears and becomes the default. Every active sprint shows as a column; user stories appear in the right column based on their Sprint field. An Epic groupBy option is also added.
• The "no sprint" group pins as a Backlog sidebar on the left of the board. Drag a story from the backlog onto a sprint column to schedule it.
• The Add button gains three options: Add a project (creates a user story), Add a sprint, Add an epic.

[SCREENSHOT: A Scrum-enabled circle's Projects tab grouped by sprint, with the Backlog sidebar on the left and active sprints as columns on the right.]

User stories

A user story is the unit of Scrum work. Each story carries:

• Sprint: the sprint the story belongs to. Empty means it sits in the backlog sidebar.
• Epic: the epic the story rolls up to. Optional.
• Points: a Fibonacci estimate (1, 2, 3, 5, 8, 13).
• Points burned: a slider from 0 to the story's points. Lets you show partial progress on a story without flipping its status.
• Type: Feature, Bug, Chore, or Spike. Default is Feature.

Stories also carry the standard project status field (Future, Current, Waiting, Done) which is what drives the sprint kanban columns and the burndown.

The userstory label implies project, so every story is also a regular project. It shows up in the rest of Nestr's project surfaces (workspace search, project reports, the role's Projects tab) the same way any other project does, and todos can hang off it as usual.

The role or circle the story belongs to is the team that owns the work. Pick it during creation in the same way you pick a parent for a regular project.

[SCREENSHOT: The user story detail view with Sprint, Epic, Points, Points burned slider, and Type fields visible.]

Sprints

A sprint is a time-boxed iteration. It carries:

• Term: start date and end date. Variable length, so a two-week sprint and a four-week sprint can live side by side.
• Sprint goal: what the team commits to within the term. Lives in the standard purpose field, re-labelled "Sprint goal".
• Capacity (points): how many points the team thinks it can finish.
• Total points: sum of the points across every story linked to the sprint. Computed automatically.
• Points burned: sum of the per-story burned values across linked stories. Also computed automatically.
• Burndown: a line chart of points remaining over the sprint term, with a gauge toggle for a single-number view.

Sprints surface in two places: as columns on the circle's Projects tab when grouped by Sprint, and as their own nests you can open for the full board and details.

Sprint nest tabs

Open a sprint to see two tabs:

User stories

The dedicated sprint kanban. Stories assigned to this sprint group into four columns by their project status:

• To do (Future)
• In progress (Current)
• In review (Waiting)
• Done (Done)

Drag a story from one column to the next to advance it. The kanban view sorts stories within a column by manual order, so you can also reorder by dragging up and down within a column.

[SCREENSHOT: A sprint with the User stories tab open, showing four columns and a handful of stories spread across them.]

Communication

Aggregates comments from the sprint itself plus every story linked to it via the Sprint field. All sprint-related conversations sit in one stream, and you can post a sprint-level comment directly here too. This is the place to track sprint-wide discussion without losing the per-story threads.

[SCREENSHOT: A sprint's Communication tab showing a mix of sprint-level comments and story-linked replies in a single stream.]

Burndown mechanics

Three fields drive the chart, two of them computed:

• Total points is the sum of the Points field across every story linked to the sprint. Recomputes when you add a story, remove a story, or change a story's points.
• Points burned at the sprint level is the sum of the per-story Points burned across linked stories. Recomputes when any of those sliders move.
• The burndown line is computed at render time from total minus burned, snapshotted across the sprint term.

Each story has its own Points burned slider. Two things drive it:

• Move the slider on the story directly to show partial progress without changing status. Half-finished work, say.
• Mark the story Done, and the slider snaps to the story's full point value. Reopen the story (status leaves Done) and the slider drops back to zero. The sprint totals follow automatically.

The chart defaults to a line view. A toggle on the chart switches to a gauge if you want a single completion ratio instead.

[SCREENSHOT: A sprint's About tab with the goal, capacity, total points, points burned (computed), and burndown line chart visible.]

Sprint end date and overdue

Sprints are not user-completable in this version. The term and the burndown tell the team where they stand; there is no "tick the box to close" step. If a sprint passes its end date without all stories in Done, it shows as overdue (red badge on the listview card, picked up by overdue filters and search) so the team gets a nudge.

Epics

An epic is a scope axis: a feature or initiative that lives longer than a single sprint. Each epic carries:

• Status: Proposed, In progress, or Done.
• Stories: every user story that has this epic set on its Epic field.

Open an epic to see its Stories tab. Stories belonging to this epic group by sprint, with a Backlog group for stories that have no sprint yet. The sprint groups are ordered by their start date, so the nearest active sprint comes first.

That layout is the whole point of epics: a single screen shows the work for this initiative that already shipped, the work that lands in the next sprint, the work that comes after that, and the work still in the backlog. Update the epic status as the initiative progresses so anyone scanning the epic list sees what is moving.

An epic also has a Communication tab that aggregates comments from the epic itself plus every linked story, the same way sprints do.

[SCREENSHOT: An epic with the Stories tab open, showing one group per sprint plus a Backlog group at the top.]

How it fits with the rest of Nestr

Scrum stories are also projects. They carry the project label in addition to userstory (via the label's implies rule), which means:

• Workspace-wide project reporting (status counts, completion, search) covers them.
• Todos can hang off a story the same way they hang off any project. The story's project status drives the kanban column on the sprint board.
• Sprints and epics created directly on a circle are tagged as that circle's own work so they don't accidentally roll up under a super-circle's view.

The same applies to circles: a Scrum-enabled circle still has Roles, Domains, Policies, Meetings, Metrics, Todos, and Notes if you have those apps on. Scrum is additive.

Customising for your team's process

Different teams run different flavours of Scrum. Three customisation patterns cover most of what teams need, all using existing Nestr label customisation, no engineering changes.

Add kanban columns by extending project status

The sprint board groups by the workspace's project status field. The default field has four options (Future, Current, Waiting, Done) which map to four columns. To add columns, add options to the project status select field in the workspace's Labels & Fields settings.

Common extensions:

• Blocked: a story that is paused on an external dependency. Add it between Current and Waiting so it does not pollute the "In progress" view.
• To release: code merged, waiting for the next deploy window. Add it between Waiting and Done. The burndown's auto-bump only fires on transitions in and out of Done, so a story in "To release" correctly does not count as burned yet.

Bring your own milestones (Gates) with a custom label

Some teams group sprints under a higher milestone: a release, a contractual Gate, a quarter. There is no native milestone object, but it composes cleanly from existing primitives:

1. Create a workspace label, eg gate, with the fields you need on it (status, definition of done, target date).
2. Add a userstory_gate graphselect field on the userstory label, pointing to label:gate. Add the same field on sprint and epic if you want to scope those to gates too.
3. Optionally use Nestr's tagAlong rules so that linking a sprint to a gate propagates the gate context to related items.

"All stories in Gate G2" is then a normal Nestr search: label:userstory fieldValues.userstory_gate:<gateId>. The Projects tab can be grouped by gate the same way it groups by sprint or epic.

Add custom fields on the Scrum labels

The userstory, sprint, and epic labels accept custom fields the same way any Nestr label does. Common additions:

• Areas involved and Areas affected multi-selects on the user story for cross-team visibility.
• External requirement IDs as a text field on the epic for traceability back to a roadmap spreadsheet or ticket system.
• Risk level as a select on the user story or epic for the team's risk register.

Tips

• Use epics for any work that spans more than one sprint. The Stories tab on an epic is the clearest progress view in the app.
• Leave a story's Sprint field empty to keep it in the backlog sidebar on the Projects tab. Filling it in moves the story onto the sprint board.
• Use the per-story burn slider for partial progress. The team gets honest mid-sprint visibility without needing a "60% done" status column.
• If you need to scale capacity mid-sprint, change the story points on individual stories. Total points and the burndown line update on their own.
• Spikes count toward total points like any other story type. If you want timeboxes to sit outside the burndown, use Chore or Bug instead, or unset the points so they don't contribute.

Common questions

Can a story belong to more than one sprint?

No. A story sits in zero or one sprint. To carry unfinished work into the next sprint, change the story's Sprint field to the new sprint.

What happens to the burndown when a sprint passes its end date?

The chart keeps plotting against the original term. Past the end date, the sprint flips to overdue on the listview. Reopening completed stories or adding new ones after the end date still updates total and burned, so the chart stays accurate.

Where does the burn slider live?

On each individual user story, between the Points and Type fields. The sprint's Points burned is a sum of those per-story sliders, computed automatically, not a slider you drag yourself.

Why doesn't the burned points field move when I drag a story onto Done?

It should. Flipping a story's status to Done snaps the story's own Points burned slider to its full point value, which the sprint's sum picks up immediately. If the story has no points, there is nothing to add, so check the story's Points field first.

Can I disable Scrum on a circle without losing the data?

Yes. Untick Scrum enabled on the circle. The Projects tab reverts to its standard form but the sprints, stories, and epics stay in the database. Tick the box again to bring the Scrum behaviour back with everything intact.

How do I see all work across a release or milestone?

Use the customisation pattern above: a workspace label for the milestone, a graphselect field on the user story, and a Nestr search or a custom Projects tab groupBy on that field.