敏捷开发产品的策略是“整体规划，小步实施”，其中的小步实施，指的就是用户故事。
题主的困惑在于“如何设定这个”故事的大小“，是一整个流程，还是一个具体的功能点。”，也就是说，用户故事怎样去界定？什么样的用户故事才是好的，可以进入研发环节的，什么样的故事才是大小适当的？如何去拆分故事呢？
在开始一个项目之前，首先，需要创建整个产品的用户故事地图，当然，最初的用户故事地图是粗糙的，其中的故事有大有小，比如创建一个网站，可能会有这些大的故事（大颗粒的）：
- 用户注册登录
- 查看个人中心
- 定制宣传页
- 发布产品信息
其中”发布产品信息“显然是一个大的故事，这样的用户故事给到研发团队肯定是要被喷的，因为研发团队完全不知道其中的细节，该如何去实现它，呈现什么样式，为了便于研发团队进行开发，所以需要将大颗粒的故事拆分成一些小颗粒的故事：
- 创建产品详情页
- 查看以库存产品
- 定制产品规格
- 查看产品详情页
- 筛选条件
……
这样拆分过后的故事就比较明确了，描述的是特定类型用户的行为，研发小伙伴也很明确的知道要什么，开发的是什么功能，当然，这样的故事还是比较单一的。 一个好的、合理的用户故事，不仅要展示需求的场景、是谁、要达到什么目的。
通常用户故事是以三段式的形式展示的：
- 作为【一个用户】
- 我想要【某个产品特性】
- 这样我就可以【获得某个收益/满足某种需求】
然后就是如何让将需求拆分成大小合适的用户故事呢？ 从用户角度看，大小规模恰当的故事，是一个可以满足某一需要的故事。从业务角度看，大小规模适当的故事，是一个有助于实现业务目标的故事。
大故事分解为小故事，小故事又可以进一步分解更小的故事。在《用户故事地图》这本书中，作者提出，对话是拆分故事的最好的工具，与开发人员、测试人员以及其他参与软件开发的人一起对用户故事深入探讨，真正深入了解细节，在对话中，对交付产品的各个小模块的验收标准达成一致。
一个好的用户故事，理想的情况是所写的故事能够让一两个程序员花半天到两周实践完成代码和测试。
在《用户故事与敏捷方法》中，作者指出一个优秀的用户故事应该具备六个特点：
- 独立的（Independent）——要尽量避免故事间的相互依赖。
- 可讨论的（Negotiable）——故事是可以讨论的。
- 对用户或客户有价值的（Valuable to Purchasers or User）——每个故事必须对用户有价值。
- 可估计的(Estimatable)——对开发人员来说，能估算故事的大小，或者是把故事变为可用代码时间量是很重要的。
- 小的(Small)——故事大小很关键，故事太大或太小，都无助于制定计划。
- 可测试的(Testable)——故事必须是可测试的，成功通过测试可以证明开发人员正确地实现了故事。
一般用INVEST原则来代表这六个特征。
比如购物网站里的搜索，”用户可以搜索商品“，这个故事如果是和客户交流时可能是比较恰当的，可与开发人员沟通时，这个故事就不是很恰当了。因为”搜索商品“还包括以下几点：
- 搜索可以搜索商品标题、商品详情、
- 搜索是模糊搜索
- 搜索可以设置搜索条件
- 搜索条件可保存、编辑、删除、常用搜索条件
当然，前面所讲的是一个优秀故事的原则以及如何将大的故事，拆分为一些小故事，但故事也不需要太小，比如题主问题中的例子，在购物网站的搜索中：
- 搜索结果可以按照创建时间排序
- 搜索结果可以按照评论量排序
- 搜索结果可以按照评分大小排序
- 搜索结果可以按照店铺等级排序
显然，这几个故事可以很大程度上可以统一实现，在做迭代计划时，可以将这些故事合并起来。
需求管理
如前面所说，通常敏捷开发中将需求通过用户故事来呈现，需求管理影响着整个项目的成功与否 ，需求管理的重要性不言自明，借助一些研发管理工具来进行用户故事管理，对项目的成功和高质量的产品交付有着至关重要的作用。
这里毛遂自荐一下我们自研的精益敏捷研发管理工具——鲸舟
产品负责人以三段式书写用户故事，设置优先级，引导团队聚焦高价值需求交付，通过定义验收标准、与团队一起进行故事估点、确保不同研发角色对其理解一致，高效准确的完成研发工作。
在鲸舟中，各个业务需求方、客户需求等不同业务部门，可以通过创建【需求空间】记录和描述初始需求，团队成员在与业务或客户沟通明确需求后，可设置需求进入迭代计划列表，支持对大的用户故事进行拆分，快速创建子工作项。
以上部分，权当抛砖引玉，如你的团队正好需要一款优秀的敏捷研发管理工具，欢迎来试用。
30人团队以下，永久免费！
