Scrum doesn't need a Project Manager. In the projects I worked with, we typically give the Product Owner role to the PMs. It works fine as long as the PM takes onboard the responsibilities and limitations that come with the role.
1. he is the owner of the product back log. Basically he communicates to business and creates the user stories and adds them to the backlog. He is in charge of deciding what priority each item on the back log has. This means basically he is in a effect in charge of planning and deciding what features are developed when. (initial estimations are done with the dev team at projects I work with. We estimate in complexity points, which means you estimate how much work something is compared to another task you did. The PO then puts a time on this).
2. the product owner calculates each sprint what the available complexity points are for the team. This is done taking holidays, vacation, etc... in mind. Based on this calculated number, he makes a prioritized list of backlog items he would like done in the sprint. This is discussed with the team during the first part of the sprint meeting (at the start of the sprint). In the second part of our sprint meeting (we call it the technical sprint), our dev team typically does small analysis of the stories and divides them in tasks. We then estimate the tasks and if needed we split the tasks further (task max 2 working days or 13h actual work). Based on this we couple back to the PO what the real estimates are and he can decide to add a story or remove a story if needed. Very important: never overcommit! it doesn't work!
3. during the sprint, the team has their daily scrum meetings. All problems and questions that arise are relayed back to the PO by the Scrum Master. The PO is then responsible for providing answers on the questions. In our company we also relay things such as "we need 2 extra servers" to the PO and he talks to the responsible departments for it.
4. If for some reason extra important features are required, the PO has the possibility to halt the sprint and start a new sprint. This is an exceptional situation and should be used with care. Never start messing with the content of your sprint mid sprint: emergency break + new sprint.
Earlier I said that the PM should also take on the limitations of the PO role to make it work. With this I mean that:
1. he should stay away from the team as much as possible mid sprint. Asking "is it done?" a million times leads to frustration. If developers can concentrate for a longer period of time, you loose momentum and your velocity drops. If there are issues, the SM will inform the PO. You need a good SM that dares to say NO to the PO btw. An SM that always says "yes", will lead to contra-productive situations.
2. he should not try to (micro-)manage the project or play boss. Scrum leads to self-managing teams. It works quite fine. Interaction in the team is very important and a good mix between junior and senior members where the juniors receive coaching by the seniors is needed.
3. if working with a burndown chart, keep it away from your PO, unless he knows how to interprete it. A burndown chart is not rocket science and it surely isn't a straight line down. If the PO starts panicking when you are above the most ideal line (especially in Greenhopper where it's a straight line down, while it's actually a curved line with slow slope in the beginning and steeper at the end), it will lead to frustration, annoyance and mockery.
With kind regards,
Jeroen
