在产品交付过程中，我们的工作除了产品待办事项阐述功能的一个个用户故事，还有为了更好推进交付而需要解决的问题，障碍待办事项就是敏捷开发为解决阻碍性问题的一个可视化工具，团队在基于信任文化的基础上，可以对目前面临的阻碍有一个全面的掌握，并且随时补充和及时地根据优先级进行持续改进。我个人理解的障碍待办事项是产品待办事项的一个子集……
团队向前推进工作，磨合好的团队，迭代的长度也不变，我们就可以对团队的下一个生产阶段进行预测……
由团队中的一名成员给PO演示代办列表中已经“完成”的一个条目。当PO问开发团队从用户角度功能何时准备就绪时，开发团队会告诉他们已经完成了所有工作，但是非常有必要去做更多的测试，并且将系统迁移到客户机环境中，而这又取决于另一个任务。继续往下讨论，另一名成员说因为这块是系统的重要基本部分，开发团队和PO应该在发布之前对它进行检查。“那么什么时候完工呢?”这位绝望的PO问。“你仅仅去演示它是可以的，但仍有一些事情需要做。”
“游戏精神”在Scrum所有模式语言中占首位，它为其它模式语言奠定了基础，更重要的是游戏精神将带给我们关于如何理解Scrum的新见解和如何使用Scrum。在游戏中，游戏精神更重要还是规则更重要？游戏精神和Scrum精神有何共通之处？当组织中出现了并不违背明确的Scrum规则时，我们应该如何判断，如何应对。
在规模化敏捷中常强调的有效沟通和交付对齐。Scrum of Scrums是一种最早的规模化敏捷技术，简单且有效，用于集成多个（建议不超过3-9个）在同一产品上工作的Scrum团队的工作。Scrum of Scrums确保团队之间有效沟通，以使每个团队的软件输出与其他团队的输出很好地集成在一起并交付客户，尤其是在工作重叠或时间顺序很重要的地方；同时，也是为了共同讨论并决策。最直观的活动就是SoS会议，由各Scrum团队中派出主要代表参加。总体目标是使团队工作保持顺畅，并使总体交付成果保持在正常状态。通常组织将这种方法用于扩展敏捷性和组织大型复杂产品交付的第一步，然后在酌情考虑采用更成熟的规模化敏捷框架……
尽管我们处于一个追求团队合作的时代，将工作分配给个人去独立完成的情况却随处可见。批量处理的思想运用在开发项目的各个环节。开发人员从Sprint Backlog中挑选需要开发的功能或者需要修复的缺陷，测试人员从已经完成的功能待测列表中进行测试，部署人员将所有测试成功的代码批量部署。从每个团队成员去看，似乎大家都在高效的完成各自的工作。然而当我们从单个SBI的角度去看，就不难发现在整个过程中，等待随处可见。完成的代码等待测试人员进行测试，测试失败的缺陷需要等待开发人员修复，测试通过的代码需要等待批量部署。“蜂拥而上”的模式从提高产品生产速度的角度出发，提供了一种新的团队合作方式，将效率评估从个人转向团队，转向产品。文章向我们详尽的解释了，为何蜂拥而上的方式，可以将团队效率最大化，并引用了丰田的案例，向我们介绍了如何将该方式运用到Scrum中，将生产的流速度提高到极致……
传统的项目管理模式使用甘特图来制定工作计划，在Scrum模式下，我们用Sprint待办列表来表示工作计划。排序是Sprint待办列表的核心，怎样维持工作的节奏？如何有效率地完成交付？还有如何平衡PO的影响等等，这些都是排序时要思考的问题。Scrum追求开发团队自我组织，但实际上要实现这一点不是一件容易的事，正如文中所言，能独立地安排工作计划，是团队实现自组织前的重要一步。因此，每一个Scrum开发团队都应该认真面对工作计划……
本文说到的Scrum白板是一个重要的Scrum工具，是以物理或电子的方式展示当前Sprint范围及其状态。在Sprint计划期间，当前Sprint计划的产品增量被分解为可执行任务。Scrum白板主要包含故事及其相关任务，通常也称为任务板。作为以Scrum框架进行的敏捷实践中重要的可视化信息发射源，它在Scrum中被广泛应用。如果对Kanban很熟悉的朋友，这里有一句话：Kanban面板控制团队；而团队控制Scrum白板。阅读本文去品位一下吧……
在很多敏捷项目中，秩序诞生的标志之一是有了成文的DoR。但是项目组和需求方的折中往往也无可奈何地始于将没有就绪的需求纳入到Sprint待办事项列表，并为Sprint实施阶段带来一系列的不可控因素。为什么市场和产品人员时常要求技术人员在Sprint里实施一些没有充分精炼过的需求？如何制定DoR，并使之解决市场和技术之间的断层问题？推动DoR的过程中出现问题要怎么办？本文作者立足于自己的经验，分享了对以上问题的看法，对正在踌躇是否制定、正在制定和推动DoR的团队有一定的借鉴意义……
无论是新手还是老兵，ScrumMaster有必要找一个教练，或帮助自己补足短板，或提供新鲜的视角，为自己打开解决长期问题的思路。关于敏捷教练有很多的参考资料，个人推荐从Lyssa Adkins的Coaching Agile Teams一书开始。学习教练技术，可以更好地为团队的成长和提高服务；此外，若很难找到合适的教练人选，自我教练也是可行之路……
最近在读《Design Thinking for Innovation》, 作者是Walter Brenner 和Falk Uebernickel。其中的理念、方法论和实践总结和自组织团队有很多的地方异曲同工……
随着越来越多的公司与组织（尤其是规模较大的企业）启动敏捷转型，规模化敏捷的话题在业界和敏捷社区中越来越火热。然而传统公司在敏捷转型的规模化中时常步履蹒跚，其中主要的原因之一就在于：原本严丝合缝的组织架构，无法良好地适应并赋能一线的敏捷团队进行充分的自管理和自组织。因而社区通过总结 PatientKeeper 的优秀实践，提炼了 MetaScrum 的方法，即本篇译文的主题：在大型企业或组织的规模化敏捷实施中，设置高层级的 MetaScrum 团队，负责组织级的愿景与优先级确认，部门协调，跨团队互动，快速移除障碍等等工作……
在参与产品开发的过程中，你是否遇到过这些问题：编写很多不必要文档；开发了需求列表中没有的功能；在沟通确认和寻找信息上花费掉很多的时间；多个人负责同一个任务，经常需要交接等等？这些问题都属于浪费，所有追求高效的组织都要考虑如何识别和消除浪费。价值流是精益的核心思想之一，它的作用就是通过跟踪产品从概念到交付的全部路径，从而识别别出流程中各个环节中存在的浪费，而 Scrum 则提供了一些消除浪费的工具……
随着敏捷与 Scrum 在业界实践的范围越来越广，各种转型中的问题亦层出不穷。比如某个组织虽然建立了基于 Scrum 的业务团队，并通过短迭代周期的节奏运作交付价值，而其他团队（如财务）仍运作在传统的业务节奏中（如月度，季度，年度）。由于价值流的流动和交付贯穿于整个组织，不同的业务节奏就会导致协同的困难，造成浪费……
这篇文章，让我想到了全局观，应该是作为产品负责人具备的基本素养，不仅给产品以愿景，给团队以方向，同时也能帮助产品负责人与干系人很好的进行沟通。而发布计划应该是这种素养的可视化的表述之一。发布计划向上衔接面向管理层的产品愿景和路线图，向下衔接面向团队的Sprint计划，对产品某次发布有个明确的规划，连接愿景与落地。个人的经验而言，可以让产品负责人与团队一起，结合用户故事地图工具一起来做发布计划……
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/295326.html