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”?
Have you thought about it yourself?
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.
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.
Also read my previous post about 5 things bad developers say and what to do about it.