使用已完成的用户故事估计未来的用户故事

Question

在Scrum/Agile中，用户故事的复杂性可以用故事点来估计。在完成一些用户故事之后，程序员或程序员团队可以使用这些经验来更好地估计完成未来用户故事所需的时间。

是否有将用户故事的复杂性分解为可量化或可量化属性的方法？

例如，用户Story需要GUI中丰富的、新的视图，但是用户Story可以使用服务器上现有的业务逻辑来执行其大部分功能。在1到10的范围内，用户Story在客户机上的复杂度为7，在服务器上的复杂度为2。用户故事X完成后，有人会问用户故事Y需要多长时间才能完成，它在客户机上的复杂度为3，在服务器上的复杂度为6。看一下完成用户故事X需要多长时间，我们可以对完成用户故事Y所需的时间做一个有教养的估计。

我可以想象到其他一些细节：

• 一个属性的复杂性(例如客户端的复杂性)可以有子属性，例如序列中的步骤数、功能点等。
• 还可以考虑其他几个属性，例如程序员对系统的熟悉程度或所涉及的组件/接口的数量
• 这些属性可以累积到某种用户故事清单中。

重申:是否有将用户故事的复杂性分解为属性/子属性复杂性的现有方法，还是使用完整的用户故事作为指标来估计未来的用户故事更像是一个非正式的过程？

Answer 1

根据我的经验，这是非常非正式的。如果团队经验丰富，他们应该能够查看一个故事，并决定它是否需要与另一个故事相同的努力，或者更多，或者更少。故事点只是近似的，所以只要你的判断前后一致，准确性就不是什么大问题。

Answer 2

> use (those) experiences to better estimate how much time 
> it might take to complete a future user story.

函数_点_分析焦平面不是基于用户故事的，但是一旦有足够的经验，估计可能会有帮助。

fpa的“属性”是指输出、查询、输入、内部文件和外部接口。