The traditional waterfall operating mode using the detailed requirements specification to express their needs, the needs of persons responsible for doing research needs, the preparation of detailed fact sheets needs based on research carried out needs assessment, signature confirmation to the research and development team designed and developed after review. In such an environment, requirements document is the subject of information transmission, but also a contract.
However, the detailed requirements specification has the following five major drawbacks:
- One-way information transfer, prone to be understood that deviations.
- Formal document, we will think it must be right, do not question it, let's stop judgment.
- With detailed documentation, we will not discuss it again, mutual recognition.
- Written documentation is not conducive to shared responsibility team, which played the role of evidence. Scrum team emphasized shared responsibility, regardless of demand, developers and testers still, our common goal is through discussion, collaboration, after proper understanding of the needs of these needs into customers really need function, rather than one-way tasks are passed .
- Preparation of detailed, accurate expression of the requirements document takes a lot of time, if the requirements change frequently, higher maintenance costs.
Agile Product Backlog use to manage demand, product Backlog is a list of requirements, in accordance with the needs of the commercial value of the sort of high-priority demand of the uppermost layer in the Backlog. Product Backlog is a gradual breakdown of the list, it has four main features, known as DEEP:
- Detailed appropriate level of detail, the high-priority needs more detail, more low-priority needs of granularity
- Emergent style emerged, demand is slowly emerging from the gradual breakdown of
- Estimated after estimated
- Prioritized / Ordered in good order according to business value
In the Product Backlog, the demand is mainly in the form of user stories. User story is a brief description from the user's point of view on demand. User stories are the focus of the team from the description, write functional requirements transferred to the best way to approach demand.
User stories are described from the user's perspective eager to get user function. A good user story consists of three elements:
- Cast: Who use this feature.
- Activities: What kind of function needs to be done.
- Business Value: Why do you need this feature, which brings what kind of value.
User stories are usually expressed in the following format:
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
Chinese:
As a <character>, I want <event> in order to <commercial value>.
For example: as an ordinary member of a site, I expect until after I place an order, shipping can not cancel the order, which is more flexible for me.
We are currently in the country with an agile tool Leangoo doing demand management!
Leangoo is a very simple Kanban collaboration tools, we can create products Backlog Agile Kanban by Leangoo to manage demand. Priorities and planning arrangements for visual management of product backlog items by leangoo billboards, the whole team is very intuitive understanding of the needs.
The figure is a Product Backlog Kanban example:
In Leangoo on billboards, we can create multiple lists, then add story cards on each list.
Because we need to the recent high-priority needs into the Sprint, so the billboards can create these lists: the original requirements to be finishing later iterations, the next iteration to be combing the story, the next iteration ready story, the current iteration ,paid.
We can according to the priority needs of the demands were placed in these columns. The current iteration of the highest priority.
After establishing a good column, we can increase the previous list inside the card, each story card.
We can add workload, and acceptance testing elements of the story to each card. Acceptance test points reflect the way check items.
In addition to work, check the item, we can make some discussion on this story, that comment may be one member of @!
We can also set labels to card
Tags are usually used to classify the card, you may be marked with a priority card!
（每张卡片的优先级可以位置来决定的，每个list里面的卡片根据位置对卡片进行强制排序，高优先级的卡片放到最上面，低优先级的需求卡片在下面）
卡片ID
我们也可以为每一张卡片设置ID,便于卡片定位沟通和跟踪，在菜单栏开启就可以。
卡片多选
当我们开启卡片多选的时候 可以批量移动卡片，为卡片批量添加标签，为卡片批量添加成员等等 ，这也是我最爱的功能之一
燃尽图
当一个迭代结束时，我们要对完成的故事进行评审会议，评审通过的故事可以挪到已交付的列表中。
Leangoo会根据故事卡的变化自动生成发布燃尽图，点击菜单-看板统计，就可以查看！不仅有燃尽图 还有任务周期，任务分布等
如下图所示：
通过上述的方式，我们就可以很好的管理我们的产品Backlog了。
最后还有一点提醒，敏捷强调透明性，所以，可视化管理产品backlog很重要，如果条件允许，我们可以考虑通过大的显示屏幕将产品Backlog进行可视化，有触屏大电视会更好。
---------------------
作者：一只鲸鱼
来源：CNBLOGS
原文：https://www.cnblogs.com/shineshine/p/9505022.html
版权声明：本文为作者原创文章，转载请附上博文链接！
内容解析By：CSDN,CNBLOG博客文章一键转载插件