Scope creep kills budgets and timelines.

Sometimes, the encroachment is due to circumstances beyond the development team's control, such as product owners pushing for products, re-prioritized priorities, and re-revised requirements. Other times, the pain is self-inflicted!

Have you ever wandered down the rabbit hole of refactoring regret? Here's a fix! There's a fix! Suddenly, everywhere, we're fixing a fix!

How far is too far? How big is too big?

Yes, we should leave the code better than we found it. Tackle the tech debt; CLEAN it up and DRY it out. However, now might not be the right time, and I'll tell you why as we use my handy decision tree and a few real-life examples to help you and your dev team fight creepy scope.

This is a new talk for 2025 to help developers identify and manage scope creep due to refactoring. We should consider the many moving parts in an enterprise-level codebase, how a change might affect other features, and whether a time-intensive update is required now.

Objectives:
* Identify scope creep and ways it manifests (client requests, defects, priorities, refactoring)
* Develop an understanding of the potential impact of unplanned code refactors
* Use a decision tree to quickly assess the potential impact of a change and determine whether, and how, to proceed.