一、敏捷宣言价值观
1. 个体与互动高于流程与工具
在Scrum中，各种会议，如计划会、站会、回顾会等，都是尽可能采用面对面的方式，个体表达，队员倾听，它是最直接有效的；会上采用多种方法进行互动，以便能更好的达成一致，如分组讨论，PO与DT之间讲述、聆听、复述、澄清、提问等，这种个体的表达、团队的互动的效率和效果远高于按照既定的流程和特定的工具来做。
2. 可用的软件(增量)高于详尽的文档
Scrum中，每个Sprint的产出都是可用的软件，交给客户的都是迭代增量，而不是产出一个详尽的文档，有了可用的软件，客户才可能给予真实的反馈，便于后续迭代的开展和产品的不断完善；当然在Scrum执行过程中需要一些简洁、明了的文档辅助Sprint的进行还是必要的。
3. 客户合作高于合同谈判
Scrum中，PO与团队不仅仅是合作关系，更是团队中一员，从计划会开始，PO就开始参与，到评审会议PO的验收，甚至站会也可邀请PO的参与，团队会议中的环节基本都有PO的身影，PO与团队已是密不可分的关系，这样的团队才能更有效的交付；如果按照合同谈判来进行，甲乙双方分的很明确，有时候会产生矛盾或者纠纷，不利于产品的交付。
4. 响应变化高于遵循计划
Scrum中采用小步快跑的模式，使增量能尽快得到客户、相关干系人的真实反馈，方便团队持续改进；甚至Sprint中，PO都可以否决本迭代的内容或部分内容，重新开始Sprint；完全遵循较长计划，只会使反馈滞后，不能快速响应客户的需求，交付的产品未必是客户所需。
二、敏捷宣言原则
1. 尽早地、持续地交付有价值的软件来使客户满意是最高优先级的工作
Scrum中，计划会时团队根据PO制定的PBI中的优先级拆分UserStory，并在Sprint结束时交付增量，让PO验收，可以说整个过程都是根据PO制定的方向前进，同时团队也保持特定的时间框，持续交付可用软件，客户必然满意。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程适应变化来为客户创造竞争优势
Scrum中，PBI和SBI可以动态调整，以适应客户需求的快速变化，为客户创造价值。
3. 以几周到几月的间隔频繁交付可工作的软件，交付间隔越短越好
Scrum中限制交付时间，每次迭代交付时间不能大于1个月，尽快、尽早的稳定交付是我们需持续关注的。
4. 在整个开发期间业务和开发人员一起工作
Scrum中PO参与迭代中评审前(含评审)的各个会议，并和开发人员坐在一起办公，随时对用户故事或问题点进行澄清，保障迭代无障碍的进行。
5. 激励团队成员来建设项目。提供所需的环境与支持并信任他们能够完成工作
Scrum中要求团队自组织，团队领取任务后自发追踪进度，并管理进度，共同对结果负责；SM移除团队前行的障碍，为团队提供安全环境。
6. 在团队内部以及团队之间最有效最高效的传递信息的方式是面对面的沟通
Scrum中，如站会，每个人表述完三个问题，队员聆听，有问题记录下来会后沟通，这种方式不仅能聆听内容，更能透过肢体或面部表情，来了解表述人的情感，便于为会后的沟通做好准备。
7. 可工作的软件是首要的进度度量
Scrum中每个迭代的交付成果，都是可工作的软件，它是每个迭代要完成的目标；可工作软件的交付代表着PBI中有一部分用户故事可以关闭掉，进度可查。
8. 敏捷过程提倡可持续的开发。干系人、开发者和用户应保持长期、稳定的工作速率
Scrum中要求有时间盒的概念，各个事件都要遵循时间盒，Sprint的时间盒不能大于1个月，它固定下来后，团队就需要在这个时间盒内，保持一定的速率完成一定的任务量；这样持续的迭代，持续的交付。
9. 持续追求技术卓越和优秀设计能提高敏捷性
Scrum中通过回顾会以及code review等，反馈技术和设计上的一些问题，在下个迭代中不断完善、改进，使技术负债越来越少，技术负债的产生以及积累会使开发变慢，降低敏捷性。
10. 敏捷的根本在与简明扼要-是极力去除不必要工作的艺术
Scrum重新定义开发流程，强调了DOR和DOD的概念，多余的流程不需要；同时在功能上，从用户故事的拆解，到任务的细分，都是围绕着既定目标前进，不会出现镀金以及范围蔓延的情况。
11. 最好的架构、需求和设计出自于自组织团队
Scrum是一种实验性过程，架构、需求和设计都是在团队工作中慢慢浮现，而不是预定义，所有人都是同一团队，不能孤立生存。
12. 每隔一定的时间，团队反思如何更有效的工作，然后相应地调整其行为
Scrum定义的事件中有回顾会议一项，在安全的环境里，团队成员吐漏心声，将阻碍团队前进的问题暴露出来，共同讨论解决方案，并制定改进计划，在后续的迭代中调整、完善。