Shulou(Shulou.com)06/03 Report--

Is the Product Backlog sufficient for agile requirements management?

Agile methods guide teams to manage product requirements in a Product Backlog and prioritize each product requirement as necessary. Before the Planning Meeting, the Product Owner selects the Willing List of iteration cycle preparation development from the Product Backlog for overall introduction, and then assigns it to the Sprint R & D process. Pure agile methods, represented by Scrum, believe that requirements analysis is not necessary in the first place because requirements are constantly changing. Therefore, the concept of Story is put forward, and it is believed that the requirements should be expressed in a similar storytelling way to the requirements, so that the original customers can clearly express the requirements, and the same development and testing will gradually think about their own work with the customer's requirements. So that we can all think at the level of needs.

However, in the widespread use of agile methods, the limitations of pure agile methods have been discovered:

Unable to support full traceability driven by requirements;

The fundamental premise is that the entire team is fully committed to the development of the project, and any change in the direction of the development team can lead to the collapse of the project because requirements are always changing.

Practice surveys have found that the success of more large projects depends on overall project planning and control at the requirements level through requirements workflow, requirements analysis, and requirements traceability management. In agile processes, Product backlogs alone are insufficient to meet requirements management. Usually, the development process of a project is expressed in three spaces: requirements space, development space and QA test space. The three spaces should be fully integrated with each other so that the different functions of the entire team can work together. Today we will start by exploring demand space!

What is demand space for?

In SpecDD model, user requirements are registered in the requirements space. Agile advocates customer value orientation and should be described from a customer value perspective, that is, describing how customers use it, rather than describing how it is achieved at the technical level. We like the way Story expresses user needs, but this does not mean that the management of user needs is messy, random and disorderly. Product owners need to refine, itemize and prioritize product requirements with the help of requirements workflow, requirements analysis and requirements traceability management. Through the requirement space, the detailed and quantified SPEC is formed for the user requirements.

There is often a many-to-many relationship between requirements and SPEC, that is, a requirement may be split into multiple SPEC, and a SPEC may come from multiple original user requirements. The actual development tasks and testing tasks often need to be decomposed and allocated based on specific SPEC. In this way, with the help of systematic management of the requirements space, the project leader can better track the product functions, user requirements, development tasks, test cases, product defects, etc. associated with the requirements, and realize the traceability management of requirements.

Is the Product Backlog replaced when there is demand space? How should it be used in practice?

The clear answer is that with the requirement space, we still need the Product Backlog, and the Product Backlog will continue to play an important role. First of all, we make it clear that the Product Backlog stores the requirements for the development team and serves the development team more. How to understand this? You might say that requirements for the development team should of course be in the Product Backlog. However, in actual project progress, the following two practical problems are often encountered.

Question 1: Requirements are still in design or collated, but have not been decided to let the development team implement them. Do these requirements need to be stored in the Product Backlog to manage them?

Answer: Of course, it can be placed in the Product Backlog to manage, and it is good to distinguish it by specific fields or title identifiers.

Comment: With this approach, you can still use Excel to manage product backlogs. But as user demand increases, or when the project is large, you'll need a 47-inch monitor and eagle eyes to manage the Product Backlog list.

SpecDD believes that only when the requirements decide to develop, there needs to be an allocation; when there is an allocation, it needs to be placed in the Backlog. Otherwise, it can be hidden even from development and testing departments when a requirement is still in the design phase, or when it has not been decided whether it needs to be implemented. With this improvement, you can better control and manage the Product Backlog list. Once the requirements are assigned to the development team, they are removed from the Backlog. New and finished parts can be assigned to the development team's pending requirements and then moved from the requirements space into the Product Backlog. Such improvements allow the Product Backlog to implement the original ideas of Scrum and help project managers quickly locate tasks that need to be developed from a vast ocean.

Question 2: A requirement contains a large amount of development work. At the beginning of Sprint 1, the requirement is allocated from the Product Backlog, but in Sprint 2, the same requirement needs to be iterated, but the requirement no longer exists in the Product Backlog. What should I do?

Product Owner: Move previous requirements from Sprint 1 to Sprint 2?

Project Manager: Wouldn't that distort Sprint 1's work history?

Product Owner: Or create an identical requirement in the Product Backlog and assign it to Sprint 2?

PM: Wouldn't that be a duplicate requirement item?

Obviously neither idea is good. SpecDD provides a realistic answer to this question. SpecDD believes that the Product backlog and requirements space are integrated with each other, except that requirements (Epic/Spec) are not directly assigned to the Product Backlog or Sprint from the requirements space, and when the product owner decides to implement them, requirements are assigned to the Product Backlog in the form of Story. Story is a realisation assignment of requirements.

SpecDD model believes that user requirements do not need to be stored directly in the Product Backlog, otherwise more and more task queues will be made in the Backlog, which will affect the task priority arrangement. Backlogs should be kept as small as possible to avoid putting requirements directly into backlogs, but it is better to put Stories and Tasks into backlogs. Once a Story is assigned, it is removed from the Product Backlog. A requirement, if the workload is large and needs to be completed through multiple iterations or multiple teams working together, then multiple Stories can be generated for allocation according to the development situation. Of course, you can also think of Story as a pointer to requirements, that is, through Story, the development team can directly view the description information of specific Epic/SPEC and obtain upstream and downstream requirements. A Story assigned to a development team can contain a categorized set of development tasks, all of which are related to derived Stories and split tasks, all of which can be tracked and tracked in Epic/SPEC entries in the requirements space. Thus, the project leader and management team can firmly control and plan the progress and quality of the project from the demand level.

From the above series of discussions, we can see that pure Product Backlog is not enough to achieve requirements management. Systematic requirements management by introducing requirements space, repositioning the role of the Product Backlog and defining the Story concept will help the team decide on product features, and can be traced directly from the software product results, and improve the delivery accuracy of executable products. Efficient and flexible delivery of executable products allows users to propose changes earlier, so that the overall progress of the project remains healthy, and management does not have to worry about team changes and turnover, so that the enterprise cannot find the team discussion and decision process experienced when creating product features.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.