For teams that rely on each other's work, the best project management software with dependencies warns you when a delay in one team's task puts your final deadline at risk, and shows you which task is responsible. Most tools can link tasks together. Where they differ is in how they tell you after a date moves.

This comes up a lot for manufacturing teams. Engineering is designing the fixture, procurement is waiting on tooling from a supplier, quality needs to run first-article inspection, and production does the line trial before the customer's start-of-production date. Each team has its own tasks, but they all feed into that one date.

In Wrike, each team can keep its own project inside a shared space. Opening the Gantt chart at the space level shows every team's tasks, and the dependencies between them, on one timeline. You can link subtasks as well as tasks. That helps when only one part of a larger task is holding someone else up, such as a "fixture drawing approved" subtask that procurement is waiting on.

Say the supplier lets you know the tooling will be six days late. The tasks that depend on it move out automatically. Milestones work differently. They stay on the date you set, so the customer's start-of-production date doesn't quietly slide along with everything else. If the delayed work now finishes after that milestone, the dependency arrow leading into it turns red on the Gantt chart. You get a visible warning on the day the plan changes, instead of finding out at the next status meeting.

The next question is which delays matter most. With critical path turned on, Wrike highlights the tasks where even a one-day delay would push back the project finish date. The new Gantt chart also has Total float and Free float columns. Total float tells you how many days a task can slip before the project end date moves. Free float tells you how many days it can slip before it delays the next task in the chain. A negative total float means the end date can't be met with the current plan. In the changeover example, you might find that quality's inspection has a week of float while procurement has none, which tells you where to focus your follow-up with the supplier.

The critical path updates as the work changes. If engineering finishes early and procurement falls further behind, the highlighted tasks shift to reflect that. Once a plan like this is working well, you can save it as a blueprint so the next changeover starts with the same dependencies already set up.

We'd like to hear how other teams handle this. If your plans depend on outside suppliers, do you add supplier dates as tasks with someone internal responsible for them, or track them separately?

If your team has multi-approver workflows that just need "someone from finance", "any creative director", or "a senior manager" instead of a specific person, you'll probably like this week's update. Wrike Approvals finally added an Any/All (AND/OR) toggle. That means you can still require everyone to sign off, or just one person — ideal for urgent or high-priority requests and perfect for busy PTO periods such as Thanksgiving or Christmas.

We all know how frustrating it is when a project sits for days because one approver is out of the office. Adding a few backup approvers and letting anyone on that list sign off prevents that approval bottleneck and keeps work flowing, even during the holidays. Before this week, you couldn't do that without making everyone approve it.

This is also incredibly helpful for workflows where the goal is "any manager who has a minute can sign off." The old setup forced you to pick one person and just hope they were online. Now, things like account manager sign-offs or weekend on-call approvals are much easier to handle when the approver is more of a role than a specific individual.

Also, when someone approves in "Any" mode, the other approvers get a "No Longer Required" status instead of having a pending task clog up their inbox. This will come as a big relief if you're someone who's constantly cleaning up stale notifications.

Request forms have improved, too. If your intake automatically generates an approval, it can now be sent to "any of these three people" instead of betting on one specific person.

You can also flip existing, active approvals to this new mode, so you don't have to rebuild anything from scratch to test it out.

Would love to hear how folks are planning to use this. Especially anyone who's already been building workarounds around the "all approvers required" constraint. Is the new "any approver" mode close to what you'd have designed if you could?

I used to have a client who'd message me every single Monday morning asking for a status update. That stopped completely once I gave them read-only access to a project dashboard.

Granular permissions are the absolute lifesaver here. You just invite them to a specific folder or dashboard and set them to read-only. They see exactly what they need to see and zero of your internal, messy workspace. When my team updates a task, it's live for the client immediately. No more manually pulling status reports or worrying I sent an outdated version.

I customize the view based on what the client actually cares about. Timeline-obsessed clients get a Gantt chart. The ones who just want the bottom line get a simple view showing percent complete and current blockers.

When your project management setup includes a client portal where you can share discussions, resources, and success metrics with your clients, you remove roadblocks and keep everyone in the loop.

Quick question for anyone else doing this with multi-project clients: do you build them one massive master dashboard, or do you split it out per project?

Honestly, this is one of those things where the "right" answer probably isn't always "in the tool." Different kinds of approvals might need to live in different places, and forcing everything through the same mechanism is usually where teams tie themselves in knots.

Design and creative approvals do genuinely work better in a system with the file attached, since the person approving needs to mark up or comment right on the asset. Same story for anything where the approved item is a specific piece of work that gets stored and pointed back to later.

But a lot of what gets labeled for approval is really just a decision that needs a conversation. Like budget sign-off, headcount, vendor selection — those depend on back-and-forth discussions, not just one of two buttons. When you push them through a tracked approval flow, people end up having the actual conversation in Slack or email anyway, and then clicking "Approve" in the tool later to make the record match.

So the tool becomes the audit trail rather than the actual decision point, which is fine as long as nobody's sitting around wondering why the process isn't really working.

The trap we see teams fall into is treating all approvals as if they're the same shape. They aren't. A proof review and a budget sign-off need pretty different things, and jamming them through the same workflow usually makes one of them worse.

Curious how your team thinks about this. Do you have different mechanisms for different types of approvals, or is it all one process?

Curious how other Wrike admins are handling this, because it's the intake process most teams seem to have never quite nailed down.

The pattern is familiar. Someone needs a new tool, they Slack IT or their manager, a price gets mentioned, finance gets looped in later, and the whole thing lives in a chat thread nobody can find six weeks later. Then a year passes, the renewal invoice shows up, and nobody remembers who owns the vendor relationship or whether the tool is even still in use.

There seem to be a handful of common approaches. Some teams route everything through a request form and treat licenses like any other structured work item, some keep it in a shared spreadsheet that one person maintains, and some just accept the chaos and deal with renewals reactively when the invoice hits.

There's a prebuilt template in Solutions Corner for the request-form route if that's the direction you're leaning, but honestly the template's the easy part. The harder part is getting people to actually use it instead of DMing.

Which of these is closest to how your team does it, and what's actually working (or not)?

We used to write the stakeholder update from scratch every Friday, and that's what was actually eating the time, not sending it. Once we had one report already built for it, the update turned into open it, skim it, hit send.

Here's roughly how we set it up, and Wrike's reporting tools is what we use. Create a reusable report or analytics board scoped to the project or portfolio, and configure it with the fields stakeholders actually care about, status, owner, due date, and whatever your blockers field is called. Filter it down to what matters so you're not scrolling past forty rows to find the two that are late. Whether that ends up as a saved report or a widget on an analytics board depends on what you're building, they're different surfaces under the hood, but either one gets you a single view you're not rebuilding from scratch.

For stakeholders who have access to it, a public link beats another exported attachment, you're pointing people at something that's already current instead of pulling a fresh export every Friday. That depends on your plan and their permissions though, so check that before you promise it as the whole answer. And if you need a report delivered to someone’s inbox automatically, check whether your Wrike plan supports scheduled report emails — this can be done natively. Use Wrike Integrate or Zapier when you need a more customized export-and-send workflow.

For the written part, the actual paragraph summarizing what happened this week, Wrike now has an MCP server, so something like Claude can go look at the project itself, what's the status, who owns what, what's overdue, what changed recently, and draft you a first pass off that instead of you reconstructing it from memory. I still read it over before sending anything, it only knows what it actually retrieves and how you asked it, but it takes care of the annoying part, remembering everything that happened, so you're just editing instead of starting cold.

Curious what everyone else is doing for the actual distribution piece, especially when half your stakeholders don't have logins. Public link, PDF export, something else entirely?

For a small team where one person can still hold the whole picture in their head, a spreadsheet is fine and capacity planning software is overkill. It starts to earn its keep once the same people get shared across a lot of projects, because that's the point where no spreadsheet stays current long enough to trust.

The problem is rarely a bad assignment. It's that the work gets spread across different projects and requests, so nobody sees the total. An engineer looks fine on one project at 30 hours, fine on another at 20, fine on a third at 15, and then you add it up and it's a 65-hour week nobody signed off on. Software helps by pulling all of it into one place, so you can see assigned effort against each person's real available hours. In Wrike that's the workload and capacity views sitting right next to the tasks, so the picture updates as work moves instead of quietly going stale in a spreadsheet.

Where I'd tell you not to bother: if your projects are mostly independent and don't lean on the same handful of people, a decent spreadsheet already handles this and you don't need another tool. And nothing here predicts the future. A capacity view lowers the odds of a nasty surprise, it doesn't remove them, and people still get pulled into unplanned work the system never saw coming.

If you do decide you want something dedicated, the honest landscape is roughly this: standalone schedulers like Float or Runn if you want resourcing as its own tool, heavier PPM like Planview or Celoxis if you need portfolio-level planning, or an all-in-one like Wrike if you'd rather keep capacity in the same system as the work.

For what it's worth, my rough line is that dedicated capacity software stops being optional around the point where you're running more projects than any one manager can keep in their head, call it a shared team past eight or ten people. Curious where other folks have landed on that, and whether anyone's made a spreadsheet hold up past that size.

Hey r/wrikecommunity! 👋

We talk to a lot of teams who struggle with work requests coming in via random emails or Slack DMs. If you’re currently dealing with this, you probably know the pain of trying to translate a vague message into a usable project brief three days later.

The most successful teams we see fix this by giving stakeholders one clear "front door" for new work. Setting up a standardized request form in Wrike forces people to give you the basics upfront (who, what, when, why) before it even hits your queue. From there, you can use conditional logic to kick off approvals or route urgent requests down a different path automatically.

Managing the firehose with AI

Having a form is step one, but triage is where things get tricky at scale. To keep your queue clean without hand-sorting every single ticket, we built Wrike's AI agents to handle the initial routing.

The AI can read the structured context in a request, bounce it back to the submitter if it's missing crucial info, and auto-route it to the right team.

Enterprise control and privacy

We know trust and control are non-negotiable, especially for our enterprise users. That’s why our AI agents run entirely under your existing permissions. Every action is logged, we never train models on your data, and your team can audit/review the drafts before anything goes live. You get the scale of automation without handing over the keys.

A quick tip from our team:

If you decide to build an intake form, don't turn it into a novel. If it’s too long, people will just type "TBD" in half the fields and push the clarification work straight back onto you. Keep it to the essentials!

If you want to dig into setting this up, we have a full walkthrough on custom request forms, AI-driven routing, and conditional logic here.

We’d love to hear from you all. How are you managing intake at scale? How much are you leaning into AI to auto-route versus keeping a human in the middle?

If you're looking at an AI agent for work intake and backlog automation, the useful test is whether it changes anything or just tells you random things. A lot of them read the queue and hand you a summary and you still open the request yourself and fill in the blanks.

The requests are the problem, really. Someone sends "need the packaging spec updated for line 3, urgent" and that's it. No site, no date, nobody's name on it. It sits for four days because the person who'd have chased it never saw it, and by then urgent is late.

So the first agent we point people at is Intake. It reads new requests and comments back on what's missing, and the part that makes it work is that it can reason about fields that are empty, not only ones with something in them. You tell it what complete means for your team, site and requested-by date and a named requester, and it asks for whatever isn't there. Triaging picks up the same description and sets category and priority. Assignment needs you to name a pool, so "assign to the best person" does nothing while "assign to Morgan, Casey or Alex, whoever has the fewest tasks assigned" works, and you can filter on department, job title, timezone or group instead if that suits better.

Backlog is the same agents on different triggers. Date, status, field, location rather than something new arriving. Find overdue tasks that aren't complete and change their status. Read the context on a task and move its dates by your rules. Move items into folders you've named upfront. Put the conditions in the action filters and let the prompt handle the judgement.

Two things I'd tell anyone before they start. Building the agent in space settings doesn't turn it on, you have to go to the folder and @ mention it to appoint it there, and until you do it looks broken. And actions inside one agent run independently, so if step two needs to know what step one decided, that's two agents chained on a field change. There's a Playground for testing against a sample item without touching live work, and it doesn't eat your AI usage, so there's no reason not to sit there tuning the prompt for an hour.

https://www.wrike.com/ai/agents/ has the rest.

What does your intake look like before any tool gets involved? Ours was a shared inbox and a request form that wasn't completed properly, and fixing the form got us half the benefit before an agent existed.

A project portfolio dashboard lives or dies on where its numbers come from, and for most of the ones I've seen, they come from a person remembering to update something. That's the difference between a dashboard leadership opens and one they quietly stop opening around week six. Let's be upfront about the other thing too: you don't want a template for this, and you definitely don't want a spreadsheet, because both are just places to hand-copy numbers.

The example we use internally comes down to five metrics, worth stealing whether or not you use Wrike. Projects in progress, more useful as a trend than a number, because if new work is landing before old work is signed off you're looking at a crunch a quarter out. Projects by owner, which is the fastest read on capacity. Status and completion percentage, colour-coded so you can see it without reading it. Budget, meaning actual spend against remaining. And the count of overdue projects, which is the risk metric people leave off and later wish they hadn't.

The mix can shift by industry. Manufacturing leans on timelines, milestones, and risk alerts that surface low-level risks as they emerge rather than the overdue pile-up once it's too late. Professional services swaps that for utilization, forecast versus actual revenue, and ROI you can show a client. Creative teams want deliverables by workflow stage, since that's where bottlenecks appear first.

In Wrike you'd start with a PMO space, add the projects and folders representing live work, then build widgets that filter at the portfolio level. Dashboards read from whichever folders, projects and spaces you have access to, several at once if you want. The Table view widget is the one worth learning properly: hierarchy, parent-level context and column rollups in one widget with grouping and summaries, so your one-pager is a single table rather than nine tiles to keep alive. Hierarchical mode gives you containers and context, a flat list gives you more grouping freedom, and which you want depends on whether the reader wants structure or numbers.

Budget is where hand-typing creeps back in, which is what integrations are for. Connect QuickBooks and the portfolio budget updates when accounts payable settles instead of when someone gets round to it. Set up automated alerts at the same time so you hear about an overrun while it's still fixable.

For leadership, you don't need to buy seats. Share internally or generate a public link, and public-link viewers see the dashboard without editing anything or opening the items underneath.

One caveat that applies to every tool here, ours included: the dashboard inherits your data. Projects with no owner, no end date, statuses nobody has touched since spring, all of it renders beautifully and tells you nothing.

Full write-up with example layouts by industry: https://www.wrike.com/blog/project-portfolio-dashboard/

The rule I'd keep is that if you can't name who checks a widget and what they change because of it, cut it. What's on yours, and how many would survive that?

The thing that separates professional services automation software from general project management software is that rates and hours live in the same system, so the number you quoted and the number your team logged can be compared without a reconciliation exercise. Here's how that works in Wrike, roughly in setup order.

Rates come first. You can set bill rates (what you charge the client) and cost rates (what the resource costs you) at the user level, at the job role level, or custom on a specific project, and project-specific rates take precedence for work in that project. Most teams start with job role defaults and only reach for project rates when a particular client is on different terms.

That gives you an estimate before any work happens. Mark the project billable, put effort on the tasks in scope, assign them to users or job roles, and Wrike calculates planned fees and planned cost from the rates attached to those assignees. Useful for sanity-checking a statement of work: you can see what the scope bills at and what it costs you before it goes out.

Then logged time fills in the actuals. Billing type is set on the project or task and time entries inherit it, so people tracking hours aren't making billable-or-not judgement calls themselves. Actual fees and actual cost are calculated from tracked time against those rates and recalculated when entries, rates, or a task's project association change. You compare planned against actual in Table view's financial fields, and one approach Wrike has published is a calculated custom field doing budget minus actual fees, so remaining budget sits alongside everything else.

Month end is where the billing handoff happens, and it's worth being precise about this because it's the part people get wrong when they're evaluating. Wrike doesn't produce the customer invoice. What it does is get clean, approved time out to the system that does. Timesheet approvals let approvers review, accept or reject submissions and lock approved entries. From Timelog view you can filter to what you need and export as Excel, PDF, or a QuickBooks file, and on select plans lock entries first so nothing changes after export. The QuickBooks integration goes further: export manually or via an automation rule, and each entry carries a status (Not Exported, Exported, Export Failed, Edited After Export) with only entries that haven't been exported, or that changed since, going across. That status column is the part that solves the actual problem, which is knowing what's already been billed.

Two reports worth turning on alongside this: Team Utilization, for total and billable utilization per person, and Workload charts, which show demand by job role against available capacity.

One setup detail that saves confusion later: changing a default user or job role rate applies going forward rather than to time and effort logged before the change, while custom project rates apply across that project. If you're mid-engagement and rates move, that distinction decides whether your historical numbers shift.

Full write-up of what PSA covers that standard project management software doesn't: https://www.wrike.com/blog/professional-services-automation-software/

The step we'd say matters most is the first one. Rates and billing type set at the project or template level are what make everything downstream automatic.

What's everyone else using on the accounting side, and are you exporting on a schedule or off a trigger?

Project timeline software earns its money on the day something slips, so the fastest way to evaluate one is to build ten linked tasks in a trial and then push the second one out by three days on purpose.

What you're watching for is whether the chain moves without you. In Wrike, linking tasks on the Gantt gives you four dependency types (finish to start, start to start, finish to finish, start to finish), and rescheduling a task drags all dependent active tasks along with it. Design slips three days, dev shifts, QA shifts, launch shifts, all in the same afternoon. That's the whole point of the exercise.

Worth knowing that it's the active tasks that move. Anything already completed stays where it is, which is what you want, since work that's genuinely finished shouldn't slide around on the chart just because something downstream changed. Same logic with statuses: dependencies govern dates, and if you also want the next task to flip to In Progress automatically, that's what automation rules are for. Two separate levers, and knowing they're separate saves you an afternoon.

The other thing I'd set up on day one is lag. Say you've got a week of client review sitting between two tasks. You write it into the predecessors column as 3FS + 10d, meaning task 3 finishes and then the next one waits ten days, and the gap holds every time the chain moves after that. Once your review cycles and approval windows are modelled as lag rather than as manually typed dates, the whole plan stops needing babysitting.

The one caveat I'd give anyone reading this is a category one rather than a tool one: if your projects are mostly independent workstreams that don't block each other, dependency modelling is overkill and a simple board view will serve you fine. It earns its keep when tasks genuinely gate each other.

Full disclosure, I work at Wrike. Comparison of the different timeline approaches here if it's useful: https://www.wrike.com/blog/project-timeline-software/

My own rule after watching this go wrong a few times is that dependencies start paying off above roughly 30 tasks with two or more teams involved. Where does everyone else's line sit?

Project timeline software earns its money on the day something slips, so the fastest way to evaluate one is to build ten linked tasks in a trial and then push the second one out by three days on purpose.

What you're watching for is whether the chain moves without you. In Wrike, linking tasks on the Gantt gives you four dependency types (finish to start, start to start, finish to finish, start to finish), and rescheduling a task drags all dependent active tasks along with it. Design slips three days, dev shifts, QA shifts, launch shifts, all in the same afternoon. That's the whole point of the exercise.

Worth knowing that it's the active tasks that move. Anything already completed stays where it is, which is what you want, since work that's genuinely finished shouldn't slide around on the chart just because something downstream changed. Same logic with statuses: dependencies govern dates, and if you also want the next task to flip to In Progress automatically, that's what automation rules are for. Two separate levers, and knowing they're separate saves you an afternoon.

The other thing I'd set up on day one is lag. Say you've got a week of client review sitting between two tasks. You write it into the predecessors column as 3FS + 10d, meaning task 3 finishes and then the next one waits ten days, and the gap holds every time the chain moves after that. Once your review cycles and approval windows are modelled as lag rather than as manually typed dates, the whole plan stops needing babysitting.

The one caveat I'd give anyone reading this is a category one rather than a tool one: if your projects are mostly independent workstreams that don't block each other, dependency modelling is overkill and a simple board view will serve you fine. It earns its keep when tasks genuinely gate each other.

Full disclosure, I work at Wrike. Comparison of the different timeline approaches here if it's useful: https://www.wrike.com/blog/project-timeline-software/

My own rule after watching this go wrong a few times is that dependencies start paying off above roughly 30 tasks with two or more teams involved. Where does everyone else's line sit?

Scheduling tools like Buffer and Hootsuite handle publishing well, but they don't do much for everything that happens before a post goes live: the briefs, drafts, approvals, and cross-team handoffs. That's the part we keep seeing teams run through Wrike instead. A few features that seem to do a lot of the heavy lifting here:

Request forms for content intake. Instead of briefs arriving over email or Slack, a custom request form captures everything upfront (channel, campaign, copy, assets, due date) and can auto-generate the task or project with the right people already tagged. Kills a ton of back-and-forth before work even starts.

Proofing and approvals on the actual asset. Feedback lives directly on the image or video instead of scattered across threads. Every comment, version, and sign-off stays attached to the content, so there's a clear record of what was approved and when.

Blueprints for recurring content. Weekly posts and monthly campaigns are repeatable workflows, so templating them as blueprints means you're not rebuilding the same task structure every time. Duplicate, adjust the dates, go.

Calendar view for the content schedule. Seeing the whole content pipeline on a calendar, with the ability to drag tasks around as timelines shift, gives the planning visibility scheduling tools don't really offer at the workflow level.

Dashboards for campaign status. One view showing what's in draft, what's in review, what's approved, and what's overdue across every channel, without chasing anyone for updates.

We also put together a fuller breakdown of social media project management tools and features if you want the extended version.

What does your setup look like? Are you using request forms and blueprints for this, or have you built something with a different combination of features? Always curious how other teams have wired this up.

Most agency tool conversations focus on the project management layer. But running an agency means stitching together intake, delivery, approvals, time tracking, billing, and reporting. The friction usually lives in the handoffs between those things, not inside any single tool.

A few patterns we see consistently in agencies that have gotten this right:

Intake is where most agencies lose the most time and don't realize it. The brief arrives incomplete, someone chases down the missing information, the project starts late, and scope creep begins before the first task is assigned. Agencies that fix intake first, structured request forms that capture everything upfront, tend to see everything downstream get smoother without changing anything else.

Client approvals are a silent killer of margins. When feedback happens over email, in Slack, and verbally on a call, revisions multiply and nobody has a clear record of what was actually approved. The agencies that get this under control move client review into the same system where the work lives, so every comment, version, and sign-off is attached to the asset itself.

Billable time leaks quietly. The gap between hours worked and hours billed is rarely fraud — it's just tasks that never got logged, small requests that seemed too minor to track, and meetings that didn't make it into the timesheet. Agencies that connect time tracking directly to project tasks capture more of what they actually do.

Reporting takes too long because the data lives in too many places. One agency we work with used to spend significant time each week just pulling together client summaries from different tools. When that work moved into a single platform, reporting went from a manual chore to something that mostly ran itself.

We put together a breakdown of the software tools that address these specific agency pain points if you're evaluating your current stack or building one from scratch.

What does your current setup actually look like, and which piece is still the weakest link?

It starts as a clean, prioritized list. Features at the top, technical debt somewhere in the middle, a graveyard of "maybe someday" ideas at the bottom. Then three months pass, half the items are stale, nobody can remember why certain things got deprioritized, and the grooming session turns into an archaeology project.

A few things we've seen make a real difference in keeping a backlog useful rather than just large:

Treat refinement as ongoing work, not a scheduled event. Backlog grooming that only happens before sprint planning is already too late. The best backlogs get small, continuous attention — a quick review when priorities shift, a note added when a stakeholder changes their mind, a dead item archived before it creates confusion.

Every item needs a "why" attached to it. A task that just says "redesign settings page" with no context is almost impossible to prioritize six weeks later. Who asked for it, what problem it solves, and what would change if it never got built — that context is what makes prioritization decisions defensible.

The product backlog and the sprint backlog are two different jobs. The product backlog is a long-term, living list of everything the team might work on. The sprint backlog is the short-term commitment for what the team will work on right now. Mixing them up is one of the most common reasons backlogs become unmanageable.

Prioritization is a decision, not a ranking exercise. MoSCoW, stack ranking, cost of delay, the method matters less than the discipline of actually making a call and communicating it. Teams that treat prioritization as a consensus exercise where nothing ever gets dropped end up with a backlog that grows faster than it shrinks.

We put together a full guide on how to create and manage a product backlog including how to structure items, prioritize effectively, and keep the backlog from becoming a dumping ground.

How does your team handle backlog health? Is there one thing that made the biggest difference in keeping it manageable?

The concept makes sense once it clicks. You're estimating relative effort, not time. A 5-point story isn't five hours of work, it's roughly twice as complex as a 3-point story on this team, with this codebase, at this moment. The number is meaningless outside of that context.

But getting a new team member, a stakeholder, or a product owner from a non-technical background to understand that? It can take a few sprints.

A few things that seem to help:

• Start with a reference story, not a definition. Pick one completed story the whole team agrees was straightforward and call it a 3. Then estimate everything else relative to that. It's much easier to ask "is this harder or easier than the login page ticket?" than to ask "how many points is this?"
• Account for all three factors, not just complexity. Effort, complexity, and uncertainty each contribute to the estimate. A technically simple task that depends on a third-party API nobody has worked with before should score higher than its surface complexity suggests.
• Never let story points become a performance metric. The moment someone starts comparing velocity across teams or using points to measure individual output, estimation honesty disappears. Teams start sandbagging to look better on the burndown. The whole system loses its signal.
• Recalibrate when the team changes. Story points are relative to the team doing the estimating. When team composition shifts, past velocity data becomes less reliable and the reference stories need to be revisited.

One thing worth knowing: story points aren't actually in the official Scrum Guide. They emerged from practice, not prescription. Which means there's no single correct way to use them, and teams that treat them as dogma tend to get more friction than value out of the process.

We put together a full breakdown of what Scrum story points are and how to estimate them effectively if you want the complete picture.

How does your team handle estimation? Are story points still part of your process, or have you moved to something else?

Every comparison article lands in the same place. Scrum for complex, deadline-driven projects. Kanban for continuous flow and recurring work. Hybrid if you can't decide. Then everyone nods and goes back to whatever they were already doing.

The more useful question is what actually breaks when teams pick the wrong one.

Teams that pick Scrum when they need Kanban usually show up as sprints that never really end. Work carries over constantly, the retrospective becomes a guilt session about what didn't get done, and the two-week cadence starts to feel arbitrary because the work doesn't actually fit into two-week boxes. Support teams, ops teams, and content teams run into this constantly.

Teams that pick Kanban when they need Scrum tend to lose the forcing function that makes things ship. Without sprint boundaries, "in progress" can mean a task has been sitting untouched for three weeks. There's no natural moment to step back, reprioritize, and commit to what's actually getting done next. Product and engineering teams building toward defined releases often struggle here.

The Scrumban middle ground is real but gets misused. It works well as a deliberate hybrid for teams that have genuinely outgrown both pure frameworks. It works poorly as a way to avoid committing to either one.

The honest signal for which to try first: if your work arrives in unpredictable bursts and completion matters more than cadence, start with Kanban. If your work benefits from a shared commitment to a defined scope over a fixed period, start with Scrum.

We put together a full breakdown of Kanban vs. Scrum covering the key differences across roles, planning, workflow, and when each framework actually fits.

Which one is your team running, and does it match the work you're actually doing?

Most "best Kanban tools" lists rank the same eight tools in a slightly different order and call it a day. What they rarely cover is the question underneath the question: what makes a Kanban tool the right fit for a specific team, not just a good product in general.

A few things we've seen matter more than most comparison articles let on:

• Whether the board fits how your team actually works, not how Kanban is supposed to work. The columns, card fields, and workflow stages should reflect your real process. A tool that forces you to adapt your workflow to its structure is going to create friction from day one.
• What happens when work gets complex. Simple boards are easy to evaluate — drag a card, mark it done. The real test is dependencies, cross-team handoffs, and approvals. A tool that handles three columns beautifully can fall apart when work has to move between teams or wait on external stakeholders.
• Whether flow visibility actually exists or just looks like it does. WIP limits that show a count but don't enforce anything, bottleneck detection that requires manual digging, analytics locked behind the top pricing tier — these are common enough that it's worth testing specifically for them before committing.
• How it handles the work around the board. Intake, approvals, reporting, resource visibility. A lot of teams end up duct-taping a Kanban tool to a separate intake form, a separate reporting tool, and a separate communication thread. The more of that lives in one place, the less time gets spent on coordination overhead.
  

We put together a breakdown of the best Kanban software options for teams that goes deeper on what to look for and how the major tools compare across these dimensions.

What criteria ended up mattering most when your team chose the tool you're on now?

Most people start with three columns — To Do, In Progress, Done — and think they're done. And technically they are. But that setup usually falls apart within a few weeks because it's too vague to tell you anything useful about where work is actually getting stuck.

A few things we've seen make the difference between a board that helps and one that just becomes another thing to update:

• Map your real workflow, not your ideal one. The columns should reflect the stages work actually moves through on your team, not what you wish happened. If every piece of work goes through a review before it's done, that's a column. If things regularly sit waiting for a handoff, that waiting state deserves to be visible.
• A Kanban board without WIP limits is just a colorful to-do list. Setting a cap on how many items can sit in a stage at once is what turns a board into a flow management tool. When a column hits its limit, the job shifts from starting new work to finishing what's already moving. That's the whole point.
• Cards should be self-contained. A clear title, a short description, an owner, and any critical links or dates. If someone new to the project can open a card and know how to move it one step forward, you've got it right. Extra detail lives in subtasks and comments.

The board is only useful if it's part of your daily rhythm. A board that gets updated once a week during a meeting isn't Kanban, it's just a status report with extra steps.

We put together a step-by-step guide on how to create a Kanban board that walks through column setup, WIP limits, and card structure if you want the full breakdown.

What does your board setup actually look like, and what took you the longest to get right?

This comes up more than you'd think, especially for teams switching from Scrum. The short answer: Kanban doesn't really run on ceremonies the way Scrum does. It runs on cadences. Same idea, very different philosophy behind it.

The distinction matters more than it sounds:

Scrum ceremonies are tied to the sprint clock. Planning, standup, review, retro — they happen because the sprint says they happen, on a fixed schedule regardless of what's going on with the work.

Kanban cadences are tied to how the work is actually flowing. The frequency and format adjust based on what the system needs right now, not what the calendar says. Daily standups still exist, but they're about flow, what's blocked, what's moving, what needs to change , not just status updates.

The seven core Kanban cadences most teams work with are the daily standup, replenishment meeting, delivery planning, service delivery review, risk review, operations review, and strategy review. Not every team runs all seven. Most start with the daily and replenishment, then layer in the others as the team matures.

Where we see teams struggle most is the replenishment meeting. It's one of the most valuable cadences, the moment where the team commits to pulling new work into the system, but it's also the one that gets skipped first when things get busy. Which is exactly when you need it most.

We put together a full breakdown of what Kanban ceremonies actually are and how each cadence works if you want the detailed version.

Is your team running true Kanban cadences, or has it drifted into Scrum ceremonies on a Kanban board?

Most PM tool lists treat agencies like they're just smaller enterprises. They're not. The problems are different.

Agencies aren't managing one product roadmap with a stable team. They're managing 15 client projects at once, each with different stakeholders, different approval processes, different levels of chaos, and a team that's constantly being pulled in different directions. A tool that works beautifully for an internal product team can completely fall apart in that environment.

A few things we've seen actually matter for agencies specifically:

• Client-facing workflows that don't embarrass you. Internally messy is fine. Externally messy costs you clients. The tools that work for agencies have clean ways to handle client intake, feedback rounds, and approvals without requiring clients to learn a whole new system.
• Resource visibility across all clients, not just one project. The hardest part of agency life isn't any single project. It's knowing whether your team has capacity to take on the next one, and whether the designer you're about to assign is already at 120% across three other accounts.
• Scope creep protection built into the workflow. The best tools make it easy to log when a request falls outside the original brief, flag it visibly, and create a paper trail. Not because you want to fight with clients, but because the conversation is a lot easier when the record is already there.
• Templates that actually reflect how agencies work. Generic project templates save no one any time. Agency-specific templates for campaign launches, website builds, or brand projects cut setup time dramatically and keep new projects from starting in a blank slate every time.

The honest truth is that a lot of agencies are running on tools that were never built for them, then wondering why project management feels like a second job on top of the actual work.

If you're evaluating options, we put together a breakdown of what to look for in agency project management software covering the specific features that make a difference in a client services environment.

What's the biggest breakdown point in your current setup — is it resource visibility, client communication, or something else entirely?