敏捷软件开发宣言
个体和互动 高于 流程和工具
在敏捷中，我们更多的强调个体和互动高于流程和工具。并不表示就彻底的省略一些做事的流程和工具，只是将后者相对弱化而已。人才是获得项目成功的最为重要的因素。在Scrum中，我们每天早上固定的站会，让每个队员讲述昨天做了什么；今天准备做什么和有遇到哪些困难？通过这样让全体队员知道团队成员每个人都在做什么，对项目的整体进程有一定的了解。同时在Sprint的计划会议、评审会议和回顾会议主要也是让团队成员来阐述个人的意见和看法。
工作的软件 高于 详尽的文档
没有文档的软件是一种灾难。敏捷强调可工作的软件高于详尽的文档，编写一份系统原理和结构方面的文档是必要的。在Scrum中，我们没有面面俱到的文档，却以快速迭代的方式来发布软件，每个迭代结束的软件都是可以工作的。在每个迭代快结束时，举行Sprint 评审会议，用以检视所交付的产品增量并按需调整产品待办列表。
客户合作 高于 合同谈判
成功的项目需要有序、频繁的客户反馈。在Scrum项目团队中，有Product Owner这个角色，他是有客户委派到团队中，全权负责项目的需求，是负责管理产品待办列表的唯一负责人。
响应变化 高于 遵循计划
计划不能考虑得过远。在Scrum中，我们并不作长期的详尽的计划。我们只为接下的两周做详细的计划，以下的三个月做个粗略的计划，再以后就做极为粗糙的计划。
敏捷开发十二原则
我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
在Scrum中，建议以每两周一个Sprint，然后在每个迭代结束时，在 Sprint 评审会议中，Scrum 团队和干系人协同讨论在这次 Sprint 中所完成的工作。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
Scrum以两周一个Sprint，增量开发，且每个迭代结束都是一个可以工作的软件，可以交付客户使用的。在开发过程中，可以对Product Backlog和Sprint Backlog进行动态调整，使之能及时响应客户的要求，保证产品满足市场需求。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
Scrum以两周一个Sprint，增量开发，且每个迭代结束都是一个可以工作的软件。所以随时可以交付可工作的软件。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
Scrum中，有客户全权指派的Product Owner在团队中，每天和开发人员在一起，可以相互合作，频繁交互。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
在Scrum中，以团队成员为中心；完成相信队员，让团队成员来评估每个用户故事及认领任务。相信团队能胜任自己的工作。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
首要的沟通方式是交谈，Scrum中的计划会、站会、评审会、回顾会或在一个办公室里工作，都提供面对面沟通的方便；
可工作的软件是进度的首要度量标准。
Scrum以增量的方式，交付可工作的软件，且增量是可以检查的。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
Scrum没有详尽的长期计划，每次Sprint增量开发。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
Scrum通过回顾会来检视团队中的多个方面，为下一个Sprint创建改进的机会。
以简洁为本，它是极力减少不必要工作量的艺术。
Scrum不提前构建华而不实的架构，更愿意采用和目标一致的且最简单的方式来完成任务。
最好的架构、需求和设计出自自组织团队。
Scrum中只专注于当前的需求，以满足当前项目需求，不超前设计系统架构。我们通过持续改进，完善的框架；如果有具体的架构需求，可以把对架构的需求放到Product Backlog中，然后在具体的Sprint里完成。
团队定期地反思如何能提高成效，并依此调整自身的行为表现。
Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。