Tagline: Story points weren’t built for contractual commitments.

Description:
Defense software programs keep missing schedules, and the usual explanations are familiar: requirements churn, scope creep, contractor performance, technical debt, and shifting priorities. Those problems are real, but they often sit on top of a deeper weakness: the program never had an estimation capability worthy of the commitment being made.

Agile philosophy pushed software teams away from calendar-based predictability. Story points were created to avoid estimating software work in real development effort days. They’re subjective relative-size numbers assigned by each team, with no stable relationship to hours, days, staffing capacity, technical risk, codebase complexity, or contractor talent. A team can assign higher point values to the same amount of work and appear to increase output without delivering more capability.

That’s why measuring velocity in story points is so ineffective for defense program oversight. Velocity sounds like a delivery metric, but it’s built on a subjective unit intentionally disconnected from calendar time. Measuring how many story points a team completes each sprint gives program managers a trend line over an abstraction that was designed to avoid real estimation in the first place.

This creates a serious problem in defense acquisition. Defense programs have delivery obligations, funding constraints, milestone decisions, sustainment planning needs, and government oversight. A contractor can report improving velocity every sprint while the program remains disconnected from a credible forecast of delivery. The program manager sees motion, but not dependable schedule intelligence.

The good news is that much better software estimation performance is possible from contractors. The bad news is that many contractors may not currently have enough engineers with the talent required to produce it. Credible software estimation is a senior engineering skill. It depends on codebase knowledge, architecture familiarity, product and domain understanding, task decomposition skill, technical risk judgment, and awareness of the actual capability of the engineers doing the work.

This session introduces an engineering-based approach to software estimation using Level-of-Effort estimates in real development effort days, expressed as ranges and calibrated against real engineering evidence. It also introduces a 4-level estimation maturity model that program managers can use to assess whether a contractor’s estimates are grounded in actual engineering knowledge or are just planning artifacts with limited predictive value.

The session will show how program managers can demand better estimation capability, measure estimation accuracy over time, and make contractor estimation talent visible before and during execution. Contractors will cultivate this talent when it becomes part of how programs evaluate credibility, manage delivery risk, and hold teams accountable.

Target audience
1. Defense program managers responsible for software delivery outcomes
2. Government engineering leaders assessing contractor technical credibility
3. PMO personnel responsible for schedule, cost, and delivery oversight
4. Technical directors and chief engineers responsible for contractor performance
5. Contracting officers and acquisition professionals shaping evaluation criteria
6. Contractor engineering leaders who need to improve estimation credibility

Preferred Session Duration: 50 mins including Q&A