A backlog rots when nobody can find anything in it. The fix isn't a fancier tool. It's a simple, consistent structure that survives growth. Here's a structure that works, and why each layer earns its place.
Folders: areas, not projects-of-projects
Use folders for durable areas of work ("Billing", "Onboarding", "Infrastructure"), not for individual initiatives. Areas change slowly; initiatives come and go. Folders that mirror your areas stay stable while the tasks inside them churn.
Tasks and subtasks: one unit of work
A task should represent one shippable unit. If it needs a checklist of independently-assignable steps, those are subtasks. Resist the urge to make every checkbox a task, and resist the opposite urge to bury five real deliverables inside one giant task.
Task codes: references that don't rot
Per-workspace task codes are the quiet hero of a usable backlog. They give every item a short, stable handle you can reference in chat, a commit message or a meeting note, and trust that it still points somewhere real months later.
Sprints and releases: cadence vs. shipping
Sprints answer "what are we doing this cycle?" Releases answer "what's going out together?" They're different questions. Keeping both lets you plan in a rhythm while still grouping work by what ships, without forcing one concept to do two jobs.
Close the loop with code
The structure pays off when it connects to delivery. With GitHub sync, a commit can move a task from in-progress to done, so the board reflects reality instead of someone's memory. That's the difference between a backlog that's a source of truth and one that's a wish list.
For the bigger picture of running the whole team this way, see the one-workspace guide, or jump to the features overview.