传统的瀑布型软件工作模式的生命周期从需求说明书开始进行需求分析和评审，评审通过后交由研发团队进行设计与开发。可见，需求文档在软件生命周期中既是信息传递的主体，也是研发设计的依据，体现了一份契约精神。但详细的需求说明书有以下弊端：
●单向的信息传递，容易出现理解偏差。
●文档表达正式，导致开发团队忽视对其进一步探讨和确认，认为文档就是对的。
●书面文档扮演了证据的角色，不利于团队共享责任，而敏捷强调团队共享责任，不论是需求人员、开发人员和还是测试员，大家的共同目标是通过讨论、协作，正确理解需求之后把这些需求变成客户真正需要的功能，而不是单向的任务传递。
●编制详细的、表达准确需求文档需要花费大量的时间，如果需求变更频繁，则产品开发工期会延长，维护成本会提高。
敏捷使用Product Backlog来管理需求，Product Backlog是一个需求清单，按照需求的商业价值进行优先级排序，高优先级的需求被排在清单最上层。
Product Backlog是一个渐进明细的清单，主要有四大特点：
●Detailed合适的详细程度，高优先级需求更加明细，低优先级的需求粒度更大。
●Emergent涌现式的，需求是慢慢涌现出来的，渐进明细的。
●Estimated经过估算的。
●Prioritized／Ordered根据商业价值排好顺序的。
Product Backlog需求的主要表现形式是用户故事，即从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
●角色：谁要使用这个功能。
●活动：需要完成什么样的功能。
●商业价值：为什么需要这个功能，这个功能带来什么样的价值。(www.xing528.com)
用户故事通常按照如下的格式来表达：
英文：As a＜Role＞，I want to＜Activity＞，so that＜Business Value＞．
中文：作为一个＜角色＞，我想要＜活动＞，以便于＜商业价值＞。
附图2-15就是Leangoo的Product Backlog看板示例：
附图2-15 Leangoo的Product Backlog看板示例（包括列表和泳道两个维度）
典型的Leangoo教学看板布局如下：
●用户故事根据教学任务的优先级分为N个子故事，每个子故事形成一条泳道。
√子故事1：作为Android通讯录使用者，我希望通讯录视图为列表形式，每个列表项有联系人头像、姓名和手机号码。
√子故事2：用户单击列表项时弹出选项菜单，分别希望实现“添加联系人”、“删除联系人”和“编辑联系人”功能。
●创建“待办任务”、“进行中”和“已交付”三个列表，如果列表项显示团队成员头像，则表明该任务已经被排到当前迭代实施周期中。
√待办任务：已经排到当前迭代实施周期中，但还未正式开始的教学任务。
√进行中：正在实施的教学任务。
√已交付：已经完成的教学任务。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
