原文地址：https://www.scrumalliance.org/community/articles/2015/february/open-secrets-of-scrum
摘要
尽管Agile/Scrum逐渐流行并获得更多人认可，但真正能理解并执行好Scrum却有不少障碍。大家常说的，Scrum很容易学习但是非常难精通和操作。下文我将通过一个组织好的方式来解释scrum工作模型
序言
理解scrum基础框架并不难。他引入了3个角色，4个事件和3个工作产品。我将介绍一些“公开的秘密”，犹如催化剂一样，他们帮助我们工作得更好，产出高效结果。
Scrum工作流模型
下图描述了各种事件，如果执行正确，则会帮助我们维护一致节奏来及时交付软件
Sprint容器（Sprint container）
这里举一个10天周期sprint例子，因为两周是常见的时间盒。下面列出的是Scrum成功的关键因素，并在每轮sprint的同一时机迭代执行。假设本轮sprint从5日到16日。
Sprint计划会议
计划会议是sprint的第一件事，帮助建立sprint的backlog和目标。一般2周sprint建议4小时的会议。以前这样的会议常被忽视，backlog在会议前就分配好了，但sprint结束时却让大家失望。如果能计划好这4小时时间来理解业务需求、确认准则和对完成的定义（DoD），那么失败的可能性就会降低。强烈建议scrum团队能充分利用这4小时来理解、估计、框架化backlog和sprint目标。
Sprint启动报告（Sprint entry report）
启动报告应该在计划会后发布给所有干系人。报告应简短，涵盖sprint
backlog和目标、计划的故事点、假设和风险。报告可帮助关键干系人了解计划的交付趋势，从而为产品层决策（release-level decisions）提供依据。
每日会议
每天15分钟会议来回顾昨天，策划今天，揭露问题。参会人员最好能同时同一地点参加，从而让大家动作相符，节奏相同。无论团队规模和sprint周期，每日会议最好控制在15分钟之内。如果裁减了每日会议，团队就失去了互相帮助的机会。每日会议会减少召开其他会议的必要性。当然，第一天和最后一天的每日会议可以裁减，因为有其他两个重量级的会议可以关注问题。
问题跟踪（Impediment tracker）
一个简单的excel表格就可以帮助团队跟踪每日问题和风险。团队是自管理，所以应能主动识别问题的解决人并确保问题按优先级得到解决。没有问题最好，有问题或高优先级问题则预示着sprint的风险。应有指示器能显示团队每天的工作成果，并且该指示器能在sprint中看到趋势。
用户故事扩展会（User story grooming session）
扩展会用于分解用户故事/特性到下一层可执行单元。团队应同产品负责人、业务分析师一起工作，确保大家对用户故事/特性有一致的理解，并且sprint backlog已就绪。理想情况，一个sprint中10%~15%的时间用于扩展会，大概4次会议，每次60~90分钟。持续时间和次数会根据用户故事的成熟度（maturity）有所不同。
Sprint中期检查会（Mid-sprint heath check meeting）
这是在每一轮sprint进展中间召开的小型的类似sprint计划的会议，通常在第一周的最后一天或第二周的第一天。目的是了解进展，必要时（产品负责人的变更请求，团队的重大问题）对sprint backlog和目标做出调整。输出是修改过的sprint backlog和目标。在会议中，团队可以灵活地从sprint中增加或移除item。
Sprint中期检查报告（Mid-sprint health check report）
这是一个标准的报告，展示了根据业务修改后的sprint目标和backlog，用于帮助干系人理解变化需求和用户优先级。
Sprint评审会（Sprint review meeting）
也称为sprint展示会（sprint demo meeting），用于展示团队在sprint内完成的工作，一般演示2个小时，必须是可工作的代码。团队也会了解到下一个sprint的backlog，并记录干系人的反馈，会后分析，并决定是否纳入产品backlog或sprint backlog中。
Sprint结束报告（Sprint exit report）
Sprint周期的最后一份报告，涵盖度量数据，如交付故事点的数量、缺陷数、自动脚本数、测试用例数及执行状态。这些是sprint成功的关键指标。
Sprint回顾会（Sprint retrospective）
回顾会是Sprint周期内的最后一项活动。一般持续60~90分钟，如果是分布式团队，回顾会也可在sprint的第一天。如果回顾会被错过，就会失去改进的机会。回顾会的最后，团队决定行动项，标识其负责人，并鼓励大家积极改进。一口吃不出胖子来，改进应一步步进行。
Sprint0
Sprint0是开发活动开始前的特殊事件，也称为sprint readiness sprint，团队确保至少2个sprint的backlog就绪，建立工作环境，定义DoD，团队章程，沟通模式，以及其他有必要的事宜。Sprint0的持续时间通常是1~4周，根据项目的范围来调整。
集成sprint（Hardening sprint）
类似Sprint0那样特殊的sprint，一般是在产品部署前。通常是在多团队协同工作，且需要产品集成并执行非功能测试和集成测试。同时执行一些发布管理活动，确保产品能签署发布。该sprint只为集成各个sprint的成果，需要时可执行，并非强制性。
一些思考
如果要成功，上面提到的事件、报告、跟踪方法是有用的，至少可提高成功的几率。底线是：如果你裁减了scrum原始过程并形成自己的研发过程，请不要苛责Scrum过程（Please do not blame the Scrum process if you follow your
own tailored process rather than original Scrum，译者注：no zuo no die？）。