1986年，Scrum首次应用于产品开发，竹内弘高和野中郁次郎在 《The New New Product Development Game》文章首次提到将Scrum应用于产品开发。
1993年，Jeff Sutherland在首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。
1995年，Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。
2001年，敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。
2002年，Ken Schwaber和MikeCohn共同创办了Scrum联盟。
Scrum敏捷开发让团队以一个整体走完全程，产品开发过程从一个精心挑选的多学科团队的不断互动中产生，团队成员从开始到结束都在一起工作，该过程不是在定义好的、高度结构化的阶段中进行的，而是在团队成员的相互作用下产生的。
4. Scrum的特点
4.1内置的不稳定性
高层通过发出一个宽泛的总体战略方向的信号来启动项目，并设置了一个极具有挑战的目标，同时赋予项目团队极大的自由来完成这个项目，这样既给团队压力，同时把团队推到墙边并把他们逼到极致发挥他们的创造力。
4.2自组织的项目团队
当项目团队被驱动到“零信息”的状态时，他们就会呈现出一种自组织的特征，这种状态存在模糊性和波动性，因此需要项目团队像初创团队一样运作，承担主动性和风险，并制定独立的议程，当一个群体表现出三个条件：自治、自我超越和异花授粉，这个群体就拥有了自组织的能力。
自治：公司的参与仅限于在一开始的指导、资金和道义支持，日常工作中高层很少介入，团队可以自由地设定自己的方向。
自我超越：项目团队全神贯注于对“极限”的永无止境的追求，从总部提出的指导方针开始，他们开始建立自己的目标，并在整个开发过程中不断提升目标。
异花授粉：由具有不同职能专业、思想过程和行为模式的成员组成的项目团队进行新产品研发，这种多样性孕育了新的思想和概念（这里和黑客增长理念接近，多样团队的观点碰撞，获得更具创意的实验方案）。
4.3重叠的开发阶段
在瀑布式方法下，一个项目以循序渐进的方式经历几个阶段，只有在满足了前一阶段的所有需求之后，才能从一个阶段过渡到下一个阶段，通过一些检查点控制风险，但这种方法几乎没有为集成留下空间，某个阶段的瓶颈可能会减慢甚至停止整个开发过程。而在整体或橄榄球方法下，这些阶段有相当大的重叠，这使得团队能够吸收整个开发过程中产生的振动或“噪音”，重叠方法加强了共同责任和合作，激发了参与和承诺，团队必须同步进度以满足最后期限，突出了解决问题的重点，鼓励主动采取行动，发展多样化的技能，并提高对市场条件变化的敏感性。
4.4多重学习
由于项目团队的成员与外部信息来源保持密切联系，他们可以快速响应变化的市场条件。团队成员参与一个不断尝试和犯错的过程，以减少他们必须考虑的选择的数量。他们也获得了广泛的知识和多样化的技能，这有助于他们创建一个能够快速解决一系列问题的多才多艺的团队。
4.5微妙的控制
尽管项目团队在很大程度上是独立的，但他们并不是不受控制的，管理层建立了足够的检查点，以防止不稳定、含糊不清和紧张局势演变成混乱。与此同时，管理避免了那种损害创造力和自发性的严格控制。相反，它强调的是“自我控制”、“通过同伴压力的控制”和“通过热爱的控制”，我们统称它们为“微妙的控制”。
4.6学习的组织转移跨
层次和跨职能积累知识的动力只是学习的一个方面，项目成员也有同样强烈的动力将他们的学习成果转移给小组以外的其他人，将学习内容转移到后续的新产品开发项目或组织内的其他部门。
Scrum敏捷开发的实施让开发团队有了一定自主权，已安排好的计划很大程度上不会被打断，同时上下游相互配合，为一个共同的目标而努力，每个人都清楚团队其他人的工作内容，每天都知道项目的实时进度，团队是一个整体的存在，而不是每个人独立工作下的个体，有着很强的集体荣誉感。
但Scrum能否成功实施，关键要先获得高层的认同和理解，让高层们理解Scrum的要义、利弊，如果Scrum能带来高效、优质的开发成果，那就在制定绩效结果并在实施过程中放权，让每个成员真正意识到项目成果是自己的事，而不是领导的事。如果是职能型的研发团队，同时也要获得各需求方的认可和支持，分享在这种方法下对整体的收益最大化，否则可能会面临各种不理解，最终可能导致实施失败。
因此，我们要落地Scrum敏捷开发，就要做好“猪”与“鸡”两种角色之间心理上的平衡与和谐，“鸡爷爷”切不可把“小猪”们看成是一群猪八戒，空有一身本领，但好吃懒做。“小猪”们也不可把“鸡爷爷”想象成周扒皮，只会半夜鸡叫，影响正常的开发进度。猪和鸡双方相互理解，达到项目开展过程中的平衡点，才能让整个项目顺利的完成。
敏捷开发的落地，人是最重要的，在做敏捷开发之前，需要先组建一直敏捷的团队，而作为这个团队的负责人，必须要对于敏捷有着清晰的认知。
二、敏捷开发的理解
很多人对敏捷开发的理解就是快，做项目中如果不快就对不起敏捷这两个字，但快到什么程度却没有概念，因此往往没有参与过完整敏捷开发项目的人，遇到一些问题之后“比如不是他想象的那么快”，就对敏捷开发提出质疑，觉得敏捷开发也就那样，究其根本是对敏捷开发的片面理解，或者只是了解了皮毛就觉得掌握了全部，而忽略其本质；
敏捷开发的目的是用来适应快速变化的市场，就像冲浪一样，一直处在动态、不停的变化当中，而在项目研发过程中遇到的需求变化和沟通平衡的挑战，就是你在冲浪时遇到的海浪，它们从不停止且永远在变化，所以我们要快速的适应变化。
