Scrum要求产品在每个Sprint中保持可能可交付(例如,经过适当测试/集成)的状态,产品所有者(Product Owner)声明哪个工作是最优先考虑的,并且工作可以分成薄的垂直切片,通常是以客户为中心的用户故事(User Stories) 每个都要大于几天。如果我们正在做其他敏捷 (Agile)的东西,我们不能错过发布日期 (Time Schedule),因为产品每周或每两周都可以发货。估计错误的唯一缺点是我们会按时发货,同时省略不太重要的功能 - 比瀑布 (waterfall) 或伪敏捷团队 ( pseudo-Agile) 今天所遇到的压力更小的工作方式。
在瀑布式方法中 (waterfall approach),管理人员根据时间确定团队成员的工作负载能力。经理要求选定的开发人员估计他们预期某些任务需要多长时间,然后根据该团队成员的总可用时间分配工作。在瀑布中,测试是在按照特定的职位名称之后完成的,而不是与代码一起编写的。瀑布的缺点是众所周知的:工作总是迟到,总是有质量问题,有些人总是在等别人,而且总是在最后一刻才赶上最后期限。
Scrum团队采用完全不同的方法。首先,整个Scrum团队而不是个人负责这项工作。整个团队负责每个产品Backlog项目。整个团队负责测试产品。没有“我的工作”与“你的工作”。所以我们专注于每个产品积压项目的集体努力,而不是每个任务的个人努力。其次,Scrum团队更喜欢将项目相互比较,或者以相对单位而不是绝对时间单位来估算它们。(最终,这会产生更好的预测。)第三,Scrum团队将客户可见的需求分解为尽可能小的故事,从而大大降低风险。如果有7个人的工作量太大,我们会组建功能团队 (feature team) 消除依赖 (dependen