如果按照思维定式来考虑已有的Scrum框架，项目中本没有敏捷项目经理（Agile PM）这样的角色。而在另 一些敏捷方法中——例如特征驱动开发（FDD）人们仍然依仗项目经理（PM）。但项目经理的角色已更多转变 为负责项目行政方面，而非负责协调开发团队及其活动方面，或是处理资源问题方面（也远非项目管理知识体 系——PMBOK中所描述的传统意义上的项目经理）。仍旧以特征驱动开发（FDD）为例，以上描述的是开发经理 的职责而不一定是项目经理的职责。在战术层面上，敏捷项目经理应该比普通项目经理看得更远，站在战略层 面考虑问题。敏捷项目经理不仅应该具备传统项目经理的各项技能，还必须对快节奏、充满变数的敏捷项目及 其框架有所见解。
我们可以把敏捷项目经理看成具备多项技能的专业人士，在一定需求下他具备的技 能能够使他同时胜任项目中多个角色。从Scrum框架考虑，这些角色可以是客户产品负责人（PO）及Scrum Master。例如，在我们的某个项目中，敏捷项目经理在一个Sprint中是Scrum Master，而在下个Sprint中则转 变成产品负责人。根据不同需求，敏捷项目经理必须可以胜任Scrum Master或产品负责人的角色，而不是去取 代这个角色。敏捷项目经理能够凭借自身的项目管理专长胜任任意一个角色（客户的产品负责人及开发团队的 Scrum Master），哪里需要支持，敏捷项目经理就能出现在哪里，永远以达到项目最佳产出为目的。
在敏捷软件开发项目的课程中，人们常常把Scrum Master描述成“敏捷流程的负责人”，他会确保团队正确运 用Scrum及敏捷框架进行开发。当我们考虑近岸开发项目时，由于近岸开发的特点——大多数时候开发团队和 产品负责人分布在不同的国家，我们更倾向设多个负责人。这样一来，每个区域的负责人都有责任保证自己团 队的进度，从而满足项目的整个日程。举例来说，Scrum Master和敏捷项目经理可以协同工作共同领导项目， 带领团队前进。同样，因为客户的业务合作伙伴往往不和开发团队在同一区域工作，敏捷项目经理将更多地与 合作伙伴确认需求，保证项目向正确方向前进。从这方面看，敏捷项目经理代表着客户，他的工作将确保团队 满足流程要求并在一定程度上左右近岸开发项目的成败，因此这个角色也变得至关重要。敏捷项目经理的另一 职责是协调分布在不同区域的团队。由于项目成员分散，文化也存在差异，不一定都能习惯 “自上而下的沟 通方式”，敏捷项目经理将帮助团队成员消除沟通障碍以保证项目顺利实施。
敏捷项目经理的职责包 括（但不局限于）：挑选合适的团队成员（人事），提供指导和辅导，与产品负责人协商产品Backlog的开发 ，与项目团队协商产品Backlog的创建流程，创建、执行并对项目的日程和成本预算进行监控，负责项目的现 金流及付款通知，负责沟通，负责风险应对计划以及采购管理等等。
特别是在协作方面，敏捷项目经 理将负责主持项目的启动会议，也会按需安排其他的项目会议。敏捷项目经理还会负责为项目干系人及团队成 员提供口头的或正式的项目状态报告，并负责为项目文档进行定期更新与归档（例如，企业的项目管理办公室 要求按照标准提供相应的项目文档，我们就该在Backlog中加入创建这些文档的story）。
敏捷项目经 理还应当具备以下三种能力：辅助客户的产品负责人将企业愿景转换成开发团队能够理解的语句（例如，运用 价值工程（Value Engineering）的方法创建并维护排序后的产品Backlog）；帮助Scrum Master确保产品负责 人正确行使权利（译注：帮助Scrum Master顶住来自客户的压力）；协助Scrum Master确认客户和开发团队的 工作都符合敏捷流程。
敏捷项目经理如何工作
想要完全了 解敏捷项目经理的工作，我们可以举一个财富50强制药公司的例子。公司有过一个软件开发项目，该项目由包 含Scrum Master的近岸开发团队负责，团队遵循Scrum原则逐步完成Backlog项。这个团队包括不同背景的三名 开发人员（有擅长写代码的，有擅长网站设计的，有擅长数据库的等等），一名测试员及一名软件架构师。我 们将敏捷项目经理与产品负责人共同看作项目的“核心成员”，他们在同一地点办公，但与开发团队分处不同 的区域。整个项目历时66天，由5个迭代组成。
项目首先由团队称作“Sprint 0”的4天热身阶段开始 。在这阶段中，团队一边评审客户创建的需求文档及估计的时间线，一边耐心等待客户讨论决定应用的基础设 施。“Sprint 0”阶段的一个目标是通过客户、敏捷项目经理及开发团队之间的充分讨论，理清业务逻辑的问 题，保证大家在这方面达成共识。
在此后为期16天的Sprint中，敏捷项目经理在协调日常沟通方面扮 演着举足轻重的角色。这包括为团队妥善安排主持每日例会，安排好与客户的晨会，检查Backlog确保每项工 作都能按时按质完成，辅导Scrum Master预见可能的未知障碍。诚然，典型的Scrum项目认为开发团队有能力 追踪Backlog并按时完成任务。但在这个项目中，近岸团队发现由于客户与团队之间的地域阻隔，设敏捷项目 经理这样一个角色在追踪项目任务完成状态方面更能发挥优势。
我要指出的重要一点是，正如传统的 Scrum Master一样，在这个项目中敏捷项目经理也不会亲自完成任何一项任务，我们的开发团队有自我组织的 能力处理所有分配的任务。例如，Backlog中的有些任务非常复杂当开发人员感到单靠自己能力无法完成时， 开发人员会自发地向软件架构师寻求帮助。同样，开发人员在除了本职工作外还会完成诸如单元测试，系统测 试及回归测试（互相测试对方的代码）等额外的工作。他们自愿帮助测试人员完成原本属于测试范畴的工作。 这表明团队能够相互照应并意识到“边际力量”的重要性，并为着达成组织架构层面上的敏捷程度而共同努力 。
每个Sprint的第一天通常会包含一个计划环节。在该环节中，开发团队会把从产品Backlog中得到的 用户Story分解成任务，评估这些任务所需时间，并领取任务。客户会同敏捷项目经理以及开发团队共同讨论 每个Sprint的目标，然后开发团队会把这些目标写在办公室的白板上。
之后的14天内，团队除了埋头 进行开发外，还需要参加每天早上的15分钟Scrum立会。在立会上，敏捷项目经理会通过网络摄像头逐一跟团 队评审3个内容：前一天完成的工作，当天要完成的工作，以及任何会阻碍团队实现Sprint目标的障碍。除此 之外，敏捷项目经理每天还要参加另一个30分钟的电话会议，与产品负责人讨论立会中出现的阻碍及解决方案 。每个Sprint的最后一天将是历时1个小时的演示单元，开发团队会向客户及项目干系人展示此次Sprint开发 的功能。