Ask yourself a question, why are you creating tasks and user stories?
I can think of several possible reasons:
- You want to know the capacity of the team for future sprints
- You want to track who is working on what
- You want to track progress by seeing when tasks/stories are completed
If the IT/ops related tasks take up the same amount of time each sprint then they can be treated as an overhead when calculating capacity. Just do the work as required and expect your velocity to reflect this by being lower. There is no need to track the tasks.
If, however, you wish to track progress in the sprint then it would be worth having a new task each sprint that allows you to see when the IT/ops related work is done and by whom.
Be careful though, as I have found a lot of IT/ops tasks are related to user stories and could be wrapped in to those stories. For example, say the team rebuilds their test database when starting on a new functional area of their product. The task for this should be wrapped in to the estimate for a user story in that new functional area. That way the stories correctly reflect the work done to complete them.
