How AI PMs Run Effective Sprint Planning with ML Engineering Teams

Why ML Sprints Are Fundamentally Different

In a standard software sprint, the PM writes a user story, the engineer implements it, and done means the feature exists and works. The uncertainty is in scope and velocity, not in whether the implementation is theoretically possible.

ML work has a different failure mode: the experiment runs to completion, the model trains, and the result genuinely does not improve the metric you targeted. Nobody made a mistake. The experiment simply did not work. Running a software-style sprint in this context creates three persistent problems:

Sprint goals become unreviewable

If the goal is 'ship the recommendation model improvement,' a negative experiment result looks like a failure even if the team learned exactly what they needed to learn. Stakeholders cannot tell the difference between a team that ran excellent science and a team that shipped nothing.

Retrospectives turn into blame sessions

When 'done' is defined as a metric improvement and the metric did not improve, retrospectives focus on what went wrong rather than what was learned. This is demoralizing and produces the wrong behavioral incentives: ML engineers start over-claiming expected improvements to avoid accountability.

Research capacity gets eroded

Stakeholder pressure to show progress leads PMs to fill ML sprints with small, safe work (bug fixes, infrastructure, data cleanup) rather than the exploratory experiments that produce breakthrough improvements. Two quarters later, the team is busy but not advancing.

The fix is not to abandon sprints. It is to define three distinct sprint types and plan each differently.

The Three Sprint Types for ML Work

Every ML sprint falls into one of these three types. Naming the type explicitly at the start of planning forces the PM and the team to agree on what success actually looks like before the sprint begins.

Research Sprint

Definition: Open-ended investigation to answer a specific question about feasibility, architecture, or data quality. The deliverable is a written finding, not working code.

Success looks like: A clear answer to the sprint question, documented with evidence. 'We cannot improve cold-start recall without additional signals' is a valid success. 'We tried and it did not work' is not, because it does not document the evidence.

When to use: Early exploration, unknown feasibility, evaluating new approaches. Typically one to two weeks. Protect these aggressively from scope creep.

Primary artifact: Research brief: one to two pages covering the question, approach, findings, and implications for the roadmap.

Experiment Sprint

Definition: Hypothesis-driven sprint with a specific metric target, a defined experiment design, and a predetermined decision rule for interpreting the result.

Success looks like: The experiment ran to plan and produced a clean result, positive or negative. A clean negative is genuinely valuable. An inconclusive result because the experiment was under-powered is a failure of planning, not science.

When to use: When you have a specific hypothesis about an improvement and enough data to run a statistically valid test. Define the minimum detectable effect and required sample size before the sprint starts.

Primary artifact: Experiment brief: hypothesis, success metric, experiment design, minimum detectable effect, decision rule, timeline.

Deployment Sprint

Definition: Implementation work to move a validated model or experiment result into production. Behaves like a standard software sprint.

Success looks like: The model is in production serving real traffic, with monitoring in place. Standard software definition of done applies here.

When to use: After an experiment sprint confirmed a positive result and the team has decided to ship. Avoid mixing deployment work with open research or experimentation.

Primary artifact: ML model card (documenting performance characteristics), deployment checklist, monitoring dashboard spec.

Writing Sprint Goals That Survive Model Uncertainty

The most common sprint planning failure in ML is goal-writing that conflates the process commitment (run this experiment) with the outcome commitment (achieve this metric improvement). Here is how to write goals that accurately represent what the team can and cannot commit to.

The two-layer goal structure

Process commitment (the team can fully control this)

We will run experiment X using approach Y with dataset Z and document the result by Friday of week 2.

Learning objective (what the experiment is designed to reveal)

We expect to learn whether fine-tuning on domain-specific data improves precision on ambiguous queries by more than 5 percentage points.

Decision rule (what you will do with each possible result)

If improvement exceeds 5 points: proceed to deployment sprint. If improvement is 2 to 5 points: run a follow-up experiment with a larger dataset. If improvement is below 2 points: abandon this approach and explore alternative architectures.

This structure gives stakeholders visibility into what is being learned, not just what is being built. It also pre-commits the team and leadership to a decision rule so that result interpretation does not become political after the fact.

Bad ML sprint goal

"Improve recommendation click-through rate by 8% this sprint"

Commits to an outcome the team cannot guarantee. Failing to hit the number looks like team failure even if excellent science was done.

Good ML sprint goal

"Run three fine-tuning experiments targeting the cold-start cohort and document which approach achieves the best CTR lift, with a minimum sample size of 50K events"

Commits to a process, defines scope precisely, and makes the learning objective explicit.

Learn to Lead ML Teams Without the Trial and Error

The AI PM Masterclass covers cross-functional collaboration with ML teams, experiment design, and how to communicate uncertainty to stakeholders. Taught live by a Salesforce Sr. Director PM.

Running Sprint Ceremonies That Work for ML Teams

The standard Scrum ceremonies need adjustment for ML work. The adjustments are small but they change the tone of every meeting.

Sprint Planning

Name the sprint type first. Allocate time by type: research sprints run one to two weeks, experiment sprints two to three weeks (to account for training time), deployment sprints are standard two-week sprints. Confirm the experiment brief or research brief is written before the sprint starts, not during it.

Daily Standup

Replace 'what did I do yesterday' with 'what did I learn yesterday and what am I running today.' On training days where engineers are waiting for a job to complete, the standup should cover what the team expects to learn from the run, not just status. Blocked jobs are flagged immediately.

Sprint Review

Present findings, not just features. A chart showing a negative experiment result should be presented with the same care as a chart showing a shipping feature. Walk through: what we hypothesized, what we measured, what it means for the roadmap. Stakeholders should leave knowing what to expect from the next sprint.

Retrospective

Separate process retrospective from scientific retrospective. Process: did we plan well, were we blocked by infrastructure, were estimates reasonable? Scientific: was our hypothesis well-formed, was the experiment design valid, what would we do differently? A failed experiment that was well-designed is a process success, not a failure.

Protecting Research Capacity from Stakeholder Pressure

The most consistent failure mode in AI PM is allowing research capacity to erode sprint after sprint as stakeholders request increasingly specific delivery dates for improvements that have not yet been validated as achievable. Here is how to defend research time without losing stakeholder trust.

Publish a research roadmap separately from the feature roadmap

The research roadmap shows what questions the team is investigating and what decisions those investigations will unlock. Stakeholders get visibility without treating every investigation as a committed feature.

Timeboxed research sprints with hard cutoffs

Every research sprint gets a hard end date. If the question is not answered by then, the team writes up what was learned and decides whether to extend or pivot. Open-ended research is how research capacity disappears.

Frame research capacity as option value

Stakeholders understand investment language. Research sprint = buying an option on a future capability. Skipping the research sprint = attempting to exercise an option you never purchased. This framing converts research from 'not shipping' to 'protecting future roadmap flexibility.'

Make the decision gate explicit

Every experiment sprint should have a pre-agreed decision gate: the metric threshold at which the team proceeds to deployment. Stating this at planning prevents the experiment from being reinterpreted as success regardless of outcome.

The ML Sprint Planning Checklist

Use this checklist at the start of every sprint planning session. A sprint that passes all items rarely fails due to process problems.

Sprint type declared (research, experiment, or deployment)

Framing

Research or experiment brief written and reviewed before planning starts

Artifacts

Sprint goal written as process commitment, not outcome commitment

Goals

Decision rule for each experiment specified in advance

Goals

Training compute budget and timeline estimated by ML engineer

Scope

Data availability and labeling status confirmed before sprint starts

Scope

Metrics and logging infrastructure confirmed to be in place

Infrastructure

Stakeholder update scheduled for sprint review

Communication

Definition of done agreed for each sprint type

Clarity