The traditional waterfall working mode uses the detailed requirement specification to express the demand, the demand person is responsible for the demand investigation, prepares the detailed requirement specification according to the investigation situation, carries on the request appraisal, after the appraisal signature confirms to the research and development team design development. In such an environment, the requirement document is the subject of information transmission and a contract.
However, the detailed requirements specification has the following 5 major drawbacks:
- One-way information transmission, easy to understand deviation.
- The document is very formal, we will mistakenly think it must be right, not to question it, let us stop making judgments.
- With the detailed documentation, we will not discuss it over and over again and confirm with each other.
- Written documentation is not conducive to team sharing responsibility, it plays the role of evidence. Scrum emphasizes the shared responsibility of the team, whether it is the needs, the developer, or the tester, and the common goal is to translate the requirements into the functionality that the customer really needs, rather than one-way task delivery, through discussion, collaboration, and understanding of the requirements.
- It takes a lot of time to compile detailed and accurate requirements documents, and if the requirements change frequently, the maintenance costs are higher.
Agile uses the product backlog to manage demand, and the product backlog is a checklist of requirements, sorted by the business value of the demand, and high-priority requirements at the top of the backlog. The product backlog is a list of progressive details, which has 4 main features, called Deep:
- Detailed the right level of detail, high-priority requirements are more detailed, and low-priority demand granularity is greater
- Emergent emerging, demand is slowly emerging, gradual breakdown of
- Estimated the estimated
- Prioritized/ordered in order according to business value
In the product backlog, the main form of demand is the user story. A user story is a short description of the requirements from the user's point of view. User stories are the best way to shift the focus of a team from describing, writing functional requirements to discussing requirements.
A user story is a user's point of view to describe a user's desired functionality. A good user story consists of three elements:
- Role: Who wants to use this feature.
- Activity: What functions need to be completed.
- Business value: Why this feature is needed and what value this feature brings.
User stories are usually expressed in the following format:
English:
As a <role>, I want to <activity>, so that <business value>.
Chinese:
As a < role, I want to < activities to facilitate < business value >.
For example, as a regular member of a website, I hope that after I place an order, I can cancel the order before it is shipped, which is more flexible for me.
Leangoo is a very concise Kanban collaboration tool that we can use Leangoo to create product backlog Kanbans to manage agile requirements. is an example of a product backlog Kanban:
On the Leangoo Kanban board, we can create multiple lists and then add story cards to each list. Because we need to put recent high-priority requirements into the sprint, you can create these lists on the Kanban board: Sprint 1, Sprint 2, Sprint3, Sprint 4-n, you can put the requirements into these columns according to the priority of your requirements. Sprint 1 has the highest priority, and sprint4-n has a lower priority level. If your product needs cannot be predicted after 3 sprints, you can create fewer columns, such as Sprint 1, Sprint2, Sprint3-n.
Once the column is set up, we can add cards to the list, one card per story.
The three icons in the lower right corner of the card represent the story points of the story card, some discussion of the story, and the key to the acceptance test of the story. The acceptance test points are reflected in the way the items are checked, as shown in:
In addition to the workload, comments, and checklists, we can also set a color label for the card and classify the card by tag. As shown in the following:
In Leangoo, the priority of each card is determined by its location, each card in the list is ordered according to the position of the card, high priority cards are placed on top, low priority demand cards below.
When the end of an iteration, we have to review the completed story, the story can be moved to the delivered list, Leangoo will automatically generate a release Burndown chart according to the story card changes, click on the Burndown chart icon behind the Kanban cycle to view the Burndown chart, as shown in:
By the way above, we can manage our product backlog very well. Finally, there is a little reminder that agility emphasizes transparency, so it is important to visualize the backlog, and if conditions permit, we can consider visualizing the backlog through a large display screen, which is better with a large touchscreen TV.
This paper
Liao Jingbin Eric Liao, CSP,CSM, a renowned agile instructor, consultant, trainer
This article transferred from: leangoo.com
How to do demand management and planning with Leangoo? (Product backlog, user stories)