Estimating a framework upgrade
The story where 'bump the version' turns out to be six weeks of fixing things you didn't know were broken.
Major version upgrades aren't tickets. They're projects.
Patch versions are tickets. Minor versions are usually tickets. Major versions — the ones with breaking changes, deprecation cycles, peer-dep cascades, and "we recommend migrating to..." in the changelog — are projects, and Planning Poker isn't the right tool for sizing them. The story that says "upgrade to React 19" or "Postgres 16" is not the work; it's the wrapper around the work.
Treating the upgrade as a single estimate produces a single failure mode: the team votes 13, runs out of time in week three, and ships a half-migrated codebase that has the new framework's bugs and the old framework's idioms. The honest move is to break the upgrade into a sequence of smaller stories, each independently estimable, with the upgrade itself as the umbrella project.
What gets said in the room
Engineer: "The codemod handles most of it."
Lead: "Most of what? What does it not handle?"
SRE: "Do all our deps support the new version yet?"
QA: "What's our regression-testing strategy for the diff?"
PM: "Are we shipping anything else this sprint, or is this the sprint?"
Questions worth asking before voting
- How many breaking changes apply to our codebase — read the changelog, count?
- Do peer dependencies support the target version, or do we cascade?
- Codemod or manual? What's the codemod's coverage?
- Test coverage on the changed surfaces — adequate, or do we add tests first?
- Rollback strategy if it goes badly mid-sprint?
- One PR or many? If many, what's the dependency order?
The right output of this conversation is often "this isn't a story, it's a project — let's plan it that way." See other techniques for fuzzier or larger work, and spikes for the investigation that should precede the estimate.