本文更新内容以转自  

---------------------------------------

Scrum的基本概念其实并不复杂，但是想做好并不容易，大家都知道product backlog的重要性，但是我们如何制定和展现它，如何评定优先级，如何进行初始评估？下面我将介绍和product backlog相关的一些问题。

在介绍了流程，这里主要介绍第一个最重要的工件 Product Backlog。它是Scrum的核心，也是一切的起源。它是由Product Owner负责制定的一个按照重要性的级别排序了的故事列表。

 一般按照轻量级的故事来进行描述需求。用户故事是最基本的设计单元，它是从系统用户或者客户的角度出发对功能的一段简要描述。用户故事的形式很自由，没有什么强制性的语法。但是，按照大致符合这样一个形式来考虑 用户故事是比较有益的：“作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到...的结果】以便【业务价值】。”以这样的模作为例子，可以得到一个用户故事说：“作为购书者，我希望可以根据ISBN来找到一本书，以便能更快的找到正确的书。”在做用户故事时，需要注意每个用户故事用的是用户的语言，它只描述一个功能（feature），而且每个用户故事的开发周期不要太长（1－5天）

 我们不需要一开始对所有的故事都进行详细的描述，但计划放在下一个sprint中的故事应该比较清楚。可以按照硝烟一书中的表格来写backlog的故事：

 

ID为一个唯一标识，确定后最好固定不变，在其他工作或者文档中想引用故事就使用这个ID来引用

Name2到10个字，通过简单的描述来说明故事，如果要很多字才能表达这个故事，那很有可能这个故事太大，或者不清楚

重要性 这个优先级决定了sprint选择的故事，优先级越高的越早实现

初始估算 这个由Team来根据故事描述内容来估算，产品负责人讲解完故事后，Team对不清楚的进行询问，大概了解后进行粗略估算。从估算的角度出发，故事不应该太短，但也不能太过于详细，不需要把具体的规则和算法写进去。

How do demo 从用户视角，从操作层面进行讲解这个故事如何通过软件来演示，也可以作为一个简单的测试用例了。重要性高的backlog条目都要填写”如何演示“。

Notes相关信息、解释说明和对其他资料的引用等，一般都非常简短。

有时我还会增加一个分类列来标识出故事的主题，通过主题来从更大视角来查看需求主要内容，后期也可以根据主题的优先级来初始确定故事的优先级。

• 
  
• 怎么拆分故事

• 怎么评定优先级

• 怎么进行初始评估

 

 

推荐：

敏捷个人sina围裙：    

欢迎转载，转载请注明：转载自