Planner: boards, views and tasks
Your studio's tasks: boards, views, tags, priorities, due dates.
No integration to connect. Planner works from the moment the organisation is created, and it is usually the first screen a team opens.
Boards
Planner. A board groups a body of work: a sprint, a workstream, an app.
On creation, a Kanban view is generated automatically - an empty board with no view would be useless.
| Action | Effect |
|---|---|
| Duplicate | Copies the board and its views |
| Set as default | This board opens when you land on Planner |
| Delete | Removes the board and its views. The tasks are not deleted |
That last point is worth reading twice: a board is a way of looking at tasks, not a container. Deleting it destroys nothing.
Views
The same board is looked at in three ways, and a board can carry several views in parallel.
| View | Good for |
|---|---|
| Kanban | The workflow, column by column |
| List | Quick scanning, sorting, dense reading |
| Calendar | Due dates, load over time |
Every view carries its own configuration:
- Group by - status, priority, assignee, tag
- Filter by - status, priority, assignee, tag, project
- Show on the card - the fields visible without opening the task
Two views of the same board can therefore show very different things: a Kanban grouped by status for the morning stand-up, a list filtered on "urgent" for the review.
Tasks
A task carries:
| Field | Values |
|---|---|
| Status | To do, In progress, In review, Done, Cancelled |
| Priority | Urgent, High, Medium, Low |
| Assignee | A member of the organisation |
| Project | One of the studio's apps, or none |
| Due date | A date |
| Tags | As many as needed |
It also carries a formatted description, comments, attachments and sub-tasks.
The Project field is what ties team work to the apps: filtering on a project gives everything in progress on that app, across all boards.
Deletion
Deleting a task sets it aside; it can be restored from the deleted tickets. Only a draft being written is lost for good, and the interface says so beforehand.
Tags
Planner → Settings → Tags.
Tags are organised into sets, each set configured as single choice or multiple choice.
This is the part people usually get wrong. A "Area" set in single choice (iOS, Android, API, Design) forces a decision, and makes grouping readable. A "Context" set in multiple choice accepts several labels. Putting everything into one bag of free tags gives you, after a month, an unmanageable list.
Deleting a tag removes it from every task that carried it. Permanent.
Tutorial - starting a sprint board
- Planner → New board, name it "Current sprint".
- Set it as default: it is the one the team should see on arrival.
- On the generated Kanban view, group by status.
- Add a second List view, filtered on Urgent priority: Monday's review happens on it.
- Create an "Area" tag set in single choice, with one entry per part of the product.
- Create the tasks, assign them, set the due dates. The Calendar view then shows whether the week is feasible.
Coming
Sprints (planning, team velocity) are announced in the product but not shipped yet.