怎么写userstory( 四 ) _userstory

计划会议的最终目的是让 scrum team 中的每个人都明确自己的工作量和依赖关系，而要确定这些东西的大前提就是需求足够的清晰明确，且 sprint 结束前都不发生任何变化。不变是 scrum 能像黑箱一样运行的大前提，试想，如果需求做到一半砍掉了或者发生很大的内容变化，以前开会定下的各种 task 就会发生根本变化，导致计划成为废纸一张，sprint 也就执行不下去了。
因此，一般 sprint 计划会议最终决策的时候，必须有 stakeholder 过来拍板认可，也算是在这个场合里给大家一个准信，确保这些 task 像泼出去的水一样不会再变了。需求稳定还只是一个要点，最终还是要落实到 task 上。
从需求到 task 其实还隔了几道墙，一方面并不是所有的需求都是真实需求，有时候 stakeholder 自己可能都不清楚自己想要什么，另一方面从产品概念到实现也不是一目了然，需要把各种细节提前约定清楚才行。这里面就需要引入一些需求分析的工具。
User story 是帮助需求分析的一个工具，各种敏捷方法貌似都比较推崇这种需求分析的方式，这种方式跟写一个需求分析文档或产品设计文档都没什么本质差别，只是个工具。从题主的描述来看，我猜想你所在的团队之前应该从未使用过 user story 来分析需求，所以感觉会比较虚也比较难以分解成 task 。
如果咨询顾问们无视你们之前的需求文档/产品文档的风格硬要用 user story 来套的话，有可能他们犯了形而上的错误。能够清晰的分解成可执行、短小的 task 的需求才是好需求，无论用 user story 还是拿友商的同类产品直接山寨还是老板某天洗澡突发的灵感，只要是个 stakeholder 想要做且细节都定义清楚了的需求都是好需求。
反之，如果无法分解，那就是需求分析的失败了，管你什么炫酷的方法都是浮云。像题主所说，一个任务给 200 或 300 的估计，那就是需求完全没有细化的结果，要知道那个数字的单位一般是小时，而一个 task 一般都不要超过 16 才对。
一旦需求分析完成，分解 task 就应该水到渠成才对。如果技术团队因为技术细节不确定而无法分解需求，那么暂停会议，会下讨论清楚再来。
分解 task 本身没什么好说，跟传统的分任务一回事，其中 scrum 比较可取的一点就是那个 planning poker，每个人把自己的时间当做资源，通过 planning poker 这种比较好玩的方式分配自己的时间直到时间耗尽。当然啦，这种形式本质上就是想确保每个人都能均衡的完成任务，免得出现瓶颈，如果达到同样的目的采用其他方法排任务也无妨。