我接触到一个scrum team, 在拆分story的task时,按照如下规定:
1、一个工作日的理想工作小时为5个;
2、story point总数量乘以3(3是team的经验值),即是这些story总的要花费的小时数。总的小时数除以5即得出要花费的天数。
对规定1,我不反对;对于2,这个team这样做的目的也许是为了计算作完一个项目需要的时间,我认为笼统的乘以一个常量得出“理想”小时数欠妥。story point数量本身就是一个估算值,乘以一个常量无疑是将其误差放大了。记得《敏捷规划与估计》好像提出不要试图确定story与task之间的计算关系,并且这本书提出用story point/sprint来衡量team的开发速率。这带来了另外一个问题,做项目时,不同的sprint的长度可能不同,比如有的两周,有的四周,这样该如何处理呢?是先对不同长度的sprint分别估算速率还是...
不知大家对于这种情况如何处理?
1、一个工作日的理想工作小时为5个;
2、story point总数量乘以3(3是team的经验值),即是这些story总的要花费的小时数。总的小时数除以5即得出要花费的天数。
对规定1,我不反对;对于2,这个team这样做的目的也许是为了计算作完一个项目需要的时间,我认为笼统的乘以一个常量得出“理想”小时数欠妥。story point数量本身就是一个估算值,乘以一个常量无疑是将其误差放大了。记得《敏捷规划与估计》好像提出不要试图确定story与task之间的计算关系,并且这本书提出用story point/sprint来衡量team的开发速率。这带来了另外一个问题,做项目时,不同的sprint的长度可能不同,比如有的两周,有的四周,这样该如何处理呢?是先对不同长度的sprint分别估算速率还是...
不知大家对于这种情况如何处理?
本文探讨Scrum团队在拆分Story时的一种方法及其合理性。作者质疑将Story Point乘以固定系数来估算任务小时数的做法,认为这会放大估算误差。同时讨论了不同Sprint长度对团队开发速率的影响。
1285

被折叠的 条评论
为什么被折叠?



