Skip to main content

Can you find the 3 smells in "I added a Refactoring Story for the next Cleanup Sprint?"

February 7, 2017
“I added a Refactoring Story for the next Cleanup Sprint”

This is an interesting statement. Let's see how often the alarm bell rang in your head. I mean how many smells you can find in that statement...

Before you scroll down to read my answers, please count to 10 and try to find 3 issues.


Thinking hard by 


“I added a Refactoring Story for the next Cleanup Sprint”

What would you say?



Let's see:



1. "I"

Really? You added a new story to the backlog? Did you talk to the Product Owner about it? Is it important to him? What are his responsibilities within your team? What is he accountable for? What are your responsibilities within the team? What are you accountable for?



2. "Refactoring as a Story"

First of all, the Scrum Guide (the official source for Scrum) says nothing about "User Stories". In the Scrum Guide, Jeff and Ken talk about Product Backlog Items. Everything that adds Value in the Product should go on to the Product Backlog as a Product Backlog Item. Why is the activity of refactoring a story? Should it be a task then? Does it matter to create a task for refactoring? Should you even track it somehow? What are reasons to manage 'refactoring' work? What are your skills as a developer in your team?



3. Is "Refactoring" something of value to your stakeholders?

Does the Product Owner care about Refactoring the Product? Should he? What is the responsibility of a Developer? Is "refactoring" something that just happens as described in the Boy Scout rule? Should "refactoring" just be part of your professional way of working? In another blog post, I described the Hotel Room rule and why it doesn't work.



4. A "Cleanup Sprint"?

What is a "Cleanup Sprint"? Does that mean you don't deliver anything of value in that "Cleanup Sprint"? You just do house cleaning that you haven't done before? When is your house clean enough? When do you stop cleaning? You don't know? Doesn't look very professional to me.



5. "Next"

Are you saying you already had a Cleanup Sprint?



6. "Next Cleanup Sprint"

You manage single Sprints? Are you sure? Are you adding stuff to single Sprints or to the Product Backlog? How come you put it into a Sprint and not the Product Owner who is prioritizing Backlog items?



7. Is Refactoring a Story?

What is Refactoring again?



Refactoring is the activity of changing the inner design without changing the outer behavior of the system.

What are User Stories all about?



A User Story is a placeholder for a conversation about a User need, which is about outer behavior.

So having "Refactoring User Stories" doesn't make sense. In order to be transparent about them talk to the Product Owner about them and how you visualize those.






It's your job

There are quite a couple of issues we can find in that sentence. In my eyes, it is important to highlight that refactoring is your job. It is your professional behavior. You as a professional developer build quality into the product from day 1. Refactoring is part of making sure you build the right quality. If you as a team don't do it continuously, we get in trouble soon. Building quality is something that happens all the time and the development team is accountable for a high-quality product.



What should we do in this situation?

The good thing about this statement is that someone recognized a problem with code quality and wants to fix it. The thing to improve here is the behavior around it. I would start with asking the above questions. Give feedback about what you think from your perspective and ask "How did we end up in this situation?". Check whether the process, team or surrounding organization drive this behavior.



What can we change or improve to make things better in the future?

Are there more smells in that statement?
What is your approach in dealing with this situation?
Tweet a little tweet 
@peitor or leave a comment down below.








What did you think about this post?