Share

Can you find the 3 smells in “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.

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

Think a little, but don’t fall asleep.

Have you thought about it yourself?

Really hard?

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 had already 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?

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.

Let’s see:
– “I added a story” in my view would sound better like “I negociated with the PO to add a story”
– “Refactoring story” sounds bad. Refactoring should be continuous. If I need a story to do refactoring, then something went wrong in the recent past. I would dedicate a retrospective to this impediment.
– “Cleanup Sprint” means that I live in a dirty house for a couple of months until I had enough and I finally clean up. Sounds like I’m missing the basics of (software) hygiene.
– “Next Cleanup Spring” means for me that I had other cleanup sprints in the past. So it’s not only an isolated incident that I live in a dirty house, it happened in the past. So maybe the retrospective(s) did not cover some important aspects in the past. Something is wrong in my continuous improvement process.

– I usually train programmers, testers, system administrators, DBAs, etc to negotiate with the PO, rather than to discuss with them. That is a small, but important in my view.
– My problem with the refactoring is that it’s separate than something bringing value, not that it’s a story. It could be very well be a story or anything else.
– I liked to focus on the “software hygiene” term that I like. Unfortunately too many people consider that this is not important.
– If there were previous clean-up sprints, the main problem is at the process. The ScrumMaster should focus on guiding the team so that kind of sprint will not take place, because it won’t be needed anymore. So in my view it’s not only the problem of the team, it’s a disorder on the process side.

As for refactoring and the backlog, it depends in what situation you are:
– if you started the project, everything is nice and green, the quality is high, then of course you don’t need a PO to tell you what to refactor or not.
– if you have a project that started well, but after a while is more or less getting worse, you need to convince the PO to take some time to get back on the good track. Sometimes these things happen because of the delivery pressure. Then you need to take the time to clean-up.
– if you have an old ugly project where nobody cared about quality, then you will certainly need to negotiate with the PO where you need to apply legacy code techniques to improve the code so that in the near future it will be easier to add requirements. If you don’t do that, it is probably impossible to estimate how big a requirement is. If you take the time to clean-up before wanting to add the feature, then it’s more probable to have less error in the estimation. So in this case I will always want to negotiate legacy code improvement tasks and refactoring tasks. Thus it’s a bit tricky to use user stories in this case.

>> Of course I read it, I just wanted to give another view on the topic:
Oh I see. Thanks!

I agree with what you said and I would add the following.
The PO needs to understand 2 things:
#1 refactoring and “software hygiene” (great term!) are important and an investment in order to keep up the pace. Which means the development team is not 100% busy with features. I think 100% busyness is a bad sign anyway.
#2 sometimes taking shortcuts is OK, but this builds up “technical debt” which needs to be taken care of later.
This discussion and understanding is important.