用户故事 应该可以估算。
如果您遵循其他方面 ‘Invest’ acronym,很可能会。 * E *中‘Invest’代表Estimatable;衡量用户故事是否良好的另一种有用方法。
那么,估计用户故事的潜在障碍是什么?
太大?
故事可能太大了吗?在这种情况下,只需将其分解为多个用户故事,直到更合理地进行估计即可。
信息不足,或需要领域知识
也许没有足够的信息,故事太含糊,或者需要领域知识来正确理解含义?在这种情况下,Scrum敏捷开发方法的两个方面可以帮助解决此问题…
首先在 Sprint规划研讨会(第1部分),与产品负责人和/或用户代表一起讨论需求。在您觉得已经足够澄清以真正理解需求之前,请不要尝试对其进行估算。捕获一些进一步的信息或说明 用户故事卡.
其次,在 Sprint规划研讨会(第2部分),将需求分解为任务;理想情况下,任务少于一天。团队合作。分解需求显然将有助于估计需求。将需求分解为少于一天的任务将使每个任务更具可预测性,因此估计结果可能更准确。
在Sprint之前及时进行Sprint计划的两个部分,并让整个团队参与进来,这将有助于确保团队中的每个人都了解需求。而且,重要的是,在开发和测试功能时,信息仍然是新鲜的。
新技术或团队知识不足
另一个潜在的障碍是该产品或特定的用户故事可能涉及团队以前从未使用过的新技术。首先,这意味着团队的生产力将降低,并且可能无法依靠他们过去的经验。其次,这意味着团队可能根本不知道如何实现它。
在这种情况下,团队中的某人需要能够完成简短的研究任务,然后才能估算出用户故事。这项研究需要有时间限制,他们只需要进行足够的研究和/或原型制作就可以更可靠地估算工作。理想情况下,如果可能的话,最好在Sprint计划周期内执行此操作’要花更长的时间,应该在Sprint待办事项中提交故事之前在Sprint的早期完成。它’值得保留一些用户故事,或者 伸展任务 或者如果研究确定该故事不能包含在当前Sprint中。在 极限编程,这项研究任务称为‘spike’.
所以,现在让’s look at my recent 用户故事的示例 看看是否感觉像’s Estimatable?
It’肯定不会太大。它’非常熟悉,没有’不需要任何领域知识。我们都知道如何登录系统并知道会发生什么。我不’t think it’含糊不清。实际上,我认为它包含有关此类小卡片的大量信息。从技术上讲’很简单。在我们的情况下,它是用熟悉的技术开发的。所以我’d说这个例子很容易估计,所以这个故事–至少在这方面– is good.
凯莉