Every engineering leader we talk to at BFSI and fintech companies says the same thing when their headcount crosses 80-100 engineers: “Sprint planning used to take an hour. Now it takes a day, and half the sprint still slips.” If that sounds familiar, you’re not doing Agile wrong — you’ve just outgrown the version of Agile that works for a 15-person team.
At Speqto, we’ve run sprint cycles for lending platforms, payment gateways, and core banking integration teams where a single release touches eight to ten squads at once. Here’s what actually happens behind the scenes when sprint planning scales past the textbook version — not the Scrum Guide version, the real one.
Sprint planning stops being one meeting
At 10-15 engineers, sprint planning is one room, one backlog, one conversation. At 100+, it becomes a two-layer process:
- Program-level planning (often called PI Planning or a “sprint zero”) happens every 6-8 weeks across all squads — payments, KYC, risk engine, mobile, core banking adapters — to align on dependencies and big rocks.
- Squad-level planning happens every two weeks inside each team, where the actual stories get sized and committed.
We ran this exact split for a digital lending client whose loan origination system had six squads working against one shared underwriting API. Without the program-level sync, the risk-scoring squad kept building against a contract the API squad hadn’t finalized yet. Once we introduced a recurring cross-squad dependency review before each sprint, rework dropped noticeably within two cycles.
The backlog isn’t one backlog
In smaller teams, product owners groom a single backlog. At scale, you get a backlog per squad, tied together by epics owned at the program level. For a payment gateway client we worked with, the product team maintained epics like “Add UPI AutoPay support” at the top, and each squad (settlement, reconciliation, merchant dashboard, compliance reporting) carried its own slice of stories under that epic with its own velocity.
The trap most BFSI teams fall into here is treating epic-level deadlines as sprint-level commitments. A VP will say “UPI AutoPay ships in six weeks” without realizing that’s four squads’ worth of sprint capacity, not one team’s. Part of our job as an engineering partner is translating that business deadline into a dependency map before anyone commits a date externally.
Definition of Done gets heavier — and it should
This is where BFSI differs sharply from a typical SaaS product. A “done” story in a consumer app might mean code merged and QA passed. In a core banking or payments context, “done” usually includes:
- Security review sign-off (especially for anything touching PII or transaction data)
- Compliance checklist against RBI/PCI-DSS requirements where applicable
- Load testing for anything in the transaction path
- Audit logging verification
For one NBFC client, we added a mandatory “compliance gate” column on the sprint board itself — a story couldn’t move to Done until a compliance reviewer tagged it, not just a QA engineer. It slowed individual stories down by a day or two, but it killed the pattern of features going live and then getting pulled back for a compliance fix mid-quarter, which is far more expensive.
Velocity means something different across squads
Leadership loves asking “what’s our velocity?” as if it’s one number. At 100+ engineers, velocity is squad-specific and not comparable across teams — a mobile squad’s story points mean nothing next to a core banking integration squad’s. What matters is trend, not the raw number. We track velocity per squad over rolling 4-sprint windows and flag deviations, not absolute values. One client’s reconciliation squad showed a 30% velocity drop two sprints in a row — turned out a key engineer was pulled into incident response. That’s the kind of signal velocity is actually useful for.
Standups become asynchronous by necessity
With squads split across Bangalore, Pune, and sometimes a client’s in-house team in another time zone, daily standups stop being 15 minutes of everyone in one room. We’ve moved several clients to a hybrid model: async written updates in a shared channel every morning, with a live “scrum of scrums” twice a week where squad leads surface blockers that actually need cross-team discussion. It cuts meeting load by roughly half without losing visibility.
What actually makes this work
None of this works without a program manager or delivery lead who owns the cross-squad dependency map — because Jira and Confluence won’t catch “the risk squad is waiting on an API the payments squad hasn’t started” on their own. That’s the single biggest difference between sprint planning at 15 engineers and at 150: the tooling barely changes, but someone has to own the seams between teams.
If you’re a BFSI or fintech leader watching your sprint commitments slip as your engineering team grows, the fix usually isn’t more process — it’s clarifying who owns the dependency map and tightening your Definition of Done around compliance realities before they become production incidents. That’s the conversation we have with every client before we touch a single sprint board.
