Short answer
Small items lose because each one is compared with a big roadmap item on its own. Add up what the whole list costs in staff hours and lost deals, then give it a stream of work of its own that never competes with the roadmap, agreed with engineering up front.
Why small work always loses
Sprint planning compares items one at a time. Put an admin screen for the ops team next to the new payments system and the admin screen loses, every time, because on its own it’s smaller. But you don’t have one small item. You have thirty, and together they’re costing more than anyone has added up.
Capacity is tighter than it looks, too. Developers already spend about 30% of their time on maintenance (Sonar), so the roadmap gets what’s left, and your list gets what’s left after that.
Put a number on the list
A planning meeting won’t move for “the ops team find it annoying”. It might move for a cost. For each item, estimate who it affects and how much time it wastes:
A simple template
- Item: bulk-edit bookings in the admin tool
- Who it affects: three people in operations
- Time lost: about four hours each a week, working in spreadsheets
- Per year: 3 people × 4 hours × 46 working weeks = 552 hours
That example is illustrative. Use your own team’s numbers, and add any deals or renewals the item has held up.
Do this for the top ten items and the total usually surprises people, including the CEO.
The usual fixes, and why they fade
- “20% of every sprint for small things.” It’s the first thing cut when the roadmap slips.
- Hack days. Good for morale, bad for anything that needs finishing and supporting.
- Another hire. Not an option if headcount is flat this year.
- A separate stream of work. Small items get worked on one at a time, every week, and never compete with the roadmap. This is the one that lasts.
Get engineering on side first
Your CTO’s first worry will be another team in their codebase, and that’s a fair worry. Bring them in before anything is signed and agree:
- Which work goes to the separate stream. Admin tools, reports and integrations at the edges of the system are a good start.
- How that work is reviewed and released, so it meets the same bar as everything else.
- Who to ask when a change touches the core product.
Frame it as taking pressure off their team, because it does. The requests that interrupt their sprints are exactly the ones that move.
Ship small and see what gets used
Part of the value is speed. When a small idea can ship in days, you can put it in front of users, see whether they use it, and adjust, instead of waiting a quarter to find out it wasn’t needed.
How we help
On a subscription you get a track of your own, working through your list one task at a time. You reorder the queue whenever priorities change, with no capacity negotiations. We review the codebase before we change anything, we’re happy to work under your NDA and security policies, and a senior developer reviews every release. Embedded starts at £2,500 a month, with no headcount request. How we work with heads of product.
Questions
What sort of work suits a separate track?
Well-defined work at the edges of the system: admin tools, internal reports, partner integrations and customer tweaks. The core roadmap stays with your engineering team.
Will our CTO agree to another team in the codebase?
Bring them in early. We review the codebase before changing anything and work under your NDA and security policies, and the work they move to us is the work that interrupts their sprints.
Does it need headcount approval?
No. It’s a monthly fee that can sit in a product or operations budget, on a 12-month term.