In this case, time is being wasted.
First, you are wasting time implementing features that are not only unnecessary, but, as deemed by a coworker, bad enough to require removal.
Second, your coworker is wasting your boss's time on code matters.
The interactions suggest that something is very wrong with your development process.
- Who enters tickets into the system? Who vets and approves tickets? Who assigns them? What happens to most tickets? Who guides the development process? Whose vision is being implemented? Who is the customer?
- Why are developers going to the boss to "undo" tickets? Why aren't developers going to each other, discussing the issues, then presenting a unified face to the boss? Why aren't the developers empowered to make these decisions?
Wasted work, particularly when its not rare, is a significant problem.
I'd go to the boss and make one or more of the following points and suggestions:
- "I've implemented several tasks that were subsequently removed. How can I verify that the task I'm about to work on is useful and necessary before spending time on it? Is there a better way to assign tasks so that those tasks which my co-worker appears to know a great deal about are assigned to him, rather than me? Can we have a weekly or daily standup meeting discussing the tasks we intend to work on, so that those with particular information can chime in on a given task?"
- "Can we adjust the process so that rollbacks must be discussed among team members prior to bringing the issue to you? This should lighten your workload, and get us all on the same page."
- "Can we have each task approved by at least two developers before it is assigned to ensure tasks are useful, and any rollbacks must include discussions with those who approved it so we can make course corrections as a team, rather than individually?'
Honestly it appears there's a severe lack of communication. This could be because there's no leadership or vision.
If the above suggestions aren't taken, you can either live with it, or attempt to be the communications your team so badly needs.
Every time something like this happens - whether to you or anyone else - try one or more of the following:
- Talk to the individual who had the ticket removed. Ask them for the background as to why they had it removed. Find out if there's a conflict between the ticket and the feature list, or if it's a personal vision they have for the product.
- Talk to the person who created the ticket. Convey the information you learned in the above step and find out if they were aware of this. Ask them what feature or problem the ticket was meant to manage.
- Make sure all this information is captured in the design document(s).
Essentially you become an information hub, and you actively move information and the team's vision around so that everyone is on the same page. This can usually be done without process changes or approval, but it's time consuming.
Lastly, if you want to discourage people from removing tasks, have a lengthy conversation about the task. Bring your chair into their office, and really get into the nitty gritty with them to make sure you fully understand what's going on. Don't just accept a quick flippant answer and move on, but really show that you want to understand the overall vision and understanding you have for the project.
This accomplishes three things - one, you spend their time and eventually they'll learn that unless it's worth their time talking to you, it's probably better to let it slide. Two, you will gain their vision for the product/project, and hopefully over time they will gain your vision. Three, the relationship between you will hopefully improve and they will stop going straight to the boss, but to you.
Always be friendly and humble, but fight for what you understand the vision of the product/project to be. If it becomes obvious they are defining the project, then talking with them and disseminating that information will be your best bet at unifying the team.
Lastly, all this talking should give you an idea which tickets come by your desk that they are likely to reject. Go ask them about the ticket before working on it if it seems to be one they'd try to kill later.