How to write an agile iterative PRD
Preface
There are about several software development methods, namely waterfall mode, iterative incremental mode, spiral mode, and agile development. Compared with other modes, agile development has the advantage of short development cycle (one to two weeks is a cycle) and more emphasis The team’s high degree of collaboration and quicker response; in the Internet era, time is money, and spending an extra day on development means burning an extra day. Therefore, the agile development model is more commonly used today.
The biggest characteristic of agile development is the iteration cycle. An agile version of the PRD document must match this characteristic, otherwise the iteration will be disrupted, and the iteration will be delayed, and the agile development will become waterfall development. The results of an iteration in two weeks will slowly be delayed. Into an iteration a month.
After knowing that the agile version of PRD must have iterative characteristics, here is a PRD template summarized by the agile development team. Unlike other luxurious and beautiful templates, this one is more suitable for agile projects and can quickly respond to iterative development needs. . Let's explain in detail this agile PRD document.
1. Agile version of PRD document directory
The directory structure of the agile version of the PRD document includes: document identification, product overview, iteration 1~N, and the product overview includes: functional architecture, demand staging table, demand change comparison, research and development schedule, flow chart, role permissions, and term explanation ; For outsourcing projects or bidding projects, it is also necessary to add product introduction and audience analysis in the product overview section. Please add them by yourself, and will not be described separately here.
Two, document identification
This page is to fill in the name of the project and the basic information of the product manager:
1. Name, with the name of the project document at the top;
2. Logo, the lower right corner is the basic information filled in by the project leader (product manager).
(PS: This is equivalent to a cover, nothing special.)
Three, functional architecture
This page puts the functional structure diagram or page structure diagram of the project, which requires the product manager to sort out the function/page structure of the project with software such as mind mapping or VISIO and export the picture when doing demand analysis, and then copy the picture to the PRD .
When the later version iterations continue to increase, the original functional architecture diagram will definitely change, so:
1. When organizing the functional architecture diagram, you can only organize the large sections, and you don't need to modify the page for changes in small functional points;
2. If the functional architecture diagram is very detailed, the source file must be saved, just modify the source file and export the picture, and then insert it;
3. It is best to mark 123456... according to priority or iteration cycle, so that project team members can quickly understand the demand for a certain iteration, because the iteration cycle is very important.
4. Demand staging table
This page contains the demand plan of the entire project. After the product manager finishes the demand analysis, he needs to sort out all the function points and pages, and do a good job of staging.
1. The basic principle of staging is based on one to two weeks of work as one period, that is, one iteration is one period;
2. The main pages or function points included in the current period need to be listed;
3. Fill in the creation date and modification date of the requirement to facilitate the product manager to control the current development process;
4. The review time, status, and reviewer are convenient to record the current review results. If there is a review, the review time shall prevail.
5. Comparison of demand changes
This page fills in the records of changes and modifications to the requirements on the same page, which belong to the records of minor changes and minor modifications, and the time of the requirement change is marked with red letters; as for major changes and major modifications, they are arranged in an iterative manner and arranged in the subsequent requirements phases. .
Six, research and development schedule
Fill in the R&D timetable for each iteration on this page, including the planned and actual time of each stage of UI design, program development, testing, acceptance, release and launch. Green means early and on-time completion, and red means postponed completion for the project leader Control the progress of project development. Of course, this is a relatively convenient project management method for small teams. The most suitable method is to use software to manage project progress, such as Zen Tao, TAPD, Teambition, etc.
Seven, flow chart, role permissions, term explanation
The flow chart page puts some flow charts of the project, which can be drawn directly on AXURE, or exported pictures can be drawn in VISIO and other software, and then inserted in, but the source files must be saved for use in modification.
The role permissions page shows some role use cases and role permissions diagrams of the project, which can be drawn directly on AXURE, or exported pictures in VISIO and other software, and then inserted, but the source files must be saved for use in modification .
The term explanation page is used to write industry-specific terms, poorly understood or self-innovated vocabulary, and explain these terms to facilitate newcomers’ understanding of the project and speed up integration into the project team.
(PS: These 3 points can be added or modified by the product manager according to the actual project situation)
8. Iteration 1~N period
After the basic description of the project is listed above, the prototype page is next. This is the most critical and different part of the agile version of PRD. The prototype page is divided into different folders according to the number of periods, and the number of periods folders are sorted in descending order (that is, 54321, ascending 12345 is also acceptable):
1. If there are minor changes to the page, make the changes on the original page of the original issue;
2. If there are new or major changes to the page, iterate to the new issue, that is, create a new page in the new issue, and express the changed things on that page;
3. The staging can include the current flow chart and use case diagram;
4. The general prompt window or interaction can be separately summarized into a folder;
5. The page does not need to add page numbers.
The prototype page of this template actually contains two parts: prototype and requirements document. The left side is the prototype design of the page, and the right side is the requirement document of the page. It is mainly to add an annotation code to the prototype design on the left, and to write the requirement document with one annotation code as a line on the right, and the two are indexed by the annotation code, as shown in the figure below: The
detailed description of the above figure is as follows:
1. The serial number, which is the marking code marked on the prototype design on the left, is represented by the English letter AZ (the number 123... is also acceptable);
2. Name refers to the name of a single function point or element
3. Types, including creation, modification, addition, and deletion. The description of each type is as follows:
①Start-up, black font, it means that the function point is created for the first time;
②Modification, blue font, means that the requirement of the function point on the current page has changed;
③Newly added, green font, means that the function point is a newly added demand in person;
④Delete, red font, means that the function point has been abolished;
4. Requirement description, write the requirement description corresponding to the function point, as detailed and clear as possible, it is best to write in several large points and several small points, 123 means bigger points, ①②③ means smaller points; if a requirement change occurs in a certain function point When the time, add an explanation after a small point of the corresponding function point, use red font, and stamp the date, as shown in the figure below (also need to be reflected in the demand change comparison table)
5. Remarks, fill in some special instructions for the function point, or additional instructions.
Conclusion
The above is a general description of the agile version of the PRD document. As for more detailed content, or students who need to apply the PRD document, please move to the following and press and hold to scan the code directly.
