交付有价值的产品,先澄清用户故事吧!
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
在VUCA时代,客户需求的易变、不确定、复杂和模糊特性要求我们加强与客户的沟通,使用用户故事来明确需求,打造有价值的产品。以下内容提供了关于用户故事的澄清方法。
1. 谁来编写用户故事?
用户故事通常由最接近用户的角色编写,如客户或产品负责人。若由测试或开发人员编写,需要经过客户和产品负责人确认。用户故事的优先级也应由贴近用户侧的人员确定。发掘用户需求可以通过访谈和市场调查,并按照INVEST原则编写用户故事。为了提高团队成员的积极性,可以让每位成员参与编写。
2. 什么时候使用用户故事?
用户故事用于明确角色、功能和目的,通常在实现功能前使用。不是所有任务都适合以用户故事形式表达,只有能直接为客户创造价值的需求适用。团队内改进问题则用其他共识方式表述。
3. 用户是谁?
项目管理时需与用户沟通,了解真实需求和使用场景。技术团队需清楚用户身份、位置和需求。可用用户画像、影响地图等工具精准获取需求。对于中间件和微服务,可将上下游系统作为用户。
4. 用户故事规范
用户故事规范对于有效编写非常关键,具体编写方法可以通过学习相关实践了解。
5. 勿以唯故事点论
虽然用故事点估算用户故事,但不应过度关注。故事点没有统一标准,不宜作为团队间对比或绩效管理的依据。重点应放在功能交付上,而非故事点完成量。
6. 定义“就绪”“完成”与“验收标准”
在迭代计划前确认用户故事的“就绪”状态,团队需就“就绪定义”达成共识。用户故事的完成标准需统一,避免沟通成本增加。验收标准需团队、客户和产品负责人共同讨论,确保满足用户期望。
最终,用户故事应明确角色、动作和期望结果。文中以网站注册为例,展示了用户故事的编写。通过正确有效地使用用户故事实践,可以推动项目的成功。
想要了解更多内容?