本文为您介绍 Scrum 敏捷管理模式中的故事点功能。
进入项目
1. 登录 CODING 控制台，单击立即使用进入 CODING 使用页面。
2. 单击页面右上角的 
3. 单击左侧菜单栏中的项目协同功能页。
功能介绍
传统软件团队使用时间估算工作量，但敏捷团队一般使用故事点来估算软件规模。故事点可使用改良斐波那契数列：0，1⁄2，1，2，3，5，8，13，20，40 或 T 恤尺码：XS，S，M，L，XL 来估算。这种抽象的概念可以帮助团队围绕工作规模做出更好的决策。
CODING 项目协同支持对事项（用户故事、需求、任务、缺陷）进行故事点配置、录入、编辑、查看，还支持查看迭代的故事点总数。
配置故事点
故事点在创建项目时默认开启，可以在项目设置 > 项目协同 > 敏捷特性页面中进行配置。默认估算方式为改良斐波那契数列，可以更改为T 恤尺码。
注意：
修改故事点估算方式后，已存在事项的故事点数据将会清空，请谨慎操作。
使用故事点
录入故事点
在新建事项（用户故事、需求、任务、缺陷）时，可以为事项设置故事点。
查看故事点
在待规划、迭代详情页、事项（用户故事、需求、任务、缺陷）概览及详情页，均可以查看故事点。
待规划中不仅显示单个事项的故事点，也会统计并显示Backlog或迭代内所有事项故事点的总和。
迭代详情页与事项概览页中默认不显示故事点，可通过右上方表格显示设置开启并调整显示优先级。
拓展阅读
故事点和工时的区别
传统软件团队使用工时估算工作量。工时是一种绝对估值的方式，它的估算方法常常会依赖于历史经验信息。
故事点是敏捷研发模式中估算软件规模的方式，是一种相对估值的方式。也就是说针对两个需求，可以估计这个需求比另一个需求更大，但不确定每个需求的准确工作量。
在实际使用中，两种估算方法没有优劣之分，只有适不适合的考量。良好的估算实践有助于团队掌握项目的成本和盈利能力，还有助于团队对要交付的需求规模、优先级以及价值达成共识，从而更好地作出业务决策。
什么是斐波那契数列
斐波那契数列：0、1、1、2、3、5、8、13、21、34、……
该数列的递归关系可定义为：f(0)=0，f(1)=1，f(n)=f(n-1)+f(n-2) (n≥2，n∈N*)。也就是说除了 0、1 两项之外，第 n 项的值等于前两项的和：
1=0+1
2=1+1
3=1+2
8=3+5
...
为什么使用改良斐波那契数列作为描述故事点的方式？
敏捷研发模式中的故事点，通过使用对比的方式来估算任务规模。在改良斐波那契数列中，当数字越大，相邻数之间的间隔也会越大，使得我们更容易区分哪个任务规模更小哪个更大。例如：21 与 34 之间的差距非常能够说明差异，但过度纠结于 34 还是 35 就很不敏捷。
两种故事点估算方式该怎么选？
T 恤尺码估算方法适合估算大型用户故事的海量需求列表，估算粒度相对粗糙，但比较快速。
改良斐波那契数列的估算方法适用于小型用户故事的较少需求列表以及小团队，估算粒度相对精准。
如何让故事点的估算更加有效？
在实际敏捷研发过程中，由于业务本身的不确定性、经常会出现的新变化因素，以及个人主观因素等原因，导致估算的点数与最终实际情况出入较大，那么以下几个提高故事点效率的方式希望能启发到您：
让任务相关人都参与到估算中。 了解的信息越发全面，得到的结果也更加成熟。同时估算的过程让团队成员们分享各自的逻辑、经验与假设，也有助于团队的步调协同。
参考之前的实际工作。 在回顾迭代时，也回顾和反思估算的准确性，让下一次的迭代估算更加准确和容易。
选择适合的故事点估算方法。 对于不同类型、规模的项目，所适用的估算方法也不一样。比较受欢迎的估算方法包括：计划扑克（Planning Poker）、T 恤尺寸（T-shirt size）、点投票（Dot Vote）等等。
是
否
本页内容是否解决了您的问题？