Business Analyst / Scrum Master

Role and Responsibilities

Just Mexican Candidates. You must understand and possess experience in each of the requirements—and they must be reflected on your resume—including experience with insurance, Artificial Intelligence, and workflows for the analysis and implementation of solutions. For further information, please refer to the "How This Differs From the Traditional Role" section in this post. If this is your area of ​​expertise, do not hesitate to apply.

An embedded role on a small delivery team building production software with agentic, AI-assisted development. It converts business intent into specifications precise enough to build against, and runs the delivery cadence that keeps the team unblocked and deciding quickly. Because AI-assisted development has collapsed the cost of turning a well-understood problem into working software, ambiguity — not engineering effort — is the binding constraint on delivery.

Removing it is the core of this role.

1. Role Mandate

The mandate has two halves and both are load-bearing. The analysis half makes sure the team builds the right thing. The delivery half makes sure the team stays able to build it — unblocked, deciding weekly, and re-planning on actuals rather than defending an original estimate. The role is embedded with one team from discovery through production acceptance. There is no point at which work is handed off and accountability ends.
1. Core Responsibilities
2. Discovery and specification

– Run discovery directly with business product owners and the teams whose work the software will change. – Learn and use the business’s own vocabulary, so that specifications read as the business would state them.

– Convert ambiguous need into precise, buildable problem statements — and say plainly when a problem is not yet understood well enough to build.

– Confirm acceptance criteria consist of testable conditions that automated verification runs against, not prose requirements interpreted later.

– Own the definition of correct for each capability, including where it is contested, and drive it to a single answer.

– Leverage the platform to model the business rules, data, and object states that engineers build from.





– Maintain specifications as living artifacts through production acceptance, not milestone deliverables signed and set aside.

1. Product owner and stakeholder engagement

– Secure and protect weekly business product owner availability. – Frame decisions so they can be taken, and drive them to closure within the cycle; escalate those that stall.

– Convene direct contact between business owners and engineers rather than standing between them.

– Manage business-side expectations about continuous engagement, short cycles, and weekly acceptance decisions.

1. Delivery cadence and flow

– Run the short outcome cycles end to end: planning, review, retrospective, and the daily team cadence. – Maintain the backlog at a granularity small enough to verify continuously and traceable enough to evidence.

– Track impediments and clear them; escalate what the team cannot clear rather than absorbing it silently.

– Protect the team’s dedicated allocation and raise any erosion of it as a delivery risk.

– Manage dependencies on adjacent programs so delivery is not blocked by an unmanaged upstream commitment.

– Re-plan on actuals and report progress against delivery outcomes to program leadership.

1. Control, evidence, and audit readiness

– Support control design and application risk tiering ahead of build. – Ensure control evidence — authorship, approval, verification, deployment — is produced as a by-product of delivery rather than retrofitted for an audit.

– Maintain separation of duties in daily practice, so authorship and approval remain with different named individuals under schedule pressure.

– Keep the delivery model documented and assessable as it evolves.

1. Operating model adoption

– Document the delivery model as practiced, so it is repeatable and transferable rather than resident in individuals. – Support engineers in the shift from producing code to directing, reviewing, and accepting work.





– Capture delivery actuals — throughput, decision latency, defect origin, rework — at a fidelity that supports forward planning.

– Surface adoption resistance early. It shows up first as quiet non-participation, not as objection.

1. How This Differs From the Traditional Role

Dimension Traditional BA / Scrum Master

This role

Requirements

Documented and handed to a build team

Specified as executable acceptance criteria that automated verification runs against

Accountability

Effectively ends at handoff to build

Runs through acceptance in production

Business engagement

Gathered up front, reviewed at milestones

Continuous, with decisions taken weekly

Quality assurance

Coordinates a test phase after build

Defines correctness up front; verification runs on every change

Governance and evidence

Phase gates; evidence assembled for audit after the fact

Milestone gates; evidence a by-product of delivery

Scarce input managed

Engineering capacity

Clarity about the business problem

1. Required Skills and Experience

Requirement What it means in this role

Insurance domain fluency

Commercial and specialty P&C; — how submissions arrive and are triaged, what underwriting appetite means in practice, and how a product is structured, versioned, and distributed. Enough to hold a credible conversation with an underwriter without a translator.

Specification rigor The ability to state a business rule as a condition that is objectively testable, and the discipline to notice when a statement only appears precise.

Fluency with AI-assisted delivery

Understands that ambiguity rather than build effort is the constraint, and that a plausible-looking generated result can still be wrong for the business.

Control and audit literacy

Able to hold a substantive conversation about evidence, separation of duties, and change authorization without escalating every question.

Facilitation under compression

Running a weekly decision cycle with senior stakeholders where the cost of a deferred decision is measured in days, not months.

Seniority to hold a line

Able to tell a senior stakeholder that a specification is not ready to build, or that a decision is overdue, and make it stick.

📌 Business Analyst / Scrum Master (Ciudad de México)
🏢 Propia
📍 Ciudad de México