GitHub Copilot and What It Means for Estimation

Half of my development team now uses GitHub Copilot daily. The impact on individual productivity is noticeable but uneven. Some developers report finishing boilerplate tasks significantly faster. Others say it barely changes their workflow. This inconsistency creates a problem for estimation.

Our story point estimates are based on historical team performance. But if half the team is meaningfully faster on certain types of work, the historical baseline is shifting under our feet. A task that used to be a five-point story might now be a three for the developers using Copilot effectively and still a five for those who are not.

The Estimation Challenge

Story points are supposed to be relative and team-specific. If the team's capability is changing, the points should recalibrate naturally over time. But the transition period is messy. Velocity becomes unreliable as a planning input because you are comparing sprints where the team had different levels of AI assistance.

I have started tracking this informally. For the past two sprints, I have noted which stories were completed with significant Copilot assistance and which were not. The data is too thin to draw conclusions yet, but the pattern I suspect is that Copilot helps most with well-defined, repetitive implementation tasks and least with complex architectural work.

What PMs Should Do Now

Do not change your estimation process yet. The tooling is too new and the effects are too variable. But do start paying attention. Talk to your engineers about where AI assistance is saving them time. Watch for patterns in which types of stories are completing faster.

Over the next year, I expect we will need to rethink how we estimate work that involves significant code generation assistance. The traditional assumption that development effort is primarily human effort is starting to erode. PMs who understand this shift early will plan more accurately than those who ignore it.

For now, observe and document. The data will tell us when it is time to change the model.