My simple advice on this is simple – don’t tell them.
If you let your product owner decide when a piece of refactoring work needs to be done, they will never prioritise it.
the product owner’s job is to maximise the value delivered, and refactoring doesn’t directly produce value.
Bad code and bad design are not visible outside the development team
However the effects certainly are visible. Velocity gradually dropping off over time, an increase in the number of bugs
and estimates for new features getting larger and larger.
Just factor the time in with your normal dev tasks. I’ve always taken the view that quality and maintainability are
implied features of any software I’m working on. It’s the responsibility of every developer to keep the code clean and
Even if everything is green and the feature is complete, unless
you are happy with the design – you are not done. Even if someone else made the mess – you are still not done.
If you don’t refactor, how do you know that you can refactor. By refactoring relentlessly, you can be sure your
codebase is agile, if you are constantly having to refactor your specs, are they too low-level.
The advantage of BDD’s outside-in approach is that it’s easier to take a pragmatic decision, on a spec-by-spec basis,
which level of granularity is best for the behaviour you are interested in.
Pair-programming also helps with spotting code smells. If you are not pairing, you at least do code reviews need to
get a second opinion, proof-reading, if you like, to see if someone else can read your code.
If not you need to do a bit more refactoring.