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.




Enabling Change,

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

When can my child start learning how to code?

LeetCode September Challenge(Day-9)

My First Technical Interview

require “tty-prompt”

Reversing Zyxel VMG8823-B50B WPA algorithm generation for fun

Best place to complete your software Engineering internship .

How To Create A SQL CLR C# Project

Gamedev Log: “The Escape” #4 (Unity/C#)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Hrishikesh Karekar

Hrishikesh Karekar

Enabling Change,

More from Medium

The Scrum Ceremonies Used by Agile Teams

Agile Quickies: Deliver working software frequently

Scrum vs. Kanban = ScrumBan?

Experian Creator- Michael Hines