产品任务列表（Product Backlog Item/PBI） 是可以预知的所有仸务，包括功能性的和非功能性的仸务，PBI属于计划阶段，指出了我们目标，PBI表述的时候建议的原则：

• Independent 独立性，避免与其他Story的依赖性。
• Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。
• Valueable 有价值性， Story需要体现出对于用户的价值。
• Estimable 可估计性，Story应可以估计出Task的开发时间。
• Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。
• Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test。

这个虽然加入了一些软件技术性描述，但是总体上和我们说Smart原则上是一致的。

迭代计划(Sprint Planning )，综合考虑项目环境,在下一个迭代周期的目标,其中的Sprint Backlog来自PBI，这个就是我们所讨论的计划工作中对目标实现的途径作出安排。

当然这涉及到决策问题,比如迭代的周期？先实现那些PBI？比如迭代周期的选择，这个就是个非程序化决策，需要我们自己的经验判断，PBI的优先性我们可以从PBI的字段描述中进行程序化决策。

Scrum定义了许多角色，关于猪和鸡的笑话很形象，对于猪的角色来说又分三种：产品负责人（Product Ower），Scrum主管（Scrum Master）,开发团队（Scrum Team）

• 产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写 用户故事，排出优先级，并放入产品订单。
• Scrum主管Scrum主管促进 Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。
• Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成的小团队完成实际的开发工作。

Scrum中这三种角色是精心设计的,符合我们管理理论组织的理论，一个产品只能有一个Product ower符合我们的统一指挥原则，Scrum Master的主要工作是去除那些影响团队交付冲刺目标的障碍，也是为了项目实现创造环境等等。 在实施Scrum的时候，所做的第一件事情就是打乱特定于组件的团队，创建竖井式的团队。它减少了诸如“我们没法完成这个条目，因为我们在等server那帮家伙完成他们的工作“之类的情况发生

敏捷的宣言中包括个体与交互胜过过程和工具,Scrum中对于会议分为：计划会 （Sprint Planning Meeting）, 每日立会 (Daily Standup Meeting),评审会(Review Meeting)，回归会(Retrospective Meeting）。

• 计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
• 每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，一般包括完成了什么？是否遇到了障碍？即将要做什么？因一般只有15分钟且站立进行而得名。
• 评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议，在这个会议上产品负责人确定完成了哪些工作和剩余哪些工作。
• 回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的回忆。

这个和我们管理中控制息息相关,其中计划会指明了控制的方向,每日立会作为前馈控制,评审会可以作为现场控制，回顾会可以作为后馈控制，为我们下一步计划做参考,在会议中各个Sprint Backlog完成情况可以作为员工绩效考核的一个因素。

是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目，通常燃尽图可以在每日立会展示，作为我们控制的一个辅助手段。