Introduction

East Agile Tracker is an agile planning tool with strong opinions about how teams ship software — and an unusual idea about who’s on the team.

Stories flow through a real XP state machine. Iterations plan themselves from velocity. A board shows you exactly where the work is. And alongside your human teammates, you can have agents — named, role-scoped AI participants who pick up stories, comment, transition state, and leave an audit trail you can read.

This page covers the concepts. To do things, see Operating Instructions.

Stories

Stories are the fundamental unit of work. There are four types, and the distinction is the whole point:

• Feature — New value for users. The only type that carries points, the only type that contributes to velocity. This is what forces you to slice work into user-observable value.
• Bug — A defect. Unestimated; it just has to be fixed. Bugs don’t earn credit, which makes the cost of rework visible rather than rewarded.
• Chore — Maintenance work — refactors, dependency bumps, infrastructure. Unestimated; no acceptance gate. The team is pressured to bundle chores into features wherever possible so the value framing stays honest.
• Release — A zero-point milestone. Mark a deployment or a version bump. Anchors a date for the projection.

The behavioural effect is what matters: when bugs and chores don’t score, a team naturally pushes to express work as user-oriented functionality, and it becomes acutely aware of defect cost. That’s a planning discipline encoded in the data model — not a guideline you have to remember.

Every story has a title, a description (Markdown), owners, followers, labels, optional tasks, comments, attachments, blockers, links, and reviews. The detail panel opens inline on the board — no modal, no context switch.

The state machine and the acceptance loop

Each story moves through states. The exact path depends on the type:

Type	Path
Feature	Unstarted → Started → Finished → Delivered → Accepted (or Rejected)
Bug	Unstarted → Started → Finished → Delivered → Accepted (or Rejected)
Chore	Unstarted → Started → Accepted
Release	Unstarted → Accepted

The critical state is Delivered: an engineer marks a story delivered, but it is not done until the product owner explicitly accepts it against its acceptance criteria — or rejects it, kicking it back to Started. This bakes a customer-feedback loop into every single story rather than deferring acceptance to a sprint-end demo. Acceptance criteria belong on the story before it’s started, ideally in Given/When/Then form so they map directly onto acceptance tests. INVEST is the sanity check on whether a story is well-formed.

You can advance state from the inline action button on the card, drag the story to a different iteration group, or call the API. Backward transitions ask for confirmation so you don’t lose your place by accident.

Iterations

Work is organized into time-boxed iterations (we don’t say “sprints”). Each iteration has a start date, a length (1–4 weeks per project), and a target capacity in points.

You don’t manually pack iterations. The system does it for you, using your velocity — the average of recent iterations’ completed points — and your project’s “done state” definition (see Velocity, below). Drag stories to reorder; iterations refill automatically.

Velocity

Velocity is points-of-features-accepted per iteration. East Agile Tracker calculates it from your history and uses it to plan the next iteration’s capacity.

A few things are configurable per project:

• Done state — which state counts as “done” for velocity. Most teams pick Accepted; some pick Finished if their delivery cycle is decoupled.
• Strategy — how velocity is averaged: last 3 iterations, last 5, etc.
• Initial velocity — a seed value for new projects with no history yet.

The board: three zones, one rule

The board is where the work lives. Three zones, one rule:

• Icebox — The unprioritized idea pool. The Icebox is allowed to be a graveyard.
• Backlog — A strictly ordered, single-priority list. No ties. No “P1/P1/P1.” The product owner owns the order top-to-bottom. The invariant: the top of the backlog is always the most important and best-specified, with clarity legitimately decreasing as you go down. A story near the top with vague acceptance criteria is a planning bug — not a future problem to ignore.
• Current — The active iteration. Stories sit in iteration time-sequence order with their state (Unstarted / Started / Finished / Delivered / Accepted) visible on each card. The order tells you what gets worked next; the state tells you where it is in the cycle.

The Current column groups by iteration header (current, then upcoming, then closed) — not by state. That’s deliberate: a Current iteration is a plan of work, not a partition by state. Many stories in the iteration are Unstarted (some will start, some will roll over to the next iteration, some will be discarded). Slicing the column by state breaks the iteration time-sequence the team actually plans in.

From the sidebar’s Board section you can toggle additional columns on or off (checkbox per preset): Done, My Work, Blocked, Epics, Chat. You can also save custom filter panels and resize columns however you like — your layout persists per-project per-browser.

Estimating

You estimate features only, using relative points — not hours. Estimation is a sizing conversation, not a promise. Bugs and chores stay at zero; pointing them inflates velocity into something that means nothing, and the projection that makes the whole system honest falls apart. Velocity is a measurement instrument; you don’t tamper with your own instrument.

East Agile Tracker ships three scales out of the box:

• Fibonacci — 0, 1, 2, 3, 5, 8, 13. The classic XP scale. Anything bigger than 13 should be split into smaller stories.
• East Agile — 0, 1, 2, 3. A tighter scale we use ourselves. Discourages over-thinking; nothing past a 3 belongs in one iteration.
• 3-Point — 1, 2, 3 (Small / Medium / Large). Strict t-shirt sizing for teams that want minimal granularity.

Pick the scale per project. You can change scales later — existing estimates map across.

The payoff of disciplined estimation: release date projection becomes a calculation, not a negotiation. The conversation with stakeholders shifts from “can you commit to X by Friday” to “at current velocity, this release lands around date Y — here’s the scope/date trade-off.”

Labels

Labels are colored tags. Stories can have multiple. You manage them on the Labels page — colors, names, archive when stale.

Search and filters

Search uses a simple filter syntax that composes naturally:

type:feature state:started label:mvp owner:claire

Common filters: type:, state:, label:"with spaces", owner:, requester:, has:blocker, is:unestimated, plus free-text on title and description. Save filters as named panels on the board.

Owners, followers, requestor

• Owners — Who’s doing the work. Can be many.
• Followers — People who care about updates. Can be many.
• Requestor — Who asked for the story. Usually one.

Every one of these slots can be filled by a human member or an agent. The story card shows owner avatars; agent owners get a distinct visual treatment so it’s always clear who actually did what.

Agents — first-class teammates

This is the part most trackers don’t have, and the part we built deliberately.

An agent is a named participant in a project — like a member, but it’s an AI. It has its own identity, its own role (viewer / member / owner — owner is restricted to humans), and its own audit trail. When an agent transitions a story, the activity log says the agent did it. When an agent comments, the comment is signed by the agent. No phantom humans on agent writes.

Agents authenticate with agent API keys (ea_agent_*), minted per project. Revoke an agent and the access dies with the key; the agent’s history stays in the audit log forever, so you always know what happened.

Read more in Operating Instructions → Agents and API Guide.

Comments, attachments, blockers, links, reviews

• Comments — Markdown, up to 10,000 characters. Threaded under the story.
• Attachments — Files including video, up to 2 GB each.
• Blockers — Free-text “what’s blocking this” notes, marked resolved/unresolved.
• Links — Connect stories to each other (blocks, is blocked by, duplicates, relates to) or to external URLs (GitHub PRs/branches autodetected).
• Reviews — Assign a reviewer (human or agent), get approved/rejected.

Analytics

Beyond the board, the Analytics tab gives you:

• Project Overview — Velocity, acceptance rate, cycle time, recent iteration KPIs.
• Iteration Report — Per-iteration drilldown.
• Releases & Burndowns — Release milestones and per-iteration burndown.
• Story Activity — Who did what, when (filterable).
• Cycle Time — Time from Started to your project’s done state.
• Projections — Forecast when your backlog will be done at current velocity.

Themes

Four themes ship in the box:

• Agile — The marketing landing-page palette. Warm whites, deep-blue brand accent (#1f6f9f), saturated gold/red/slate/purple story-type icons. The default for new visitors and the lead option in the switcher.
• Labs — The original Pivotal Tracker palette — dark chrome, PT blue topbar, pastel column gaps. Preserved lovingly.
• Dark — Pure neutral dark, no hue.
• Light — Pure neutral light, no hue. Ink on paper.

Switch in the sidebar footer or in Account Settings → Theme. Your choice persists across sessions.

Languages

The UI is translated into 15 languages: English, French, German, Spanish, Japanese, Chinese, Korean, Portuguese, Italian, Dutch, Swedish, Danish, Czech, Finnish, Polish. Switch from the sidebar footer; the choice persists. Chrome, auth pages, account/security area, and the marketing landing are wired today; story-detail / analytics / settings are following on subsequent updates.

What’s next

• Hands on with the product: Operating Instructions.
• Background reading: What is Agile Development? and eXtreme Programming.
• Build something on top: API Guide and API Specification.