Monday morning, 9:15 AM. Three project managers are pinging me simultaneously. Client A wants a prototype by Thursday. Client B has 'just a small change' (spoiler: it never is). Client C is threatening to block the next payment if a feature promised six weeks ago isn't shipped. Meanwhile, the backlog has 74 tickets nobody has touched since last week's sprint planning. That's the real state of most digital agencies. Not the clean Agile theory from conference decks.
Why Your Backlog Looks Like a Landfill
The problem isn't the volume of work. It's the absence of a shared prioritization criterion. Every PM defends their project, every client screams fire, and the lead dev navigates by whatever is bleeding most. High-impact tasks without screaming deadlines sink to the bottom of the backlog. Permanently.
I audited an 18-person agency in 2024. Their Jira backlog had 340 open tickets. Filtering by 'last comment > 60 days' surfaced 112 that nobody was looking at anymore. The CTO estimated the mental maintenance cost at 4 FTEs. Just to manage the anxiety of the list.
Methods That Actually Work
MoSCoW: Simple, but Almost Always Misused
Must have, Should have, Could have, Won't have. Everyone knows it. Nobody applies it correctly. The classic trap: clients put everything under 'Must have' because they don't understand it commits your sprint capacity. The fix: validate MoSCoW with a points budget. You have 40 points per sprint. Every Must have costs points. The client arbitrates when the budget runs out. That shift in dynamic is enormous.
RICE: The Framework I Wish I'd Known Sooner
RICE stands for Reach x Impact x Confidence / Effort. A numeric score per ticket. It sounds cold, but it kills ego-driven debates in meetings. You no longer have to convince the founder that their 'brilliant' feature is actually a Could have. The score decides. I saw one product team cut sprint planning from 2.5 hours to 45 minutes within three sprints after adopting RICE. The trick: fill in scores asynchronously on Notion before the meeting, not during.
We stopped arguing in meetings the day we let RICE scores decide, not whoever talked loudest. Our burn rate dropped 22% in two months. -- Head of Production, e-commerce agency, Lyon, 2025.
Real Capacity: The Number Nobody Calculates
Agencies plan on theoretical capacity. 5 devs x 5 days x 8h = 200 sprint hours. In practice? After standups, code reviews, unplanned client calls, and that prod bug that drops on a Tuesday afternoon, you're looking at 120 to 140 productive hours. That's 30 to 40% lost right off the top. Calculating real velocity over six rolling sprints is non-negotiable. Clynt lets you cross-reference timed hours per project with planned capacity, giving you an honest picture of the gap. Without that number, you over-commit every sprint.
Prioritizing Across Projects: The Real Agency Challenge
Intra-project prioritization is manageable. Cross-project prioritization is where it gets political. If the answer to 'who decides?' is 'whoever calls most often', you have a governance problem, not a methodology problem. A practical rule: weight by gross margin x churn risk. Low-margin projects with volatile clients drop in the pile. High-margin accounts with strategic, renewing clients rise. It stings at first. But it aligns operational decisions with actual agency strategy.
Sprint Planning: Cut the Time Without Cutting Quality
Sprint planning runs too long in 80% of agencies. Two hours to decide what to build next week is frankly absurd. If your backlog is properly prioritized with current RICE scores and known historical velocity, sprint planning should take 30 to 45 minutes. Full stop. The remaining time goes to backlog refinement, which is where estimation quality is actually built. One poorly refined ticket in sprint planning costs two unplanned days of work. Multiply by twelve bad tickets and you understand why your sprint always overruns.
- Calculate gross margin per project weekly, not quarterly
- Assign a churn risk score (1-5) to each active client account
- Multiply both to get a cross-project priority index
- Review this index in leadership every two weeks, no more
FAQ
What prioritization method works best for small agencies under 10 people?
MoSCoW with a points budget is the most accessible for small teams. It requires no specific tool and can run in a Notion doc or spreadsheet. The key is setting the rules with the client at project kick-off, not mid-sprint when tensions are already high.
How do you convince a client that their 'urgent' request isn't actually a priority?
Show them the prioritized backlog with business impact scores attached. A rational client understands that a feature touching 3 users comes after a fix affecting 800 daily orders. If your contract includes clear SLA tiers for urgency levels, it's even simpler: you apply the contract.
Should the agency's internal backlog really be separate from client backlogs?
Absolutely. Mixing both creates an implicit hierarchy where client work always wins. Your internal improvement tasks will never get space if they compete directly against client urgencies. Two separate spaces, two separate rituals, two separate time horizons.
How do you track real velocity in a multi-project agency environment?
Cross-reference hours actually logged on delivered tickets against planned capacity over six rolling sprints. Tools like Clynt visualize this gap by project and by profile, enabling future commitments based on real data rather than gut feel. Velocity by profile (junior vs senior dev) is often more actionable than aggregated team velocity.