Can Programmers “Cut” Requirements Too? #

Hello, I’m Zheng Ye.

In our previous discussions, we mainly talked about the decomposition of development tasks. Today, let’s take a different perspective and look at the decomposition of requirements. Yes, requirements also need to be decomposed.

Once, I was chatting with a colleague who is a developer, and he told me about his recent troubles.

Colleague: We have too many requirements and too few developers. If we continue like this, one day I will just pack up and leave. - Me: Have you tried cutting down on the requirements? - Colleague: How can I not have tried? The product team just doesn’t agree. They say these features are all key functionalities. - Me: Have you tried breaking down the requirements into smaller parts before cutting them? - Colleague: Is that possible?

My colleague was surprised, but I wasn’t at all. We were both talking about requirements, but we had very different understandings of them. Let me first ask a question, what comes to your mind when you hear the word “requirement”?

Taking the commonly used login function as an example, if I ask you what this requirement is, most people’s initial response would be a username and password login.

Basically, the initial requirement description that comes to your mind is an epic. In agile development, some people call it a master user story.

If your management granularity for requirements is just at the epic level, then there are many things that cannot be discussed. For example, when time is tight and I want to cut down on requirements, if you ask the product manager if I can skip the login, you can expect to be rejected.

However, if you say that time is tight, can I postpone implementing the login verification code or the email address verification feature, the product manager can discuss this with you.

The difference here lies in the fact that the latter decomposed the requirements.

Most people can understand that requirements need to be decomposed, but the degree of decomposition is the root cause of the significant differences in execution effectiveness.

In my experience, most problems are caused by the granularity of decomposition being too large, and there are few problems due to granularity being too small. Therefore, a principle of requirement decomposition is that smaller granularity is better.

Break down the requirements #

“Theme” is just for you to remember the general direction. To truly manage requirements, you need to break them down further. In this discussion, we will continue to use the requirement description method introduced in previous columns: user stories. User stories will be the basic unit for requirement management in our discussion.

If your team uses other methods to describe requirements, you can also look for corresponding management methods.

In the previous module, we discussed “starting with the end in mind.” Our focus on user stories is mainly on ensuring the completeness of a requirement by having acceptance criteria. In the “task breakdown” module, we look at user stories as the result of requirement breakdown, which means splitting them into individual requirement points to be addressed.

In the previous discussion, we have already learned what a user story looks like, but the more important question is: there are countless ways to divide requirements, just like a cake that can be sliced horizontally or vertically. If you don’t cut it at all, you use the theme as user stories. Or you can use a sharp knife to cut the theme into pieces.

Everyone may have their preferred way of breaking down requirements. I believe that after understanding the importance of breakdown, you will always find a way. Here, I mainly want to talk about how to evaluate the results of breakdown, as it will be our basic unit for requirement management.

Only when requirements are broken down into fine-grained ones can they be easily managed. What kind of requirements are good for breakdown? Let’s first look at the evaluation criteria for user stories.

User stories are evaluated based on the “INVEST principle,” which is an acronym for six words:

• Independent: A user story should represent a self-contained functionality and minimize dependencies on other user stories. User stories that depend on each other make it more difficult to manage priorities and estimate work effort. In case of dependencies, a good practice is to separate the dependent part and readjust.
• Negotiable: When working together, it is a prerequisite to discuss matters. We cannot ensure that all the details can be fully implemented in user stories, so the best approach is to have discussions. It is also a prerequisite for meeting other evaluation criteria. As mentioned earlier, if a user story is not independent and needs to be broken down, it requires cooperation among team members.
• Valuable: A user story should have its own value, which is the easiest criterion to understand. Don’t do things that have no value. But as we have been emphasizing, before doing anything, ask about its value.
• Estimatable: We will use the estimation results of user stories to plan subsequent work. User stories that cannot be estimated are either due to many uncertain factors or because the requirement is still too large. Such stories are not yet in a state where they can be developed and require further analysis by the product manager.
• Small: It’s not good to take big steps. User stories that cannot be completed within a certain time frame should be split into smaller ones. Small user stories are easier to schedule and manage.
• Testable: We need to test to determine if the work is done correctly. This is something we have emphasized earlier, which is the acceptance criteria. You need to know what constitutes completing the work.

The wording of the “INVEST principle” is for ease of memorization. We will focus on two points here.

The first point is negotiable. As implementers, we need to ask questions. If you passively accept requirements, your value is reduced by half. Once you start asking questions, you will find many areas where the requirement writer has not thought through.

In my career, I have repeatedly rejected requirements, not because I am uncooperative, but because I do not want to work on vague requirements. The reason I can ask questions is partly based on common sense, and partly because of the value of user stories as stories that need to be told and communicated.

There is another important focus, which is also the core of this module: small. Both independence and estimability are based on the premise of being small. Only when user stories are small enough will we have flexibility in subsequent adjustments.

Then comes an important question: What does it mean to be small? This involves another important aspect of user stories: estimation.

Estimating Requirements #

To estimate user stories, the first step is to choose a metric. There are many ways to measure the size of user stories, such as using T-shirt sizes like S, M, L, XL, XXL, or using Fibonacci numbers like 1, 2, 3, 5, 8, etc. Once we have a measurement standard, we can begin estimating.

We select the simplest user story from the decomposed user stories, such as a basic information query. This simplest user story serves as a baseline.

For example, if we use Fibonacci numbers, then this simplest user story would be assigned a size of 1. Other user stories are then compared to it one by one, and if a user story is more complex, we can estimate its size based on complexity.

You might wonder how to determine the level of complexity. This is where task decomposition, which we discussed earlier, comes into play. You need to quickly break down the task in your mind, think about the steps involved, and then compare them.

Therefore, you will find that task decomposition is the foundation of everything. Without learning how to decompose, your work will rely solely on intuition, making it difficult to become a reliable programmer.

The result of estimation is relative, not absolutely accurate. We don’t need to be as precise as in scientific research, we just need to provide a relative estimate.

Different people may have different estimates for the same user story. How can we achieve consensus within the team? This requires the participation of many people in the team, and if the team is not large, everyone can participate.

If multiple people are involved in estimation, you will find an interesting phenomenon: there can be a large difference in the estimates for the same user story.

If the difference is small, such as 3 points in your opinion and 2 points in mine, we can coordinate and reach an agreement. But if there is a large difference, such as 2 points from you and 8 points from me, then there is definitely a huge difference in understanding the task. In such cases, we can take the task decomposition we did in our minds and put it on the table to see where the differences lie.

Usually, the deviations occur due to different understandings of the requirements. At this point, the colleague responsible for writing the user stories should step forward and help clarify the requirements. Therefore, the estimation process is generally a process of deepening the understanding of the requirements.

Estimation also serves another important purpose: identifying very large user stories. In general, a user story should be completed within one iteration.

For example, if you estimate that a user story with a size of 1 point will take 1 day to complete, and your team’s iteration cycle is two weeks, which is 10 working days, then a 13-point task is impossible to complete. So what should we do? It’s simple, divide it into multiple smaller tasks so that each task can be completed within one iteration.

Therefore, user stories are usually split twice. The first split is done by someone responsible for business requirements, such as a product manager, based on the business. The second split occurs during the estimation phase when large user stories are identified and split again.

Once we have a suitable user story list, we can then plan our development process. As long as we clarify the dependencies between user stories, arranging the work is something every team is good at.

Here, I want to go back to the topic we discussed at the beginning. We often say that requirements come from product managers, but what exactly are requirements, is a broad topic. By now, we have a clearer and more manageable requirement, which is the user story. At this point, when we talk about requirement adjustments, we are no longer discussing a broad theme, but rather specific user stories.

Many teams’ real dilemma lies in the lack of a requirement decomposition phase during the development process. In this case, the basic unit for requirement management is a theme, and since it is the basic unit, it cannot be divided. The team is bound to a huge requirement, with no room for maneuver.

If the team can decompose requirements, the basic unit of requirements will become smaller, and each person will not see a rigid “block”, making it more convenient to adjust and allowing for greater flexibility.

Summary #

In software development, requirement management is a very important aspect. One common mistake in requirement management is having too coarse-grained granularity, where many teams are managing requirements using a single large theme, leaving little room for requirement adjustments.

Combining user stories, I explained what a good requirement management basic unit should look like, which should comply with the “INVEST principle”. One key point is that it should be “small”, as only small requirements are easy to manage and adjust.

What qualifies as a small requirement? I introduced a way to estimate requirements, where each team can decide based on their own characteristics how large a requirement should be considered large. What should be done with large requirements? They can simply be decomposed.

If you are interested in the topic of user stories, I recommend reading two books by Mike Cohn, “User Stories Applied” and “Agile Estimating and Planning”.

If you can only remember one thing from today’s content, please remember: To manage requirements effectively, start by breaking them down into smaller pieces.

Finally, I’d like to ask you to share any problems your team has encountered in requirement management. Please feel free to write down your thoughts in the comments section.

Thank you for reading, and if you found this article helpful, please consider sharing it with your friends.