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

Hi, I’m Theerut Foongkiatcharoen

Uploading user files to S3 without passing through your Lambdas

Web scraping is a technique that enables quick in-depth data retrieving.

What is Terraform and How to create EC2 Instance infrastructure with Terraform ?

How to Manage “Signal” and “Noise” in Technical Documents

StopStalk: From Web App to Mobile App

Ruby: Date & Time for Dummies

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

Rebuttal of an Agile Development Naysayer

Scrum vs. Kanban vs. Shape Up

Evolution of Scrum — A Trip Down Memory Lane

Built-in Quality in Agile Development