From Backlog to Done: Tracking Real Progress

Learn how to translate plans into actionable work with granular backlog items, acceptance criteria, and status tracking that keeps you honest about what's actually getting shipped.

backlogtask-managementagilestatus-trackingacceptance-criteria

You’ve written a TRD. You’ve aligned on canvas. You’ve created a plan with Now/Next/Later priorities. Now comes the hard part: actually building it.

This is where most planning falls apart. You have a beautiful plan that says “Build authentication system” but no clear definition of what “done” looks like. Three weeks later, you’re 80% done with everything and 100% done with nothing. Demos are awkward. Stakeholders are confused. You’re drowning in half-finished features.

The problem isn’t lack of work—it’s lack of tracking. You need a system that breaks plans into actionable tasks, defines what “done” means, and keeps everyone honest about progress.

Here’s how to go from backlog to done without losing your mind.

The Anatomy of a Good Backlog Item

A backlog item isn’t just a to-do. It’s a contract: “When X is true, this task is complete.”

Here’s what separates a good backlog item from a vague wish:

Bad Backlog Item

- [ ] Implement authentication

What does “implement” mean? Email/password? OAuth? Both? What about password reset? Session management? Role-based access? You’ll spend two weeks building and still not be “done” because nobody defined it.

Good Backlog Item

## AUTH-001: Email/Password Signup Flow

**Status:** Todo
**TRD Ref:** Section 4.1 (User Authentication)
**Priority:** High
**Effort:** 3 days
**Owner:** @alex
**Dependencies:** None

### Description
Implement email/password signup with validation, bcrypt hashing, and JWT token generation.

### Acceptance Criteria
- [ ] User can POST /api/signup with email + password
- [ ] Email validation: RFC 5322 format, reject invalid addresses
- [ ] Password requirements: min 12 chars, 1 uppercase, 1 number, 1 symbol
- [ ] Passwords hashed with bcrypt (cost factor 12)
- [ ] Successful signup returns JWT (24hr expiry) + refresh token (30 days)
- [ ] Duplicate email returns 409 Conflict with clear error message
- [ ] Rate limiting: max 5 signup attempts per IP per hour
- [ ] Unit tests cover all validation rules
- [ ] Integration test covers full signup flow

### Out of Scope
- Password reset (AUTH-003)
- Email verification (AUTH-004)
- OAuth login (AUTH-005)

Now “done” is unambiguous. You can’t claim this task is complete until all nine acceptance criteria are checked. No 80%-done ambiguity.

The Five Essential Fields

Every backlog item needs these fields:

1. Unique ID (e.g., AUTH-001)

Use a prefix + number: AUTH-001, FEAT-042, BUG-015. This makes items traceable in commits, PRs, and Slack.

Why: When someone asks “Did we fix the session timeout bug?” you search BUG-023 instead of scrolling through 100 tasks.

Format: [CATEGORY]-[NUMBER] where category is AUTH, FEAT, BUG, PERF, DOCS, etc.

2. TRD Reference (What Requirement Does This Satisfy?)

Link back to the TRD section that justifies this work.

Why: Prevents orphan features. If there’s no TRD reference, ask: “Are we building something nobody requested?”

Example: TRD Ref: Section 4.1 (User Authentication)

3. Priority (High/Medium/Low)

Not everything is urgent. Be honest about what moves the needle.

High: Blocks other work, critical for launch, high user impact Medium: Important but not blocking, can ship without it initially Low: Nice-to-have, polish, future improvements

4. Effort (Time Estimate)

Estimate in days or story points. Be realistic, not aspirational.

Why: Helps with planning. If you have 2 weeks and 6 high-priority items totaling 15 days of work, something has to move to Next.

Tip: Add 50% buffer for unknowns. A “2-day task” is probably 3 days.

5. Acceptance Criteria (Testable Checkboxes)

The most important field. This is what “done” looks like.

Rules:

  • Must be specific and testable
  • Must be binary (yes/no, not “mostly works”)
  • Should include tests, error handling, edge cases
  • Should reference TRD non-functional requirements (performance, security)

Bad acceptance criteria:

  • “Authentication works”
  • “Improve performance”
  • “Make it secure”

Good acceptance criteria:

  • “POST /api/signup returns 201 + JWT token when valid credentials provided”
  • “API response time <300ms (p95) under 100 concurrent requests”
  • “Passwords hashed with bcrypt cost 12, never stored in plaintext”

How to Break Down a Plan Into Backlog Items

Your plan.md says:

## Now
- [ ] Build email/password authentication
- [ ] Add OAuth (Google, Microsoft)
- [ ] Implement role-based access control

That’s three vague bullets. Now break each into granular backlog items:

Authentication → 6 Backlog Items

  • AUTH-001: Email/password signup flow
  • AUTH-002: Email/password login flow
  • AUTH-003: Password reset via email
  • AUTH-004: Email verification challenge
  • AUTH-005: OAuth signup/login (Google)
  • AUTH-006: OAuth signup/login (Microsoft)

Role-Based Access Control → 4 Backlog Items

  • RBAC-001: Define role schema (admin, user, guest)
  • RBAC-002: Middleware: Check user role before protected routes
  • RBAC-003: Admin dashboard: Assign/revoke roles
  • RBAC-004: Audit log: Track role changes

Now you have 10 concrete tasks with clear scope. Each one can be assigned, estimated, and verified.

Status.md: The Single Source of Truth

Your status.md file is the heartbeat of the project. It answers: “What’s happening right now?”

Unlike a Kanban board (which shows task status), status.md shows project health: focus, risks, artifacts, and open questions.

Template

# Status

## Focus
What we're working on this week/sprint.

## Risks
What could derail us? What's blocking progress?

## Artifacts
Links to completed work: ADRs, docs, deployed features, reports.

## Open Questions
What's uncertain? What decisions are pending?

## Changelog
Recent updates (newest first).

Real Example

# Status

## Focus
- Completing email/password auth (AUTH-001, AUTH-002)
- Deploying to staging for security review
- Documenting API endpoints in OpenAPI spec

## Risks
- OAuth Google approval delayed (submitted 3 days ago, no response yet)
  - Mitigation: Can launch with email/password only, add OAuth in v1.1
- Bcrypt hashing slower than expected (400ms per request)
  - Investigation: Profile code, consider lowering cost factor to 10

## Artifacts
- [ADR-003: JWT Token Strategy](/.assistant/adr/ADR-003.md)
- [API Documentation (v1 draft)](https://docs.example.com/v1)
- [Security Audit Checklist](https://docs.google.com/spreadsheets/...)

## Open Questions
- Q: Should session expiry be 24 hours or 7 days?
  - Context: TRD says 24hr, but user testing suggests people expect longer
  - Decision needed by: Friday (before deployment)
- Q: Do we need CAPTCHA on signup to prevent bot abuse?
  - Research: Analyze signup patterns in beta, decide next sprint

## Changelog
- **2026-03-10:** AUTH-001 complete, merged to main (PR#42)
- **2026-03-09:** Discovered bcrypt performance issue, created PERF-001
- **2026-03-08:** Started work on AUTH-002 (login flow)

Why Status.md Works

For Solo Developers: You return to the project after a week and remember exactly where you left off in 30 seconds.

For Teams: Everyone reads one file to know what’s happening, what’s blocked, what needs decisions.

For Stakeholders: Non-technical people can check status without reading JIRA tickets or parsing cryptic commit messages.

For Onboarding: New team members read status first, then backlog, then code. They understand context before touching implementation.

Session-Based Tracking: Kickoff → Work → Wrap-Up

Every work session follows a pattern:

Session Kickoff (5 minutes)

Before you code, check:

  1. Read status.md: What’s the current focus?
  2. Pick one backlog item: What am I working on today?
  3. Update status: Add today’s focus to status.md

Do the Work (80% of session)

Build, test, commit. Reference backlog IDs in commits:

git commit -m "AUTH-001: Add email validation to signup endpoint"

Now your commit history traces back to backlog items, which trace to TRD.

Wrap-Up (10 minutes)

Before you stop:

  1. Update backlog item: Check off completed acceptance criteria
  2. Update status.md changelog: Note progress, decisions, blockers
  3. Create ADR if needed: Did you make an architectural decision? Document it.
  4. Mark complete or in-progress: Move tasks in backlog.md

This discipline prevents “I think I finished that…?” ambiguity three weeks later.

Real Example: Breaking Down a Feature

Let’s walk through implementing “Password Reset via Email.”

1. Start with Plan Item

## Now
- [ ] Password reset via email

2. Create Backlog Item

## AUTH-003: Password Reset via Email

**Status:** Todo
**TRD Ref:** Section 4.4 (Password Management)
**Priority:** High
**Effort:** 2 days
**Dependencies:** AUTH-001 (signup must exist first)

### Description
Allow users to request password reset via email with secure token-based flow.

### Acceptance Criteria
- [ ] POST /api/reset-request with email sends reset link (if account exists)
- [ ] Reset token: 32-byte random, expires in 1 hour, single-use
- [ ] Token stored in DB with user ID + expiry timestamp
- [ ] Email contains link: https://app.example.com/reset?token=...
- [ ] GET /reset?token=... validates token, shows password reset form
- [ ] POST /api/reset with token + new password updates user password
- [ ] Used/expired tokens return 400 error
- [ ] Rate limit: max 3 reset requests per email per hour
- [ ] Flash "password reset successful" message after completion

### Out of Scope
- Multi-language email templates (FEAT-099)
- SMS-based password reset (FEAT-100)

3. Work the Task

Day 1:

  • Implement POST /api/reset-request endpoint
  • Add token generation logic
  • Write unit tests for token validation
  • Commit: git commit -m "AUTH-003: Add reset token generation"

Day 2:

  • Implement POST /api/reset endpoint
  • Email integration (SendGrid)
  • Integration tests
  • Update status.md: “AUTH-003 complete, deployed to staging”

4. Mark Complete

Update backlog.md:

## AUTH-003: Password Reset via Email ✅

**Status:** Done (2026-03-11)
**Deployed:** Staging (2026-03-11), Production (2026-03-12)

Now it’s traceable. Six months later, someone asks “When did we add password reset?” You grep for AUTH-003 and find commits, status updates, deployment dates.

Common Mistakes (And How to Fix Them)

Mistake 1: Vague Acceptance Criteria

Bad: “Feature works correctly” Good: “API returns 200 status, JWT token in response body, password hashed with bcrypt”

Always be specific enough that someone else could verify it without asking you.

Mistake 2: Too Many In-Progress Tasks

Problem: 5 tasks at 80% completion, 0 tasks at 100%

Fix: Work on one task at a time until it’s fully done (all acceptance criteria met). Then move to the next.

Use status.md to enforce this: “Focus: Completing AUTH-001 before starting AUTH-002.”

Mistake 3: Never Updating Status

Status.md is useless if it’s stale. Update it at the end of every session, even if the update is: “No progress today due to production incident.”

Mistake 4: No TRD Traceability

Every backlog item should reference the TRD. If it doesn’t, ask: “Are we building something nobody asked for?”

Orphan features are the #1 source of scope creep.

Tools You Need (Spoiler: Just Markdown)

You don’t need JIRA, Trello, Asana, or Monday.com. You need:

  • backlog.md — List of tasks with acceptance criteria
  • status.md — Current focus, risks, artifacts, questions
  • plan.md — Now/Next/Later priorities
  • Git — Version control your planning alongside your code

That’s it. No expensive tools. No integrations to maintain. Just markdown files in your repo.

When you need to reference a task, link it:

See [AUTH-003](/.assistant/backlog.md#AUTH-003) for details.

When you need to track task status in commits:

git log --grep="AUTH-003"

Simple. Durable. Portable.

Try It Yourself

Pick one item from your current “Now” list. Break it into a backlog item:

  1. Assign a unique ID
  2. Reference the TRD section
  3. Set priority and effort
  4. Write 5-7 acceptance criteria (specific, testable)
  5. Note what’s explicitly out of scope

Then work it:

  • Update status.md with your focus
  • Check off criteria as you complete them
  • Commit with the backlog ID
  • Update status.md when done

That’s one complete cycle. Now do it for every task. You’ll never ask “What was I doing again?” or “Is this actually done?”

Coming in Post 5: Why We Document Decisions (And How ADRs Save Time) — Learn what Architecture Decision Records are, how to write them without slowing down, and why they prevent teams from re-debating the same decisions six months later.

Keywords: backlog management, acceptance criteria, task tracking, agile planning, status tracking, project progress