Avoiding Missing Important Requirements

Guidelines

We need to find out why these urgent and important requirements cannot be predicted earlier. Also, we need to know:

What are the external causes? Check whether these causes have something in common and take corresponding solutions.
Is there anything in common of the added requirements? If yes, handle them accordingly.
How temporary is the addition? If we can adjust and respond more quickly so that the temporary requirements do not affect the team, this problem is no longer a problem.
Why do not we adjust the process or work style? Is it unuseful, or do not we know how to adjust the process or work style?

Procedure

We can take measures based on different time points, that is, before, during, and after the event.

In-event handling
Take the following measures as required:
- For important, non-urgent requirements, add them as usual. If they are frequently missed, consider whether the practice of requirement analysis and planning is correct. If yes, strengthen structured requirement management and make a global plan.
- For important, urgent requirements, adjust the current development sequence and prioritize these requirements. Then, conduct a review on two aspects: requirement priority and structured requirement management, and make improvements to avoid similar situations.
- For unimportant requirements, handle them as usual. Determine whether to prioritize them based on their urgency and impact. If this situation occurs repeatedly, it is advised to perform an analysis on structured requirement management and discuss improvement solutions.
Post-event handling
Post-event handling is actually a review. The key to the review is to perform deduction and analysis based on the formulated model and specifications. We need to find out whether there is a problem with the implementation, the model is too simple to cover the special requirements, or the judgment deviation is huge due to inadequate skills. Only when the correct root cause is found can the problem be solved. Therefore, we need to conduct a careful review.

So how do we conduct a review? There are books in the industry for our reference. For example, the MOI model proposed by Gerald Weinberg in Becoming a Technical Leader is a good review approach.
- M: Motivation. Are people not motivated to do it?
- O: Organization. Is it so disorganized or undisciplined that people do not know what they should do?
- I: Idea/Innovation. Is there a lack of ideas or ideas on how to solve these problems?
Due to limited capabilities, experience, and number of problems, we may not be able to reach an accurate conclusion or find an effective solution. However, on the one hand, we can take measures that have been clearly defined and observe the effect for continuous improvement. On the other hand, we can take some temporary measures.
1. Reserve time: If it is difficult to analyze why requirements are always missed and cannot be handled in a targeted manner, we might as well adopt a vague approach. For example, we can obtain the work records of a past period of time, evaluate the workload consumed by the unexpected requirements of each sprint in this period, and calculate the average value. Reserve a certain amount of time based on the value for unexpected requirements during subsequent sprint arrangement.
2. Break down requirements: When we need to adjust the work sequence due to unexpected requirements, it is very likely that the impacts cannot be avoided due to the large granularity of requirements. Therefore, we should break down the requirements as much as possible, making it more flexible to adjust the requirement work sequence.
To calculate the reservation time, use the "Epic-Feature-Story" structure of CodeArts to aggregate unexpected requirements. For example, create a special epic named "Unexpected Requirements" and features to carry the unexpected requirements (shown as stories) in each sprint. Record the workload. After the sprint, calculate the number of unexpected requirements and the workload.

Figure 1 Sprint planning

The Module field can also be used to record and collect statistics on unexpected requirements. For example, create a module named "Unexpected Requirements" to mark all unexpected requirements, and filter or view reports based on the module to calculate the workload of unexpected requirements.

Figure 2 Sprint content
Pre-event handling
After the in-event handling and post-event review, we need to think of preventive measures. We need to perform structured requirement management and requirement priority management, publicize related regulations, allocate personnel, and develop capabilities. In this way, the impact of unexpected requirements can be effectively avoided or reduced.