scrum的开发时间的预估

首先，在scrum里,开发任务被分成很多用户故事，每个用户故事需要根据实现的难易分配点数，于是，一个团队聚集在白板前开始估计故事的点数（点数是一个斐波那契数：1,2,3,5,8...）每个人从一堆故事里挑出他（她）觉得点数最小（最容易）的故事贴在白板上，下一个人继续，直到一轮结束或者没有更多的用户故事，接下来，团队会对白板上已经排列的故事进行调整，例如故事X，有人会觉得简单。有人觉得难，这个过程需要充分交流。大家必须说出自己觉得难或者简单的原因。在交流中达成共识（可能觉得难的人发现没那么难，又或者觉得简单的人发现没那么简单）

现在，团队挑一个最简单的故事进行开发，假设一个点数为1的用户故事开发了实际用了2个小时，那么以此进行推测：点数为3的用户故事应该需要6个小时，leader通过持续的记录，可以了解到团队的实际开发速率，从而为每个spint(开发周期，通常是1到2周)估出一个合理的用户点数，例如一个团队一个spint不加班的情况下能完成40个用户点数，我觉得最多压20个用户点数，即60个用户点数，超过这个范围团队肯定会拖垮

不过，我还是希望团队能够不加班的情况下，能够提高速率（每个spint 比较轻松的状态，完成更多的点数）而非强制添加点数，实际上我也相信，良好的设计，高质量的代码，完善的测试这些都应该有助于速率的提高