Goal: One product (or a small set of products) with a shared backlog, sprint execution, and a view of “what I own this week”.
Structure
| Object | Typical mapping |
|---|---|
| Workspace | The product org or company |
| Project | Product (or Platform / Mobile / Growth if teams cannot share one board) |
| Lists | Backlog → Ready → In progress → Review → Done — or your sprint columns |
| Labels | Bug, feature, tech debt, area (API, UI) |
| My Tasks | Each engineer’s personal queue across the workspace |
If two squads must not see each other’s roadmap, split workspaces, not only labels.
Day-to-day
- PM or tech lead grooms the backlog list; ready work is pulled, not pushed, into In progress.
- Execution happens on the board. Planning discussions often happen in table (sort, scan assignees) or timeline / Gantt when dates matter.
- Bugs get a due date only when they are truly time-bound; otherwise they clutter the overdue filter.
- Watchers on a card when someone needs notifications but is not the assignee.
- Optional: AI to draft a description or checklist from a one-line title during grooming.
Engineers should open My Tasks (board/table/calendar/timeline under the workspace) every morning so they are not hunting across projects.
Reporting
- Project Dashboard for leadership snapshots.
- Time logs if you track engineering cost internally; skip timers if the culture will not run them — empty reports are worse than no report.
What usually goes wrong
- A new project per sprint. Sprints are timeboxes; they are not new products. Keep one project and use lists, labels, or due dates.
- Calendar view as the only source of truth when most cards have no dates — fill dates or stay on the board.
← All ProTask – Project Management Software with Time Tracking & Team Collaboration documentation