People often struggle with these kinds of issues when starting an agile implementation because they are used to working in an environment where the “unit of execution” if an FTE (full-time equivalent person) rather than a team.

Here is the thinking process to understand how (and why) it is expected to work. Note that it is written from the perspective of a Project Manager needing status information, but the thinking applies to all kinds of external stakeholders.

• Prioritization of work is handled by the Product Owner. The Product Owner is responsible for the work order (scheduling) that the team takes on. Team members should deflect work that comes directly to them to be scheduled by the Product Owner. The reason for doing this is threefold 1) Teams (not people) are the unit of execution with agile. This allows us to leverage idea that if one person is not able to do the work, another team member can help out. 2) We don’t want individuals on teams making priority decisions (eg I am on 3 projects, which one has priority?) but rather we smooth the flow of work by going through one person for the team. 3) We want team members to focus on delivery of valuable work, not jump around from work item to work item all the time.
• When a project determines they need something by a certain date, they will work this through the Product Owner. In some cases there will be a need for a very specific date for a capability, in which case that will be part of the discussion with the Product Owner, will be captured with a target date etc and so will help determine the prioritization and scheduling of the item in relationship to other work the team has. If there is a problem with the initial scheduling, the Product Manager will know about it then. If a problem develops in terms of the execution then the Product Owner is in a position to talk about that problem and work it (see below).
• Every day there is a daily Stand-up meeting. The Product Owner attends and participates in this meeting. (S)he is therefore intimately aware of progress of work and is able to respond to queries if required.
• Team work will also be reflected in the team work management tool. In the general sense, there should be no need for a status meeting to reflect progress since the information is already available.
• If more is required, we should look at ways of streamlining this communication as much as possible. I was in a retrospective recently where one team member said they had spent 3 days out of 5 at various project meetings. Clearly if this is the case, then there is no value delivery in that time, so my question is “what can we do to provide projects what they need without requiring personal attendance at meetings?”