compare
Planner is usually adopted because it is already paid for. It ships inside Microsoft 365, it appears in Teams next to everything else, and nobody has to justify a new purchase. The setup that follows is often a plan per team, created by whoever needed it that week, and it works well enough until a piece of work involves three teams at once. At that point the structure underneath Planner starts to matter, and it is not the structure most people assume.
This is a guide to using Planner deliberately rather than by default, with attention to the case that breaks casual setups: work that does not belong to one team.
A Planner plan is not a standalone container. Basic plans are shared with a Microsoft 365 group, and that group is what controls who can see and edit the plan. If a team exists in Teams, a Microsoft 365 group exists behind it, and a plan attached to that team inherits its membership.
This single fact explains most of the friction people hit later.
Access is group membership, not a per plan permission list. Giving one person from another department access to a plan means adding them to the group, which also gives them the group's mailbox, its SharePoint site and its Teams channels. There is no way to grant plan only access to a basic plan shared with a group.
Deleting the group deletes the plan. Tidying up an unused team removes the plan's history with it, which is the most common way a year of task records disappears.
The plan is effectively scoped to the team, not to the project. A piece of work owned jointly by engineering and marketing has no natural home, because there is no group that means both and only those two.
Microsoft's documentation also notes that only basic plans shared with a Microsoft 365 group are eligible for conversion to premium plans, which reinforces the same point: the group is the unit Planner is built around.
Because plans live inside groups, plan names are only unique within a group and only meaningful with the group's name attached. A plan called Q3 inside the Marketing team and a plan called Q3 inside the Sales team are different objects that look identical in a list of assigned tasks. Naming plans with the work rather than the period removes this problem at no cost.
Planner is reachable from several places, and the same task looks different depending on where it is opened. Choosing one canonical route for the team prevents a recurring class of confusion.
Planner in Teams. The app inside Teams, which requires a subscription that includes Teams. This is the right default for teams already living in Teams, because it puts tasks and the conversation about them in one window.
A tab on a Teams channel. Useful when a plan belongs to one channel's work. Less useful as the only route, because plans pinned to channels are hard to find from anywhere else.
Planner on the web. The full application. Best for anyone managing several plans rather than working inside one.
The mobile apps. Planner is available on iOS and Android. In practice these are for checking and updating assigned tasks, not for restructuring a plan.
Surfaces that show Planner tasks without being Planner. Assigned tasks appear in Microsoft To Do, and Planner tasks can be shown in the Outlook calendar. A Planner web part and a full page app are available for SharePoint sites. These are display routes, and they are where the team members who will never open Planner deliberately will actually see their work.
Standardising means picking one route for creating and structuring work, and letting the others be read paths. The failure mode is three people creating plans from three different entry points and nobody knowing where anything lives.
The mechanics are quick. The conventions are what decide whether the plan is still accurate in November.
Buckets are the plan's columns. The most common mistake is using them as categories, so a plan ends up with buckets named Design, Copy and Development. That arrangement tells nobody the state of anything, because a card in the Design bucket might be untouched or finished. Buckets that name stages, such as Not started, In progress, In review, Waiting on client and Done, make the board readable at a glance, and the category can live on a label instead.
On each task, the fields worth filling consistently are narrower than the fields available. Assignments, a start date and a due date, a bucket, progress and priority are supported on tasks across plans, along with labels, a checklist and attachments. Of those, start dates are the one most often skipped and the one that matters most for cross team work, because without a start date the schedule view cannot show that two teams have scheduled the same week.
Two conventions are worth agreeing once.
One assignee per task, or an explicit owner among several. Planner allows multiple assignees, and multiple assignees reliably means nobody. If two people genuinely share the work, splitting into two tasks is clearer than sharing one.
A checklist is for steps, not for tasks. Checklist items cannot be assigned, given dates, or seen from outside the card. Anything that another person needs to do, or that has a deadline, belongs as its own task rather than a checklist line.
Planner presents the same tasks several ways, and the useful habit is choosing the view by the question rather than by preference.
Board. Who is working on what right now. This is the default and the one to keep open during a standup.
Grid. Bulk editing. Adding dates to twenty tasks is fast in a list and slow on a board.
Schedule. When things are due, laid out against a calendar. This is the view that reveals deadline collisions between teams, and it only works if start and due dates have actually been entered.
Charts. Status at a glance, by bucket, by assignee, by priority. Useful for the weekly report, less useful for running the work.
Alongside the views, filtering and grouping tasks is available across plans, and plans can be copied and exported to Excel. The export matters more than it sounds: it is the route to any analysis Planner cannot do itself, and it is available without a premium licence.
For individuals, the aggregated views are the ones that hold a cross team week together, since they collect assigned tasks from every plan rather than showing one plan at a time. Anybody working across three plans should be living in those rather than opening plans one by one.
This is the part worth reading before designing a process. A number of capabilities that project planning normally assumes are not available on a Microsoft 365 subscription alone. Premium features require a Planner premium subscription, which Microsoft lists as Planner Plan 1 or Planner and Project Plan 3.
| Capability | With Microsoft 365 licences | Planner Plan 1 | Planner and Project Plan 3 |
|---|---|---|---|
| Board and grid views, task updates | Yes | Yes | Yes |
| Dependencies between tasks | View only | Yes | Yes |
| Timeline view, meaning a Gantt chart | No | Yes | Yes |
| Goals | No | Yes | Yes |
| Sprints and backlogs | No | Yes | Yes |
| People view | No | Yes | Yes |
| Task custom fields | View only | Yes | Yes |
| Plan templates | No | Yes | Yes |
| Task history | No | No | Yes |
| Critical path | No | No | Yes |
| Assignments view | No | No | Yes |
The three absences that hurt cross team work are dependencies, the timeline view, and the people view. Dependencies are what make a slipped draft move the review that follows it. A timeline is how overlap between teams becomes visible. A people view is how anyone answers who is overloaded next week. On basic plans, all three have to be maintained by hand, in a spreadsheet, by somebody.
Whether that is acceptable depends on the work. A team running recurring operational tasks does not need dependencies. A team delivering a launch with six handoffs does, and will end up rebuilding them outside Planner if they are not available inside it.
Because plans are bound to groups, cross team work needs a deliberate choice. Three patterns are in common use, and each trades something.
A dedicated group for the delivery. Create a new team, containing only the people on this piece of work, with one plan. This is the cleanest option and the one that matches how Planner is built. The cost is proliferation: a team and a plan per initiative, and a graveyard of dead teams within a year unless somebody archives them.
A plan per team, with a shared label convention. Each team keeps its own plan, and tasks belonging to the joint delivery carry a label with the initiative's name. Nothing new is created, and each team keeps its own board. The cost is that no single view shows the whole delivery, so someone has to assemble the picture weekly, usually by exporting to Excel.
One plan for the delivery, with people added to its group. A single plan, and everyone who touches the work joins the group behind it. This gives one board for the whole initiative. The cost is that group membership carries the mailbox, files and channels with it, which is sometimes fine and sometimes a confidentiality problem.
There is no fourth pattern that avoids the trade, because the constraint is structural rather than a missing feature. Teams that find all three unsatisfactory are usually looking for a tool where board membership is independent of the organisation's group structure, which is a reasonable thing to want and a different product category. The comparisons set out how several alternatives handle that boundary.
If dependencies or a timeline are required, the upgrade path runs through plan conversion rather than a new plan. A basic plan shared with a Microsoft 365 group can be converted in place, from the plan's More menu, by adding one of the premium views such as People, Goals or Assignments and confirming the conversion.
Several details are worth knowing before starting.
The basic plan becomes read only, is archived for 90 days, and cannot be accessed during that period. Downgrading back is possible within those 90 days. After 90 days the basic plan is removed.
Conversion is not available for customers in a Government Cloud Communities environment, and plans created outside the core Planner application, including published plans and Loop task list plans, cannot be converted.
Entry points change. Premium plans render in place in Planner in Teams, while Planner on the web redirects to the premium plan in Project for the web, and the mobile apps ask the user to open the plan there instead. Anyone whose habit is the mobile app will notice this immediately.
Power Automate flows and third party integrations built against the basic plan need to be modified to work with premium plans.
Premium plans also carry hard boundaries. A project is limited to 3,000 tasks in total, a task hierarchy to 10 levels, a task to 20 predecessor and successor links combined, and a project to 150 resources. These are generous for most teams and worth checking against anything importing a large existing schedule.
One further note on history: Project for the web was retired on 1 August 2025, with most of its capabilities continuing inside Planner. Guides written before that date describe a product boundary that no longer exists, which is why older instructions and current menus often disagree.
Decide whether the work being planned needs dependencies and a timeline, and answer it before choosing a structure, because the answer determines whether basic Planner is a tool or a stopgap. If it does not, standardise on one entry point, convert buckets to stages, and require start dates. If it does, the choice is between a premium subscription and a tool where a Gantt chart, a board and a calendar over the same tasks are standard, which is the position Pinateca takes.
Not for a basic plan shared with a Microsoft 365 group. Access follows group membership, so adding a person to the plan means adding them to the group, along with its mailbox, SharePoint site and channels. Teams that need plan level access without group access generally create a separate group for that work.
The timeline view, which is the Gantt chart, is a premium feature and is not available with a Microsoft 365 subscription alone. It requires a Planner premium subscription such as Planner Plan 1 or Planner and Project Plan 3. Basic plans offer board, grid, schedule and charts views.
The plan goes with it, because the plan belongs to the Microsoft 365 group behind the team. This is the most common way task history is lost, and it usually happens during a tidy up of teams that appeared unused. Exporting the plan to Excel first preserves a readable record.
Within 90 days, yes. On conversion the basic plan becomes read only and is archived for 90 days, during which a downgrade is possible. After 90 days the basic plan is removed and the conversion is permanent.
Pick one of three structures deliberately: a dedicated group and plan for the joint work, a label convention that marks the shared initiative inside each team's own plan, or a single plan whose group contains everyone involved. The first is cleanest, the second creates no new containers, and the third gives one board at the cost of wider access.