摘要：在 Scrum 中，Sprint 打算会议（简称打算会议）作为一个 Sprint 的开始，产品负责人（简称 PO）要和开发团队一起确立本次 Sprint 的指标，否则开发团队可能就不晓得做什么，进而无奈发展 Sprint 中的流动。
本文分享自华为云社区《Sprint 打算会议开始了，产品负责人却没来》，作者：麻利的小智。
背景
在 Scrum 中，Sprint 打算会议（简称打算会议）作为一个 Sprint 的开始，产品负责人（简称 PO）要和开发团队一起确立本次 Sprint 的指标，否则开发团队可能就不晓得做什么，进而无奈发展 Sprint 中的流动。
那么如果产品负责人没有加入打算议会应该怎么办呢？
为防止造成歧义，在剖析之前须要廓清一下的是，文中所说的产品负责人，次要是指自主研发我的项目中 PO 或者非自主研发下的代理 PO（非客户人员）。在 Scrum 指南中尽管没有明确指出产品负责人到应该是谁（客户 or 供应商），但业界比拟认同的是产品负责人是“客户的代表”这种说法，即你公司本人的人作为产品负责人，因为篇幅无限不再赘述。
问题剖析
随着国内越来越多的企业开始应用 Scrum 做为麻利转型的办法，对于这样的企业来说，可能会对 Scrum 中产品负责人的职责存在肯定水平上的意识偏差。无论是从 Scrum 指南 上来看，还是从其余参考资料（如《Scrum 精华》）中，原则上是要求产品负责人加入打算会议且准时的。可随着我的项目的发展壮大，需要剖析、干系人数量以及复杂度等都会随之增长，这也就导致了产品负责人的工作量呈几何式的增长。产品负责人没有加入打算会议可能不仅仅是主观认知上的起因也会被一些客观因素所影响。
所以一般来说，导致产品负责人没有加入打算会议的次要起因有：
1. 产品负责人没有明确其职责：次要体现在产品负责人没能分明或没有器重其在打算会议中的职责而没有加入。
2. 打算会议的召开没有固定性：次要体现在打算会议的召开的工夫不固定，存在肯定可能上和产品负责人工作打算相冲突而没有加入。
3. 打算会议的效率低、工夫长：次要体现在产品负责人的工作量多而简单的状况下，打算会议开的工夫长、效率低，导致产品负责人主观抗拒不愿加入。
4. 没有做好应答突发状况的工作：次要体现在产品负责人因市场变动、客户的要求等外界不确定性所影响等不能加入打算会议。
综上，接下来将会别离对上述剖析的 4 个方面给出解决措施。
解决措施
产品负责人没有明确其职责
Scrum Master，在日常的工作中要做好“政委”工作，将 Scrum 的思维浸透给 Scrum 团队中的每一个人。其中，就产品负责人而言，要让他分明的理解，作为产品负责人在 Scrum 框架中的作用和职责以及事件参加的重要水平等。对于打算会议来说，原则上是要求产品负责人加入打算会议且准时的，因为产品负责人须要和团队一起确立 Sprint 指标和范畴，否则可能会导致 Sprint 的无指标或偏离指标而没有达到预期的成果。
打算会议的召开没有固定性
“没有规矩不成方圆”，首先要立规矩（打算）。如，在一个正筹备麻利转型的团队，在其启动会上（或其余践行麻利之前的流动），就要先立规矩。其中就应蕴含 Sprint 的周期，以及什么工夫哪些人须要加入哪些 Scrum 事件等。当然曾经运行了一段时间的麻利团队，也能够从新立规矩，如果没有（须要）的话。对于打算会议而言，须要固定好每一个迭代什么工夫开，开多长时间，以及加入的人员。
在日常的工作中，Scrum Master 要做好“保姆”的工作，能够在行将要散会前“吼”一嗓子。但咱们倡议是以会议揭示邮件的形式，目前支流的邮件管理系统（outlook、foxmail），都能够做到“反复周期”的设置，简略又不便的揭示到 Scrum 团队中的成员。
上述两点，其实说白了，就是要在思维和流程上先僵化，要让每个人（Scrum 团队）都晓得在什么工夫就做什么事件，放弃团队节奏，避免出现团队中的任何人，在散会的工夫还不晓得要散会的状况。
没有做好应答突发状况的工作
如果产品负责人，遇到突发状况无奈参会时，比方须要在客户现场解决相干问题。这就须要产品负责人能确保，产品代办列表中的用户故事的数量，能应答开发团队将来 1 到 2 个 Sprint 的工作（含优先级）。除了数量以外，还要对用户故事的品质有所要求，所谓的品质，不仅要有清晰的形容，还须要有验收规范（AC）。这样就能够很大水平上为产品负责人缺席提供了可能，因为哪怕产品负责人不在，开发团队也晓得该做什么，如何去做。当然，这里所提到的是产品负责人分身乏术的问题，如果产品负责人只是在异地，工夫上是 OK 的，那么就须要团队要能具备视频散会的能力和工具，那就必须要求团队提前准备了。
此外，还应该晋升开发团队的能力，就如 Scrum 指南所指出的，开发团队也能够实现产品负责人治理产品代办列表的工作。这就须要开发团队具备自组织的能力（对于自组织能力的建设，请注意之后咱们专家团队的 FAQ），在咱们华为云 DevCloud 外部，其实也始终贯彻着，人人都是产品经理的理念，做到团队中的每一个人都能够成为产品负责人的 backup。
还有一点须要特地留神的，也是比拟容易疏忽的——产品负责人也是人。产品负责人也会有接孩子、开家长会、度假等工作以外的事件。这也就是传说中的“周末事件”，所以在对 Scrum 事件的工夫安顿上，应防止在一周的完结和开始进行（星期一、星期五），以升高要害事件被日常生活中断的概率。所以很多团队会抉择星期二、三作为 Sprint 的开始。如果存在“周末事件”的影响（产生频率较多），那么这也就对应了一开始提到的，如果有须要就从新“立规矩”。
最初还须要思考到极其状况，就是打算会议产品经理必须加入，这往往是由将来工作调整上的突发性引起的，或其余重要价值的事项。对于这种状况，就可能不得不把会议推延到产品负责人工夫 OK 的时候了。如果只是提早了几个小时，那么其实影响并不大，在当天晚些工夫散会即可，而且其余会议也不受影响。可如果会议推延较多，那么很可能就是工作布局上产生微小变动，这就要视状况而定做调整，甚至勾销该 Sprint。
打算会议的效率低、工夫长
一般来说，打算会议可能会继续开 4 到 8 个小时。这对于产品经理来说，无疑是减轻了其工作累赘，所在肯定水平上是不违心承受这么长时间的会议的，那么就须要在会议上能晋升效率。
咱们在理论开打算会议的时候，通常将打算会议分为上下半场。大抵（不同团队可能有所不同）如下：
这里能够清晰的看到，一个打算会议被分为产品负责人和团队一起加入的，以及开发团队本人加入的两个“会议”。所以实际上产品负责人不必参加残缺的打算会议，这就给产品负责人在会议上节俭了工夫。在这一过程中 Scrum Master 要能掌控好，防止产品负责人参加到了细节和技术实现上的探讨中。
这里还须要提到的是，打算会议的一个重要输出项，一个有优先级并且适合颗粒度大小用户故事的待办工作列表，而且其中需要细节曾经在梳理会上就被开发团队所通晓了。这也要求了产品负责任人要器重用户故事的品质，这实际上也是在帮忙本人加重沟通上的累赘，晋升效率。更多对于用户故事的编写请参考《“用户故事等于需要阐明”—— 你肯定没有写好用户故事》。
对于只加入半场会议的产品负责人，如果整个流程上管制的好，那么其后果，就是能够晋升产品负责人加入会议的可能性和志愿性的。当然，这个上下半场也不是齐全相对没问题的，如在下半场开发团队发现 Sprint 指标可能会有些变动，那么能够再和产品负责人做轻量级的对其和调整，个别问题不大。
总结
以上对于产品负责人没有加入打算会议的剖析，是依据常见的状况所阐述的，但必定不仅于此，因为真正的理论状况永远是变幻莫测的，咱们须要始终围绕着麻利的核心思想发展流动和解决解决问题，在践行的过程中，采取是“先僵化、后优化、再固化”的方针，不断完善和改良咱们的流程和思维，进而晋升效力和竞争力。
参考资料
《Scrum 指南》
《Scrum 精华》
点击关注，第一工夫理解华为云陈腐技术~