We want to practice proper software engineering for our project and allocate some task to do it. Problem is, I don't know where to put it.Previously we have epic & user stories like:As a developer, we must observe proper software engineering so that we maintain efficiencyAs a developer, my code should not be merged to master without passing CI so that code base quality is maintainedA user story is a tool used in Agile software development to capture a  description of a software feature from an end-user perspective.with this definition I now unsure where to put this kind of items.Note: Developer = is not an end user role, but the one who develops the software to be used by end-users
Where to put backlog items like As a developer, ...?
agile;scrum
At the end of the day, agility is about delivering a product to the end user. If putting stories like this help your team get that done, you should do it.That being said, these are terrible stories. They have no acceptance criteria, they are not something that can be done in a single sprint. What you've written are more traditionally considered part of the definition of done. They are rules that your team has decided to follow in order to help answer the question is this story done?. If you want to put technical debt in a story, I personally think that is OK.  While you aren't end users of the product you are building, you are indeed users of the tools and practices that you use to deliver the product, and presumably, this technical debt does add some sort of business value (by making you more productive, or making it possible to deliver higher quality software, etc). Remember: visibility is one of the goals of being agile. If there's work that needs to be done by the team -- regardless of who it is for -- it needs to be visible and accounted for. Just make sure that this work is actually work with valid acceptance criteria and a clear description of the business case for the story.