The planning meeting that treats AI work like normal work

They estimated the AI feature the way they estimate everything, in story points on a two-week horizon. The feature did not fit that shape, and the plan was wrong before it started.

The planning meeting that treats AI work like normal work

An engineering manager at a fintech company told me their sprint planning kept producing plans for AI features that were wrong from the first day. They planned AI work the same way they planned everything, break it into tasks, estimate the tasks in points, fit them into a two-week sprint, commit. For normal features this worked well. For AI features it produced fantasy. The feature would breeze through the parts they had estimated as hard and then get stuck for two sprints on something they had estimated as trivial, usually the evaluation or the edge cases or getting the quality high enough on real data. The effort landed in completely different places than the plan predicted, because the plan was built on a model of where effort goes that does not describe AI work.

Estimation encodes where effort usually goes

Planning rituals carry an implicit model of how effort is distributed across a piece of work. Experienced teams estimate well for normal features because they have internalized that model, they know roughly what is hard and what is easy, so their points land close. The whole practice of estimation depends on the work matching the model the team has built from years of similar work.

AI features do not match that model, and the mismatch is not random, it is systematic. The parts that look hard in a deterministic sense, wiring up the model, building the interface, the plumbing, are often fast. The parts that look easy or do not appear in the plan at all, getting the output quality high enough on real inputs, handling the long tail of edge cases, evaluating whether it is actually good, making it reliable, are often where most of the effort and nearly all the risk live. So a team estimating an AI feature with their normal model over-weights the visible plumbing and under-weights the invisible quality work, and the plan is wrong in a predictable direction, too optimistic about the hard-looking parts and blind to the parts that will actually consume the time. The feature does not fit the two-week shape, not because the team estimated carelessly, but because they applied a model of effort that describes deterministic work to work that has a different shape.

The result is plans that miss consistently, which erodes trust in planning and, worse, hides the real risk. The evaluation and quality work that will dominate the timeline is not in the plan, so it is not resourced, not scheduled, and not visible to anyone deciding whether to commit. The team commits to a plan that omits the hard part, and then spends the sprints discovering it.

Plan AI work by its real shape

The lesson is that AI features have a different effort and risk profile than deterministic features, and planning has to reflect that instead of forcing them into the normal estimation model. The hard part is usually the quality and evaluation work, and the plan has to put it front and center.

What teams do to plan AI work honestly.

  • Weight the estimate toward quality, evaluation, and edge cases, since that is where the effort and risk actually concentrate.
  • Treat the plumbing as the fast part, so the plan does not over-invest attention in the visible, easy work.
  • Plan for iteration, since getting quality high enough is rarely a one-pass task with a predictable point value.
  • Surface the risk in the quality work explicitly, so whoever commits to the plan sees where it can go long.
  • Be honest that some AI work is hard to estimate, and plan with that uncertainty rather than a false precision.

Forcing AI work into the deterministic estimation model produces confident plans that miss. Planning by the real shape of the work produces less tidy plans that are actually true.

How we think about it at Density Labs

The plan that is wrong from day one is a common experience with AI features, and it is not a failure of the team’s estimation discipline. Their model of where effort goes is good, for the work it was built on, and AI features have a different shape, so applying the normal model produces a plan that is systematically off, optimistic about the easy-looking plumbing and blind to the quality work that will dominate. The team commits to a plan that omits the hard part.

When we help teams plan AI work, we reset the model to the real shape of the work, so the evaluation and quality effort is visible and resourced from the start instead of discovered mid-sprint. It produces plans that are less neat and far more honest.

Estimating an AI feature like a normal feature gives you a confident plan that is wrong in a predictable direction. The hard part is not where your model says it is.