Estimating a design-system change
The story that estimates the new component and forgets the 200 places that use the old one.
A design-system change has two scopes. The first is the system itself — the new component, the new token, the updated documentation. The second is the call-sites — every product feature that consumed the old version and needs to be migrated to the new one. The first scope is small and known. The second is what makes the work actually take a quarter.
Teams that ship the system-side change without a deprecation path ship two systems: the new one, and every place that still uses the old one. The estimate has to include the rollout — codemod or hand-migration, deprecation timeline, visual-regression strategy — or the work simply pauses there for months while feature teams get to it whenever they get to it.
What gets said in the room
Designer: "The new token is a one-line change."
Frontend: "How many components consume it today?"
Lead: "Are we doing a codemod, or are feature teams migrating themselves?"
QA: "Visual regression — Percy? Manual? Both?"
PM: "What's the deprecation window for the old version?"
Questions worth asking before voting
- How many call-sites are affected — measured, not guessed?
- Codemod or manual migration? What's the codemod's coverage?
- Deprecation path: warn, error, remove — over what timeline?
- Visual-regression coverage on the affected screens?
- Cross-team comms: who do we tell, when, and how?
- Rollback if the new component has a bug only production reveals?
Like framework upgrades, the upstream change is small and the downstream cleanup is the work. Split it. Open a session when the downstream is sized.