In a recent estimation exercise with a software delivery team, I cast the following assumption:
“No classes that were not directly impacted by the story being estimated would be re-engineered.”
This is an important assumption, for this team, because they tend toward boy scouting. They always want to leave the code base (camp site) better than they found it. Often, they add effort and risk to a story delivery because they want to re-engineer classes that are only marginally related to the story itself.
The most likely reason they cite for wanting to do this, is that it makes writing the unit tests for the new code required by the story easier.
The problem is that they are not refactoring the code, they are actually re-designing it. That means that the old tests no longer apply to the new design. That is not a low risk change, it is a high risk change. Moreover, often these changes are perpetrated across layers within the application, again, a high risk change.
I drew the following diagram reflecting the scope of re-engineering that we might engender during a story delivery.
The idea is that while the shortest path to done is a straight line, to the center circle, the more scope we allow in our re-engineering, the longer it takes to get to done.
So here is the illustration of the path to done, if we follow the broadest scope of re-engineering:
The distance along the nautilus shaped path is the new effort estimate. This is hard for developers to understand, sometimes. They are focused on making the code base sustainable. But there is always a balance between polishing and delivering.
The risk of defects or behavioral change introduced during a broad scope re-engineering can only be managed when the developers and testers are both very familiar with the stories and the test cases.
The right conversation needs to happen when we are deciding how far off the direct path to go, when improving the code base.