In Scrum, the traditional role of the PM is really divided into the roles of the Product Owner and the Scrum Master, with some responsibility also falling to everyone on the Scrum team.
The Product Owner is responsible for defining the project scope, prioritizing work by maintaining the product backlog, deciding if the effort should continue into future iterations, and being involved in risk management and mitigation strategies as a representative of the user and customer. In other words, the Product Owner deals with things that happen outside the team, with regards to the user and customer, and provides a single focal point for this information.
The Scrum Master is more process and team oriented. This person manages the resources, often takes point on risk management and mitigation strategies, and deals with the process and ensuring that the people who need information but aren't on the Scrum team have access to it and visibility on the work being done and any successes and failures of the team.
Some work is delegated to the team as a whole. For example, there is no single individual providing organization and instructions - the team as a whole works with the product backlog and previous data to determine how much work to take on in a sprint. Also, risk management is another activity that falls to the whole team, with the Scrum Master facilitating the process.
Finally, some concepts don't map well to Scrum at all.
There isn't an up-front idea of the total number of iterations needed. The idea is to set a timebox on iterations (often 2-4 weeks) and have a potentially shippable deliverable that adds value. The project ends when the backlog is empty or the needs of the customer change such that funding another iteration would cost more than the value added by the work that can be done. Of course, it's not a blind idea - you know by watching the backlog and working with the Product Owner when the project is approaching a termination state.
In addition, potentially releasable software is produces no less frequently than at the completion of every sprint. The idea is that there is a value-adding product at the end of every iteration. This product has been designed, implemented, tested internally, and undergone acceptance testing. All documentation and guides associated with the product are also up-to-date. In other words, if the customer wants it, they can get it. However, they might not want to go through the effort of deploying a product at the end of every sprint, but it's an option. Because you are responsive to change, you should be able to denote an actually-shipped product in your sprint planning meeting.
It's not advisable to combine the role of Product Owner and Scrum Master because they are concerned with different things. The Product Owner is working from the perspective of the end user and the customer - deliver the most value in the least amount of time possible and demand a high quality product. The Scrum Master is team centric and provides a counter balance to ensure that the team isn't overworked, has the resources they need to do the best job, and that they are generally happy and productive people. I, personally, think that someone who is skilled enough can probably play both roles. However, it does take a skilled manager and leader to do so. There's a great deal of information about this in a Project Management Stack Exchange question about combining the roles of Scrum Master and Product Owner.
