Man*_*uPK 1 agile estimation user-stories
在敏捷过程中,故事点是复杂性而非时间的衡量标准.这对于一个不那么复杂但需要更多时间来完成的故事来说有什么用呢？
让我举一个例子,
故事1:保存用户详细信息.
Story points = 2. Typically Takes about 1 day to complete.
故事2:公司名称已从X更改为Y,这需要在应用程序中更新.大约有40个屏幕,10个报告,法律声明所有这些都应该改变.
这是一个简单任务的典型示例,但实现(考虑本地化应用程序,即使遵循适当的开发标准)和测试也需要花费大量时间.
如果我按照传统的定义,我会给故事点1,但是我看错了速度,即使在做好工作之后速度也会下降.我看过这篇关于这个问题的文章.
My question is how this task can be compared to the first story and should the effort be included in story point estimation?
我几乎确信这个想法,但想知道在这种情况下使用的最佳做法,或者如果有任何好文章我可以阅读它？
小智 5
"与故事相关的故事点数量代表故事的整体大小.没有用于定义故事大小的固定公式.相反,故事点估计是开发特征所涉及的努力量,开发特征的复杂性,其中固有的风险等的合并." - 来自Mike Cohn的敏捷估计和规划.
在我的开发团队中,我们根据大小和复杂性来估计故事.我向新团队成员描述的方式是将大小和复杂度视为图形上的两个正交轴.这允许在复杂性方面不同的故事,但在相反方向上的大小(努力)同样不同以被认为是相对相同的.
根据个人经验,我们发现如果只考虑复杂性,那么您的团队可能会无意中低估需要大量工作量的故事.这将避免您的积压估计,并使使用三角测量等技术更难以保持估计相对.