Backlog

A backlog is the single ordered list of work a team has decided it might do but hasn't started yet. It holds features, bug reports, technical debt, and rough ideas in one place, sorted so the most important item sits at the top. When someone finishes a task and has capacity, they pull the next item off the top — which is why a well-ordered backlog is really a continuously-maintained priority decision.

Why a backlog beats a pile of tickets

Without a backlog, work arrives from everywhere — Slack, email, support tickets, your own head — and nothing tells you what to do next. A backlog forces every incoming idea into one queue and one ordering decision: is this more or less important than the things already here? That single question, asked repeatedly, is most of what prioritization actually is.

Backlog grooming

"Grooming" (or "refinement") is the recurring act of keeping the backlog honest: re-ordering items as priorities shift, splitting vague items into concrete ones, and deleting things that no longer matter. On large teams a product manager owns this. On small teams, it's a 10-minute weekly habit — and skipping it is how backlogs become 80-item graveyards nobody reads.

How small teams should treat the backlog

For a solo developer or a team of three, the backlog should stay short enough to scan in one screen. Pair it with a lightweight priority system so the top of the list is obviously the next thing to build. If an item has sat untouched for a month, that's a signal to either commit to it or delete it — not to let it rot.

How GritShip handles this

GritShip doesn't impose a separate "backlog" object. Your first board column (typically Todo or Backlog) is the queue: cards at the top are what you'll pull next, ordered by fractional index so reordering never renumbers anything. The discipline of a short, ordered queue is built into how the board reads left-to-right, not bolted on as a separate planning surface.