At least in my understanding of Agile/Scrum, there shouldn't be any cards representing code quality. There are only features that make sense to both the customer and the developer. The time to write tests and so on should be built into cost estimation of the feature.
However, as 'api' says, this tends to result in a mucilaginous mess. There really is a certain amount of work that you have to do on a project which is just about the code itself. I haven't seen any Agile method capture that in practice. A manager who listens to the developers will often suspend Agile in order to get refactorings done.
I don't think there should ever be a scheduling item for 'code quality' (and related activities) in any software development planning/management cycle. If software developers want to be treated as proper engineers at some point in time, we should start implementing quality as a default, not as an afterthought.
Therefore it stands to reason that 'code quality' should always be baked in when estimating software tasks, same goes for any other related and required development activity.
However, as 'api' says, this tends to result in a mucilaginous mess. There really is a certain amount of work that you have to do on a project which is just about the code itself. I haven't seen any Agile method capture that in practice. A manager who listens to the developers will often suspend Agile in order to get refactorings done.