In my experience, the word leader instills a certain image about a strong "command and control" person, who manage people into doing stuff. Words such as authority, coordination, structure and timing springs to mind. A leader is generally highly committed to the work and feels personally responsible that the task gets completed. This of course is a heavy burden to carry, especially since the leader is not the person who personally works on the task. Instead, the leader is completely dependent on his team. This can often be frustrating and some side effects of this is that pressure is added or moved on to the developers, followed by the occasional flogging (if they slack) or partying (if they success).
You don't really need that in an agile setting.
In fact, having a person on the dev team who is supposed to be a leader may instead disrupt the teams work, since the other members looks to the leader for answers instead of themselves and thus negating the effect of any self organization. Also, implementation decisions should be solved by the team during their estimation effort. If any one person on the team is regarded as a leader, he or she may sway the balance and non-technical arguments may influence the design which could lead to bad implementation.
Another problem is the need to "look good" in front of your boss. This may result in completing tasks that the leader feels is important rather than what is most important for the business right now.
Contrary to this, agile teams are self-organized. Being self-organized means that the team members themselves sign up to the tasks they want to work on and decides how they are going to do it. When you choose what do to and truly commit to it, you feel empowered, energized and take a personal interest in getting the work done. The result is increased team motivation and a much higher chance of success.
I suggest that, instead of having one person act as a leader, you let the interaction between the customer (prioritize) and the team (estimate) do its thing, preferably using the planning game. For this to work, you need the courage to trust that the framework has everything it needs to solve any problems. Some calls it "the magic of collaboration" and when it works, it is extremly powerful.
Note that the role of agile coach is nothing like this. It may be a type of leader, but their primary goal is not to control, but rather to support the team being their "servant leader" carefully helping the team to grow their skills and learn to use their abilities as best as possible.
So in short, I cannot really see what a leader could do in an agile environment.
Related to this is the cool presentation about "The amazing truth about what motivates us" which I highly recommend: