We have already talked about the topics of annual product planning and demand value evaluation, and this article will continue to refine the requirements scheduling at the level of daily iteration execution.
Requirement scheduling is based on the prioritized demand pool, under certain resource constraints, weighing a variety of factors, comparing and selecting requirements, selecting the most prioritized set of requirements and allocating R&D resources. A requirement scheduling may be a product release or just a R&D iteration cycle without a release.
1. What is the meaning?
In essence, demand scheduling is more like an investment decision-making behavior, and the core is to pursue the best ROI at the moment. For commercial B-end products, it is for revenue growth, and for self-developed or customized software, it is for leadership & user satisfaction. (In the following, market revenue will be equated with leadership & user satisfaction, and replaced by market revenue to avoid redundancy)
Regular prioritization of demand development with the pace of development iteration is a revision of the annual plan, a response to market changes, and a resource allocation optimization decision made to improve short-term market revenue, product competitiveness, bargaining power, customer response perception satisfaction, etc.
2. Weigh the elements
In addition to the prioritized list of backlog requirements, there are a number of trade-offs, such as:
- ROI is the most important element in the balance of options, that is, with the same R&D investment, priority is given to demand that is expected to generate higher revenue.
- Influence, i.e., the needs raised by high-influence people, is also known as the need for leadership. The leader here may be at the top of the company, or it may be at the top of a key account.
- Development capacity, that is, the total amount of R&D manpower and time that can be invested in the iteration cycle, affects the granularity and quantity of requirements that can be arranged.
- Urgency, such as the demand at the key node of project transaction and acceptance, the demand that is fed back when there is a quality problem, the demand that the delivery time of the demand commitment is approaching, and the demand that has been put forward for a long time and urged many times, etc.
- Dependency, that is, there is a sequential dependency between requirements, to avoid the delivery of semi-finished products or repeated rework, etc.
- Iteration balance, that is, the number of large and small requirements in the iteration, the number of different types of requirements, etc.
- Requirements clarity, which usually prioritizes requirements that have been clarified in the requirements analysis.
3. Frequently Asked Questions
1. Misalignment of decision-makers
B-end products are afraid of excessive pursuit of user experience and technology, and should pursue revenue maximization. It's easy for functional product managers to get bogged down in UI/UE details, while technical leads tend to get bogged down in the pursuit of new technologies, better architectures, and less technical debt. In the end, business value may be neglected, cost control awareness may be lacking, and the product may look good but not very useful.
The iterative demand scheduling decision should be led by the person who bears the most pressure on the market revenue assessment, or let the person who leads the decision take on more market revenue assessment pressure to avoid the disconnection between the product and the market.
2. The value is difficult to quantify
ROI is an important factor to measure which needs to be achieved first. However, how to define the value of requirements and how to evaluate development costs is a difficult point. Relying on one person or a group of people to pat their heads is too subjective and lacks explainability, consistency, and measurability. The pursuit of relative quantification at the lowest possible cost can help improve the quality of decision-making.
For example, each decision maker is given 100 value points when selecting requirements for each scheduling, and each decision maker assigns value points to the needs to be scheduled, and finally finds the average value of the demand value points as a reference for scheduling.
The pursuit of an absolutely accurate quantification of the value of demand consumes time and energy, and is not necessary, and there is a certain degree of subjectivity in the determination of the value itself.
3. False cost statement
The oppression of the business side to do more and the resistance of the R&D team to not overwork it are widespread, which leads to the possibility of inflated workload when the R&D team assesses the workload. To alleviate this problem, you can use the Development Capacity and Time Point Valuation methods.
For example, if a development team of 5 people has an iteration cycle of 2 weeks, we can define the iterative development capacity of the development team as 400 man-hours. When evaluating the cost of requirements, the development team and multiple roles participate together, each gives an estimate of the working hours, and finally averages the working hours as a cost reference.
4. Pursue methodology
There are many methodologies on demand scheduling and development priority, and the essence is "trade-off dimension + comparison and ordering". There is no need to worry about which methodology to use, as long as the person referring to the decision maker agrees on the key trade-offs and their weights, and compares the ownership trade-offs to the relatively quantitative value points.
5. Unbalanced iteration
If only a few large requirements are placed in the iteration, a large number of small requirements will be backlogged, and the overall demand delivery cycle will increase, which is easy to give customers a perception of slow response and low efficiency. In order to balance the external perception, it is necessary to balance the internal requirements within the iteration and appropriately add some small demand responses.
Requirements can be divided into optimization, new features, bugs, and technologies (non-functional, technical debt, and architecture transformation), and the types of requirements need to be balanced during iteration. If there is a lack of constraints, the R&D team may make a lot of technical requirements, and the market and customers perceive that the product will not change or increase in value after multiple iterations. For example, the workload of technical requirements for each iteration should not exceed 20%, each iteration needs to have new feature requirements, and each major version release needs to have selling point publicity requirements.
6. Change of requirements
Requirement changes within an iteration may cause insufficient time and quality degradation, which may affect the achievement of iteration goals, and a change management mechanism is required to ensure the development rhythm. For example, requirements that have changed are not included in the sprint goal; If there is a change in the requirements, it will be directly postponed to the next iteration, and this iteration will be supplemented with clear small requirements based on the remaining work capacity.
7. Emergency queue cutting
Requirements may arise within an iteration that require an urgent response and release, and are handled in a similar way to requirements changes. For example, kick unstarted or poorly completed requirements out of the iteration. Generally speaking, urgent requirements have a large impact on the development rhythm and need to be tightly controlled, and in some large companies even have a dedicated emergency requirements management process.
8. Technical uncertainty
Some requirements are important and the business scenarios are basically clear, but there is great uncertainty in the technical implementation. If it is not discharged, it may drag on for a long time. Therefore, it is recommended to schedule iterations, but not to make delivery requirements. Even if the requirement doesn't make much progress throughout the iteration, it's worth the time to keep tackling it. High-value demand cannot be postponed indefinitely because it is difficult.
In this topic, the author wants to talk about the idea of relative quantification of value, and the others are more supplements to the previous content and the completeness of the topic in this article.
This article is written by Everyone is a Product Manager Author【Product Xiaoshuo】, WeChat public account: [Product Xiaoshuo], original/authorized Published in Everyone is a product manager, without permission, it is forbidden to reprint.
Image from Unsplash, based on the CC0 license.
![Wang Wenli regretted losing the "first share of tea" in 31 years of entrepreneurship, and the excessive packaging of products in the Eight Horse Tea Industry was notified[fig]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)