我猜想有很多情况下估计在某些时候是错误的.因为只要深入了解积压项目的细节,您就可能几乎总能找到在规划期间没有考虑过的事情.这可以在任务级别sprint估计期间或在实际sprint期间发生.
在任务级别估计期间,您可能会发现故事/积压项目的许多任务,因此需要调整初始估算. 你现在做什么？您是否回到产品所有者并告诉他他可能想要重新确定其积压物品的优先顺序,现在需要更长时间(甚至更少)？基本上它可能意味着整个团队需要回到故事级别的估计并重新调整故事？
在sprint期间,您可能会发现实现需要比最初想象的更多的努力. 你现在做什么？知道你无法按计划完成它,你是否默默地继续冲刺？从现在开始,您将为所有估算添加"安全缓冲区"？
一般来说,SCRUM如何解决整体估算精度问题？
如果我理解正确,那么SCRUM开发团队就会"承诺"产品所有者将按计划交付.但只有准确估计才能做到这一点.所以估计似乎对SCRUM的成功非常关键,但也非常困难.
简单的事实是,估计准确性在术语上是矛盾的.就像独角兽一样,它根本就不存在.根据定义,估计不准确.
考虑到这一点,Scrum和其他敏捷方法试图解决这个限制,而不是打倒风车.在Scrum中,对产品Backlog项目(用户故事,需求等)的复杂性进行了先验估计,以便让产品所有者大致了解他可以在即将到来的sprint中完成的故事数量.在将PBI分解为任务之后,根据他们认为完成任务所需的时间来估算每项任务.一旦团队的能力得到满足,他们就可以(略微)更好地估计他们在冲刺结束时能够提供什么.
这些估计仍然不准确.
敏捷产品所有者处理这种不准确性的方式是降低交付产品的延迟成本.PO定义并优先处理他的故事,以便尽早交付产品中最重要的部分,并尽早创建(仍然不完整)可用且有价值的产品.这样,任何未及时完成的任务(sprint结束或发布日期)仍然是可以交付的最佳产品,并且通常可以在时间之前创建足够好的发布,其余的,最不重要的功能在不久之后,小批量.
这就是Scrum处理估计(准确)的方式.