The traditional waterfall working mode uses a detailed requirement specification to express the requirement, and the requirement personnel are responsible for the requirement research, compile the detailed requirement specification according to the research situation, conduct a requirement review, sign and confirm after the review and hand it over to the R&D team for design and development. In such an environment, the requirements document is the main body of information transmission and also a contract.
However, detailed requirements specifications have the following five major drawbacks:
- One-way information transmission is prone to misinterpretation.
- Documentation is so formal that we can mistake it for something that must be true, don't question it, let's stop making judgments.
- With detailed documentation, we won't go back and forth about it, mutual confirmation.
- Written documentation does not facilitate team sharing of responsibility, it acts as evidence. Scrum emphasizes the shared responsibility of the team. Whether it is a requirement personnel, a developer, or a tester, the common goal of everyone is to correctly understand the requirements through discussion and collaboration, and then turn these requirements into functions that customers really need, rather than one-way task delivery. .
- It takes a lot of time to prepare detailed and accurately expressed requirements documents, and if the requirements change frequently, the maintenance cost is higher.
Agile uses the Product Backlog to manage requirements. The Product Backlog is a list of requirements sorted by their business value. High-priority requirements are at the top of the Backlog. Product Backlog is a progressively detailed list, it has 4 main features, called DEEP:
- Detailed Appropriate level of detail, high-priority requirements are more detailed, and low-priority requirements are more granular
- Emergent emerges, the demand emerges slowly, gradually detailed
- Estimated Estimated
- Prioritized/ Ordered Ordered according to business value
In the product Backlog, the main form of requirement is the user story. A user story is a short description of a requirement from the user's point of view. User stories are the best way to shift the team's focus from describing and writing functional requirements to discussing requirements.
A user story describes the desired functionality from the user's point of view. A good user story consists of three elements:
- Role: Who will use this feature.
- Activity: What kind of function needs to be completed.
- Business value: why this function is needed, and what value does this function bring.
User stories are usually expressed in the following format:
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
英文：
As a <role>, I want <activities> to facilitate <commercial value>.
For example: As an ordinary member of a website, I expect that after I place an order, I can cancel the order before it is shipped, which is more flexible for me.
Leangoo is a professional agile development management tool that provides end-to-end agile R&D management solutions, covering agile requirements management, task collaboration, progress tracking, statistical measurement, etc.
Agile Requirements Management
We can create a Product Backlog Kanban through the Leangoo agile tool to manage agile requirements.
On the Leangoo agile Kanban board, we can customize and create multiple lists, and add demand cards to each list.
Usually we create these lists in the product backlog Kanban: "user story pool, user stories to be sorted out, user stories sorted out, user stories being implemented, user stories completed"
Generally, "user story combing completed" has the highest priority, and the user story pool has the lowest priority. The following figure is an example of a Product Backlog Kanban:
The icon in the lower right corner of the requirement card in the above figure represents the story points of this story card, some discussions on this story, and the key points of the acceptance test of the story, etc. The key points of acceptance testing are reflected in the form of inspection items.
In addition to workload, comments, and check items, we can also set deadlines, labels, etc. for cards, and classify or prioritize cards through labels. As shown below:
After the user stories are added, the team can sort out the user stories with higher priority. The task items needed to complete the user story can be added to the check items in the card, so that after the subsequent user story is planned in the Sprint, it can be easily disassembled into smaller task cards.
Through the list flow, let the team intuitively understand the priority and planning of requirements
Requirement planning to iteration Kanban for iteration
- Before the iteration starts, we need to plan the sorted out and high-priority user stories into the iteration Kanban, so as to prepare the content that needs to be completed in the iteration.
- Click the "Sprint Planning" button and drag the user stories planned to be done in "Sprint1" to the "Sprint1" board.
Each iteration has an important Sprint progress statistics - burndown chart.
The burndown chart is a simple and practical tool for tracking team progress in Scrum. It can visually display the remaining workload and the change trend of the remaining working time in the current iteration. Generally, the team will use the burndown chart during the daily stand-up meeting. Understand the current Sprint sprint speed situation.
Leangoo will automatically generate release burndown charts according to changes in story cards.
Click the "Menu" on the right side of the Kanban and select "Kanban Statistics" to view the burndown chart, as shown in the following figure:
Completion rate per iteration
The completion rate of iteration is to count the completion of each iteration Kanban in the project.
Configure Kanban cycle and burndown chart, Leangoo will automatically count the completion of each iteration Kanban, and automatically generate visual statistical charts, so that the management can see the completion progress of each iteration at a glance.
Statistics for each iteration team velocity
Team Velocity is the actual amount of work done by the Scrum Team in a Sprint (usually using story points as the unit of Team Velocity).
After each Sprint is over, Leangoo will automatically record the workload completed in the current Sprint, and automatically generate a visual statistical chart of the team rate, so that the team can understand and analyze the trend of team efficiency changes.
Through the above methods and statistics, we can manage agile requirements well.
Finally, there is a reminder that agile emphasizes transparency, so it is very important to manage the product backlog visually. If conditions permit, we can consider visualizing the product backlog through a large display screen. It would be better to have a large touch screen TV.