Add photo

Sruthy Meena

Scrum Master Agile Coach
Scrum Master · Agile Coach · Mortgage & Fintech

I don't just run ceremonies.
I fix the systems that make
delivery unpredictable.

I've worked as Scrum Master across compliance-driven mortgage ETL systems — environments where unplanned work, cross-team dependencies, and conflicting strategic priorities are the norm, not the exception.

My approach is diagnostic first. I look at delivery patterns, find where the system is leaking predictability, and design fixes that outlast my involvement. The two case studies in this portfolio show exactly how that works in practice.

2 Teams managed simultaneously
70–80% Spillover reduction achieved
2 Sprints to stable delivery
Read the case studies below
01

Managing Unplanned Work Without
Breaking Sprint Predictability

How a capacity buffer and a weekly cross-team sync reduced spillovers by 70–80% within two sprints

Mortgage ETL Snowflake · SQL Multi-team Dependency management Sprint predictability Spotfire integration
The problem
Root cause

Sprint commitments were being disrupted repeatedly — not because the team was underperforming, but because an upstream dependency was invisible at planning time. Ad-hoc requests from the Spotfire visualisation team were landing mid-sprint with no warning, no buffer, and no process to absorb them.

Frequent spillovers Eroding sprint confidence Unpredictable planning Mid-sprint scope injection
Context
System

A mortgage domain ETL platform built on Snowflake and SQL. Three teams in the ecosystem: Backend (ETL/DB), Frontend (Portal), and Visualisation (Spotfire). Work was a mix of stable planned features and frequent client-driven reporting changes.

The dependency that wasn't managed

The Spotfire team consumed outputs from the ETL/DB team for downstream reporting. When Spotfire needed something urgently, they requested it directly — bypassing the sprint process entirely and landing inside an already-committed sprint.

Diagnosis
"The delivery problem wasn't execution. It was that unmanaged external demand was being treated as a team performance issue."
  • Analysed 5–6 sprints of commit vs. delivered data — a clear pattern emerged: spillovers correlated directly with Spotfire request volume, not with story complexity or team capacity.
  • No structured channel existed for the Spotfire team to communicate upcoming needs before sprint planning.
  • Sprint planning was being run as if demand were fully predictable — with zero buffer for the known-unknown of ad-hoc requests.
  • The team was absorbing blame for a systemic process gap, not a delivery gap.
Actions taken
Short-term Stabilise delivery immediately
  • 1 Introduced a 15–20% capacity buffer during sprint planning — explicitly reserved for unplanned incoming requests. This wasn't slackness; it was an honest acknowledgement of demand reality, validated by 5–6 sprints of actual data.
  • 2 Presented the sprint history data to the PO and team to make the case. Framed it as a systemic pattern, not individual performance. This shifted the conversation from blame to process design.
Long-term Fix the dependency at source
  • 3 Established a weekly cross-team sync with the Spotfire team — a 30-minute touchpoint before sprint planning to surface upcoming dependent user stories and reporting needs.
  • 4 This sync created early visibility that allowed Spotfire requests to be planned into sprints rather than injected mid-sprint — converting unpredictable demand into manageable planned demand.
  • 5 Over time, reduced reliance on the capacity buffer as the sync matured — the buffer shrank as prediction accuracy improved. The system self-corrected once the visibility mechanism was in place.
Results
2 Sprints to stabilise commit vs. delivered consistency
70–80% Reduction in sprint spillovers
↓ Mid-sprint disruptions from external teams significantly reduced
↑ Stakeholder confidence in delivery timeline accuracy
Key insight

"Unplanned work is not always avoidable. Unmanaged dependencies are."

The combination of a short-term buffer (control the symptom immediately) and a long-term visibility mechanism (fix the root cause structurally) is a pattern I apply consistently. One without the other fails: a buffer alone becomes a crutch; a sync alone doesn't help if the team is already drowning when you install it. The sequence matters.

02

Balancing Strategic Migration with
Ongoing Product Demands

How structuring parallel workstreams and cross-skilling a developer enabled Azure migration to proceed without dropping stakeholder commitments

Azure migration Capacity planning Portal · ETL Cross-skilling Stakeholder alignment Strategic delivery
The problem
Root cause

Two legitimate, conflicting priorities arrived simultaneously on a team with limited capacity. The PO needed Azure migration completed to cut VM costs and decommission legacy infrastructure. Stakeholders needed UI enhancements — several portal features were outdated and affecting user experience. Neither could be ignored. Both required focused effort. The team had one senior developer and one fresher.

Competing valid priorities 1 senior dev · 1 fresher UI work unstructured / R&D-heavy Migration needed uninterrupted focus
Context
The migration

The mortgage platform was transitioning from VM-based infrastructure to Azure. This was a PO-driven strategic priority — cost reduction and technical debt elimination. It required sequenced, focused development work over approximately two months.

The UI demand

Stakeholders had accumulated requests for portal UI improvements. This work was non-linear and exploratory — R&D-heavy, not easily sprint-plannable, and dependent on the one senior developer who was also the primary migration resource.

Diagnosis
"This wasn't a prioritisation problem. It was a capacity and execution model problem — and those require different solutions."
  • Running both workstreams in parallel with the existing team structure would result in neither delivered well — the senior developer split between two focus areas would deliver both slowly and poorly.
  • Telling stakeholders to wait for UI enhancements until migration was complete carried significant relationship and trust risk — this had already been deferred.
  • The UI work's R&D nature meant it didn't need senior frontend expertise exclusively — it needed someone capable of frontend work with guidance available.
  • A backend developer on the team had latent frontend capability that was untapped and undirected.
Actions taken
Structural Make the migration visible and committed
  • 1 Collaborated with developers to build a sprint-wise Azure migration roadmap spanning approximately 2 months — with dependencies, sequencing, and effort distribution mapped explicitly.
  • 2 Shared this plan across stakeholders to create visibility and alignment — transforming a vague strategic intent into a trackable delivery commitment. This also protected migration from being deprioritised mid-execution.
Creative Unlock parallel capacity through cross-skilling
  • 3 Identified that a backend developer had untapped frontend capability. Worked with the PO to formally allocate this developer to handle UI enhancements — converting a single-threaded resource constraint into a two-track execution model.
  • 4 Structured ~50% senior developer support for the cross-skilled developer — enough for guidance and quality checks without pulling the senior developer's primary focus from migration. This made the cross-skilling sustainable, not a gamble.
  • 5 Framed UI work as flexible and on-demand rather than sprint-committed — matching the delivery model to the actual nature of the work. R&D-heavy exploratory work doesn't belong in the same planning box as sequenced infrastructure migration.
Results
✓ Azure migration progressed on plan without major delays
✓ UI enhancements handled continuously — stakeholders not left waiting
↑ Stakeholder alignment improved through transparent roadmap visibility
↓ Delivery risk reduced by designing parallel execution instead of competing priorities
Key insight

"Conflicting priorities are often a capacity problem wearing a prioritisation disguise."

The instinct when two priorities conflict is to force a ranking. But ranking doesn't create capacity — it just defers one problem while solving another. The real question is: can the execution model be designed so both can proceed? Here, the answer was yes — by matching resource allocation to work type, cross-skilling deliberately, and treating exploratory UI work differently from sequenced migration work. The system was redesigned, not just reprioritised.