聊聊用户故事的估算和拆解

用户故事的大小与拆分

文章讨论了在Scrum框架下估算和拆解用户故事的难点。用户故事的大小从大到小依次为Epic、Feature和User Story，且理想的用户故事大小不应超过2-3开发人日。提出了9种常见的用户故事拆分方法，包括按工作流步骤、业务规则变化、主要/次要工作、业务简单与复杂、处理数据变化、界面变化、性能规格、操作边界拆分，以及拆出探针故事。

估算用户故事的方法

估算用户故事的大小通常采用集体评估方式，例如使用斐波拉契扑克牌和T恤尺寸等方法，做出相对大小的评估。估算前需要PO提供故事的详细信息，并允许团队成员提问。估算过程中，成员背靠背展示评估结果，若出现分歧则进行解释和重新估算。重要的是形成对需求价值和复杂度的共识，而不是追求精确度量。

技术团队的迭代速率与故事点数

技术团队的迭代速率是已知的，通过故事点数可以评估完成交付计划需要的迭代次数。史诗故事点数范围大，特性故事点数和用户故事点数较小。监控迭代开发速率对于提高测试速率估算准确性和人员效率至关重要。迭代燃尽图是监控工具之一。

用户故事实践中的热门问题

故事点不宜用于绩效考核，因为会影响团队协作和估算准确性。迭代规划时，故事优先级的确定应考虑用户利益、成本效益、内聚性和近期发布计划。MoSCow规则可以用于分类优先级。对于迭代中的需求变更，应估算新需求的故事点数，并相应调整低优先级故事。需求冗余问题通常由业务方风险规避、缺乏安全感、图省事或预算制度导致，应通过有效沟通和信任建立来降低。

任务与用户故事

用户故事可以继续拆解为任务，如设计、单测等，它们在团队的DoD中定义。任务的跟进关注的是团队集体成果，避免追踪个人进度，并建议单个任务不超过1理想人天。