Resolvecomplexityanduncertaintywithcontinuousandfastfeedbacktocreateabilityrespondingtochangeswithlowcost,sothatachievebettereffect
利用持续、快速反馈来破解复杂性和不确定性，建立用较低成本来响应变化的能力，从而达到更好的效果
Scrum是基于试验性过程（经验主义）的框架，用来解决不确定问题和维护复杂产品。试验性过程的三个支柱分别是Transparency透明、Inspection检验、Adaptation适应。
“传统的接力式的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”(Rugby)的方法——团队作为一个整体前进，在团队的内部不断传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。”
1993年，JeffSutherland在Easel公司定义了用于了软件开发行业的Scrum流程
1994年，KenSchwaber建立了“控制混乱”网站。
1995年，JeffSutherland和KenSchwaber规范化了Scrum框架，并在OOPSLA95上公开发布。
2001年，敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。
2001年，KenSchwaber和MikeBeedle推出第一本Scrum书籍《Scrum敏捷软件开发》。
2002年，KenSchwaber和MikeCohn共同创办了Scrum联盟。
CommandandControl命令控制Planindetails详细计划Enforcetheplan强制按计划“Control”change“控制”变化
vs.
Learnaswego边前进边学习Changehappens变化会发生Embracechange拥抱变化InspectandAdapt检视和调整
Openmind,activeexploring,willingtoshareandhelpothers.Experiencedintransformationoratleastunderstandpoliticalego-systemoforganization,begoodatusingpowerw/oeagertothat.Aboveaverageleveloftechnologyandproductknowledge.Havecommunicationandinfluencingskill.Moreofextroversion.
Timebox:max8hoursfor1monthSprint
PartISELECTION第一部分选择DefinetheSprintGoal定义迭代目标SelecttheProductBacklogItemstheteamcancommittocomplete选择团队可以承诺完成的迭代待办项
PartIIPLANNING第二部分计划DecidehowtoachievetheSprintGoal决定如何实现迭代目标CreatetheSprintBacklog创建SprintBacklogEstimatetheSprintBacklogItems估算迭代待办项
Scrum三大角色，合起来称为Scrum团队。
在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色，这三个角色分别是产品负责人（PO）,ScrumMaster(SM)和交付团队(DT)。
我们通常可以以划龙舟的团队角色来类比Scrum的角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色，他对产品的方向负责，对产品的Why和What负责，对产品的愿景，产品包括哪些主要的特性负责。Scrum中的ScrumMaster鼓手的角色，他帮助团队保持高昂的士气，并进行良好的协作，他是一个Scrum的专家，团队的教练，团队的服务式领导。Scrum中的交付团队，对应到龙舟赛的划桨团队，团队必须协调一致，作为一个整体前进，在这样的环境下单打独斗，各自为政没有任何胜算。
当产品代办事项列表条目或者增量被描述为“完成”的时候,每个人都必须理解“完成”意味着什么。虽然这在不同的Scrum团队之间会有巨大的差别,但是团队成员必须对完成工作意味着什么有相同的理解,这样才能保证透明性。这就是Scrum团队的“完成”定义,用来评估产品增量在什么时候完成，并且没有妥协质量。
开发团队在每个Sprint交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立即发布它。每个增量都附加于之前所有增量并经过充分测试,以此保证所有的增量都能工作。
随着Scrum团队的成熟,我们预期“完成”的定义会扩大,包含更严厉标准来保证高质量。
需要注意的是，如果在每个迭代，我们对“完成”的标准要求过低，那么这会导致在每个迭代，我们都会遗留一些完成外的工作，完成外的工作持续累计会增加项目的风险，有可能导致产品负责人决定发布的时候，产品却因为累积了过多的完成外的工作而无法发布，以致于我们还需要一个额外的Sprint来使它稳定。
当PO拿出ProductBacklog请团队拉动工作时，团队是否能否立刻开始，抑或充满疑惑，似懂非懂？有些戏精工程师就在迭代根据自己的理解胡乱做，待到验收的时候产品负责人和客户大叫“这不是我要的！”
于是DoR这个定义（也称“就绪的定义”）正式产品负责人对团队的承诺，是团队能够开工的保证。团队有权利要求PO提供这个检查清单中的必需内容，不然的话就先不开始这个工作。
DoR一般包括：每个PBI和用户故事应当具备背景和目标、足够理解的信息、已估算、已排序、已记录下验收条件测试用例，界面原型草图，乃至浏览器兼容性列表等等。
也称团队纪律。自组织团队中每个人如何协作配合？就像乔布斯在《TheLostVideo》中提到的，打造团队就是要明确目标，然后建立一个容器，让大家互相争吵、碰撞、打磨，于是丑陋的石头也会变成漂亮的石头。
大家之间磨合的约定和规则是符合现实的，外人不能也无法给出一个传统的流程强迫大家遵循，一定是大家提出、大家认可，大家才能执行下去。
AbsoluteEstimation绝对值估算numberwitha‘unit’,likeMD/Hours,LineofCodeetc带有”单位“的数字，例如人天/小时，代码行数等
RelativeEstimation相对值估算numberWITHOUTaunit:numberoftimeswecompareoneagainstanother不带单位的数字：一个数字与另一个数字的对比