Before you create your next “refactoring story”, read this

Refactoring is Good. Refactoring Stories are Not

Scrum Masters and Agile coaches often advocate their teams to adopt refactoring; many also recommend teams to have refactoring stories and sometimes even refactoring sprints.

Refactoring is Good

Refactoring is an essential practice and fundamentally sound engineering. Code is almost always progressively improved. As a developer, I remember once having a eureka moment while having dinner. In the next 15 minutes, I logged in to my laptop and made minor changes to one of the javascript functions I was working on the entire day. The javascript function was already functional and “working.” Yet, the small abstraction I did, eliminated the necessity for an extra for loop and brought in some more modularity — without inherently changing any functionality.

As Jez Humble mentions in his tweet, the internal structure was improved while preserving the behavior.

Refactoring stories are not so good.

While refactoring is a valuable practice, can the same be said about refactoring stories and refactoring sprints? There are three fundamental reasons why I think, while refactoring is important, refactoring stories have no place on the backlog.

1. Always lose out against new features.

Refactoring stories fundamentally do not add value, and from a prioritization perspective, they will never be equal in status to a business feature. The backlog of refactoring stories constantly keeps on increasing and allocation of capacity for “refactoring stories” is often lip service.

2. Encourage lousy design with a “plan” to fix later (that rarely happens because of 1)

Teams often cut corners and make compromises ending up with spaghetti code when they shouldn’t, just because there is a fallback option to rely on a refactoring story or a refactoring sprint later in the cycle. Because of point 1, code quality drops, and the cost of change goes up, pushing teams into a vicious cycle.

3. Validation and verification of refactoring stories are either weak or very expensive.

The refactoring stories/sprints pattern is often seen in places with no TDD, and teams follow the traditional automation pyramid. The refactoring stories often do not go through the same rigor of tests as user stories. A weak validation and verification creates considerable potential for risk and could be an unintentional failure point. On the other extreme, some teams plan for “regression” after those refactoring sprints making the cost of change too high.

Instead of having refactoring stories or sprints,

• Reduce the cost (and fear) of change by implementing good TDD practices, especially automated unit tests.
• Refactor code when you are “touching” it during subsequent development
• Classify work correctly. It is a technical story, not refactoring, if you are doing a redesign/rewrite that improves non-functional parameters. Define it with a clear boundary and acceptance criteria and let it get all the attention it deserves.