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

To sum up, does it mean that 'Refactoring' should only be a (technical) task inside a story?

My short answer: probably.

My long answer: The rule I use with my team for a new feature: if a change needed to fulfill a story requires a refactor, and that refactor needs it's own review (code, PO, UX, or otherwise) make it a task.

The article implies that this refactor may have been noticed after the fact. That's a problem of another stripe! As noted in the article, this means quality hasn't been built into the product as it should have been. In this case, a technical task isn't the answer; a discussion is.

Yes.
Refactoring is an activity to keep the inner quality high.
We as development team want to keep the quality high in order to be able to continuously deliver features, (that hopefully have an impact on someones life).

Great point about the "discussion".

As we know, "Transparency" is the foundation for Scrum Inspection and Adaption. That means that the development team should make this transparent and visible, by raising it, tracking it and discussing it.

Regarding "noticing after the fact", there are 2 things that pop in my head:
1. The development needs *courage* to bring this up. A great Scrum Master will create the safe environment where this is possible
2. The development team will constantly *learn* about technologies, practices, tools and the domain they are in, so they *might* also learn better ways how to do things.

Refactoring should be embedded in the Definition of Done. It's a good practice like TDD or CI. Doesn't a task for it. It's done within the work.

RE: Refactoring in Definition of Done.
How would you measure "Refactoring is done?".
Is improving the inner design ever done/finished?

In my experience it works better to ensure basic code hygiene by code reviews and pair programming and tooling.
Another thing that came to my mind is that the team needs to see the value of doing this.

I don't measure. Surely you can get sucked into perfection loop. :) I say "When we say PBI is done, we say we also have done refactoring if it was necessarily". Practices can not be really measured, can they?

>> Practices can not be really measured, can they?
That's the reason for not putting it on the Definition on Done :-) #evilGrin

That's they way we teach at PSM classes.
Where do you put it? It takes time. It should be transparent. Every PBI can have it. Same goes for TDD, CI, Code Review, Pair Programming.

>> Where do you put it?
What do you refer to by "it"?

Where do you put refactoring?

Refactoring is a continuous activity of the development team.

They need to ensure that they can build a useable increment every Sprint. If they are not able to because of quality, then potentially "refactoring" and code hygiene has been forgotten.

And... Yes, for larger refactorings I suggest to make that visible via technical tasks and discussions within the team.

So in case of smaller refactoring, where do you put it? :)
Something like the Boy Scout Rule? I put it in DoD.

I tend to make the Definition of Done measurable (S.M.A.R.T.) which the "Follow the Boy Scout Rule" isn't.

Can you share your DoD in your current project?

In some PBI (Story) patterns you can slice stories along acceptance criteria, to maintain a reasonable size in order to deliver a potentially releasable element of value. I would imagine most teams spend their time writing user-center function-experience PBIs, I know that a number of forums post here feels that generalized non-functional requirements should be added to the Definition of Done (like performance or targeting certain browsers, etc.) as opposed to being stories. Some refactoring can be done directly in a story. But sometimes you hit scenarios of production dependency that reveal the need for refactoring. Would you treat that like a defect? For example, we automate a test for performance in the initial story and perform some kind of load testing. Then later another PBI makes it to production and somehow added a lot of records via the other story had an unpredicted outcome of slowing down a screen load due to a long running calculation. Since the original PBI is closed, and the DoD need for performance has not changed, would it just be a defect who's solution is the act of refactoring?

I would say the Product overall is not in a Done state anymore.
What can we as a team do to:
* Fix it.
* Monitor this in the future
* Prevent it from happening again
* Share the learnings in the team and organisation

From my experience developers and even POs use the terms "Refactoring" or "Cleanup" in a vague way. This includes sometimes bug fixing and adoption to new purposes. Often it has a clear customer value or at least some business value behind. If such stories drop in, it should be clearified if we really talk about "refactoring" in a sense to improve code quality or if it is something else labeled as "refactoring" or "cleanup".

Yes, I see it the same with unexperienced teams.
And yes, bug-fixing and refactoring are 2 very different activities.
Sometimes they happen at the same time :) and I think that's warning sign, because then the team is not aware enough.

"Refactorings should always maintain existing bugs", Arlo Belshee has a great talk about that on youtube.