三个工件：
１、产品代办事项列表（PB）
用户故事——可用于ｓｐｒｉｎｔ
１、一个排序的列表
２、列出了所有的特性
３、优先级由高到低排列一个顺序，排在顶部的产品待办事项列表条目需要立即进行开发。更清晰、更具体（符合就绪的定义）优先级低，细节信息越小。（KANO模型和MOSCOW法）
满意程度和具备程度
必备需求、期望型、魅力型、反向需求
４、
２、sprint backlog 冲刺（迭代）代办事项列表
考点： 团队成员主动领取任务（自组织、鼓励成员挑战、透明）交叉培训，
考点：开发团队专注于达成sprint的目标，当前sprint无变更
3、产品增量
（1）一个sprint完成的所有产品代办列表项的总和
（2）新的增量必须是完成的，道道scrum团队完成的定义的DOD
（3）增量是sprint结束时可检视的和已完成的产品组成部分。
（4）增量时迈向愿景或目标的一步。无论产品负责人是否决定发布它，
技术负债：重构
核心——五个事件
1、sprint
是scrum的核心，持续时间为某个限时，以构建一个完成的，可用的，潜在可发布的产品增量
sprint长度通常保持一致（规定的时间盒）——短周期交付，及时反馈，步调稳定延续
spriｎｔ计划会议、每日ｓｃｒｕｍ站会、开发工作、ｓｐｒｉｎｔ评审会议和ｓｐｒｉｎｔ回顾会议构成
ｓｐｒｉｎｔ期间不变更
所有未完成的产品代办事项都会被放回到产品代办事项列表中，并重新估算。花在他们身上的工作会很快贬值，所以必须经常重估
只有产品负责人才有取消ｓｐｒｉｎｔ的权力
（１）ｓｐｒｉｎｔ计划会议
考点：团队决定一个ｓｐｒｉｎｔ完成多少！！！！
ｓｐｒｉｎｔ不变更，变更不应该纳入到sprint的变更事项中
故事点和团队速率
１、故事点和相对估算
斐波那契数列 １、２、３、４、８、１３
２、刺探、探测、探针（ｓｐｉｋｅ）
快速而简陋
３、速率：衡量团队在每个ｓｐｒｉｎｔ中可以解决的工作量的指标，也是ｓｃｒｕｍ的关键指标
由于每个团队选取的基准用户不同，不同的敏捷团队每个ｓｐｒｉｎｔ完成的故事点不具有可比性
故事点不是越多越好，而是越稳定越好，团队的速率需要经过多个ｓｐｒｉｎｔ才能稳定。一般不会随意的增加资源。
计划会议最终目的：sprint backlog
（２）每日ｓｃｒｕｍ站会（考点！！！）
１５分钟
１、昨天做什么
２、今天做什么
３、是否有任何障碍
会议只记录问题，讨论问题
scrum master强制执行每日scrum站会规则——只有开发团队成员才能参加
增进交流沟通
考点！！！信息发射源
大白墙或白板
高可视化、图形化的方式展示
燃尽图、燃气图、积累流量图、停车场图额，信号灯图
意义：沟通——高效、透明
减少很多不必要的会议
（3）sprint评审会议
快结束是，两周的sprint 一般2个小时
开发团队演示完成的工作，解答关于所有交付增量的问题，演示增量的目的是为了获得反馈并促进合作
结果是一份修订后的产品代办列表
（4）sprint回顾会
总结 经验教训，明确接下来的sprint中需要实施的改进
PDCA
其他敏捷实践
看板，可视化管控，消除瓶颈
WIP
极限编程
