Ping-Pong Splitting

Context

I had a mentor in software development who once shared an interesting story with me during a casual drink. His team was taking on a large-scale project that was in full swing. He gave them only one requirement: to break down all tasks into units of work that could be completed within three days and to manage and follow up on them. My mentor had no formal knowledge of Agile methodologies or practical experience, but he had a very clear understanding of basic software management principles. The core of this understanding was the importance of breaking things down, a necessity in the software industry.

“If you can’t break it down, you actually don’t know how to do it.”

This is why breaking down tasks is crucial: it is an essential tool for managing knowledge work. Knowledge work often involves scenarios where progress cannot be easily measured. Unlike manual labor or assembly lines, where you can immediately see how much work has been done, progress in knowledge work is not as straightforward. Without breaking things down, progress management, risk management, and dependency management are all impossible.

The Agile process of requirement management is an art that balances the needs of the business with the realities of development. However, in many practices, this balance is not always evident. Ping-Pong Splitting strengthens this balance between both sides.

In the teams I’ve guided, initially, they kept asking about techniques, methods, and approaches. But when it came to actually breaking down the requirements, I found I hardly needed to provide any techniques, methods, or approaches. The teams were able to do it well using the knowledge they already had.

Similar Concepts

“Ping-Pong Splitting” differs from traditional requirement breakdown methods by emphasizing the constant exchange of perspectives between different roles during the process. Similar to a debate, business and technical personnel within the team take turns refining and splitting the requirements, ultimately creating requirements that can enter the “brick” state.

This method is reminiscent of concepts like Ping-Pong Pair Programming, where two developers frequently alternate roles to write implementation code and test code, enhancing code quality and development efficiency. Similarly, Ping-Pong Splitting ensures that key angles (like verifiability and granularity) are considered through alternating perspectives.

Key Characteristics

Balancing verifiability with granularity is akin to two paddles, with the requirement to be split acting as the ping-pong ball.

Concepts

Verifiability

Agile capability, from a product perspective, is the ability to obtain market feedback as early as possible. This is challenging for IT professionals accustomed to designing systems in large, complete chunks, as design is an ongoing process throughout development. When a new requirement comes in, it necessitates a design effort. Clearly, doing ten features all at once is easier than doing them one by one. However, just because it’s more laborious to do them one at a time doesn’t mean you shouldn’t choose this method. Iterative development, making one feature at a time, is the right path from a product perspective. Therefore, it’s essential to be wary of the potential impact of developers’ inertia on the splitting process.

In guiding teams, it often involves a bit of coercing technical personnel to split requirements from a business perspective. One of the benefits of involving business personnel is that they can make decisions about prioritizing certain aspects. If splitting is done purely from a technical perspective, the development process must follow that path, often leading to a situation where business personnel feel held hostage by the technical team (because they can only deliver in a certain way). This lack of involvement is one reason why the relationship between business and technical teams can sometimes be strained.

Agile requirement splitting aims for each requirement to represent an incremental change, akin to a potter shaping clay on a wheel. Each hand movement gradually changes the shape of the clay as the wheel spins. Similarly, each software requirement represents an adjustment and change to the system, building incrementally on the previous one.

This incremental process should be perceivable by end-users, meaning each completed requirement should result in a noticeable change in the system, much like the pot taking shape. This leads to the Agile requirement definition:

Agile requirements should be small in granularity and result in user-perceivable functionality enhancement.

User-perceivable functionality enhancement means that each completed requirement should lead to a noticeable change from the user’s perspective.

This brings us to the next concept:

Granularity Standardization

Granularity refers to the complexity of the requirement, simply put, the amount of work for developers. The concept of “granularity standardization” can be traced back to the “Heijunka” principle in Lean production, which emphasizes standardizing and balancing tasks or requirements to a certain level of granularity. They shouldn’t be too large or too small; the size should be relatively consistent. I prefer not to use the term “Size Appropriated” because “appropriate” has already been replaced by the concepts of sand, brick, and diamond. Here, it refers to ensuring that the brick-sized requirements don’t differ in workload by orders of magnitude (e.g., a tenfold difference).

The Possibility of Extreme Splitting

Let’s consider an example: How many steps does it take to put an elephant into a refrigerator? People often joke that it takes three steps:

1. Open the door; 2. Push the elephant in; 3. Close the door.

Now, if you were asked to break down the first step, “Open the door,” how would you do it?

1. Walk to the refrigerator; 2. Grip the door handle; 3. Pull.

If you break down the first step even further, what would it look like?

1. Lift your eyes; 2. Locate the refrigerator; 3. Take the first step.

And if you break it down further still, what do you get?

1. Think about the task; 2. Slowly lift your head; 3. Look toward the imagined location of the refrigerator.

This illustrates that, from a logical standpoint, we can infinitely break things down. So, when someone says a requirement cannot be broken down, it’s not a question of whether it can be broken down. Everything can be broken down in this manner, right down to molecules, atoms, particles, and quarks. Just like in software development, I can break it down to each line of code you need to write. However, a new question arises…

Is Finer Granularity Necessary?

Once breaking down has reached a certain level of granularity, it may start to feel unnecessary. This feeling is actually an explicit expression of our conventional understanding and our sense of risk control. Does opening the refrigerator door need to be broken down? Anyone knows how to do that. Are there any risks associated with opening the door? I’ve done it countless times.

The risk comes from two factors: on one hand, assuming that what we know is what we know (contextual domain knowledge, or assumed understanding), and on the other hand, underestimating the potential risks (underestimating risk). That’s why my mentor insisted on breaking down tasks into three-day units. This level of granularity is very important for software projects, but if you go even finer, such as breaking down by the hour, it becomes too fragmented for tracking and recording.

Too small a granularity increases management costs, as every tiny task requires attention and management. Excessive granularity leads to higher management costs. But if the granularity is too large or coarse, it increases opportunity costs because the feedback loop becomes too slow, potentially leading to greater losses. We need to strike a balance between opportunity cost and management cost to achieve appropriate granularity.

For overly fragmented requirements, you can bundle them into a single requirement. Thus, breaking things down into smaller, finer parts is actually a higher demand in requirement management.

Estimation as a Method of Granularity Standardization

No matter what unit is used for estimation, even a time range, it’s an attempt to standardize the granularity of requirements. If you insist on a range for completion, a three-day, up to five-day work breakdown (including testing) is a good target.

Roles

The responsibilities (ping-pong paddles) are clear, with two roles ensuring verifiability and granularity standardization.

Business Personnel

Or Requirement Analysts, Product Managers

• Primary Responsibility: Ensure the business value and verifiability of the requirements, confirming that the split requirements can be validated and delivered.
• Specific Tasks:
  • Initially split the requirements.
  • Verify the verifiability of the split requirements.

Development Personnel

Leads or Key Developers

• Primary Responsibility: Ensure the technical feasibility and reasonable granularity of the split requirements, maintaining manageable risks from an implementation perspective.
• Specific Tasks:
  • Attempt to split the requirements from a technical perspective while meeting verifiability requirements.
  • Verify the granularity standardization of the split requirements.

Process

The splitting process can take place during requirement calibration meetings or during regular requirement discussions. The key is to involve two roles in the splitting process: one representing the business side to confirm verifiability, and one representing the technical side to confirm granularity standardization. Once the team becomes proficient, they can swap roles.

flowchart TD
start1([Start]) 
end1([End])
start1 --> b{Business Perspective}
b -- Split --> cr(Calibrated Requirements)
b -. Cannot Split .-> t{Technical Perspective}
t -- Split --> cr
cr -- Verifiability Confirmation --> b
cr -- Granularity Level Confirmation --> t
t -- Granularity Leveled --> ma(Mutual Agreement)
t -. Merge .-> cr
b -- Verifiable --> ma
b -. Blocked .-> todo(Record as To-Do)
t -. Blocked .-> todo
ma --> end1

1. Trigger: Identify and Prepare Requirements
   • First, the team needs to identify which requirements need to be split. This step is led by the business personnel, as it is their responsibility to move the requirements from the sand state to the brick state.
2. Business Perspective Requirement Splitting and Verifiability Confirmation
   • The business personnel split the requirements into smaller parts. The goal of this splitting is to ensure that each small requirement can be verified through specific methods, such as user testing or business rules.
3. Technical Perspective Requirement Splitting and Granularity Standardization
   • The technical personnel evaluate the requirements split by the business personnel to ensure that they are technically feasible and that the workload is appropriate. If issues are found, they further refine the requirements to ensure that they are neither too large nor too small.
4. Repeat the Ping-Pong Process (Steps 2 and 3), Continuously Marking Follow-Up Work
   • For requirements that need further modification or discussion, the team marks them and follows up afterward. These requirements may need additional documentation, technical evaluation, or communication with relevant personnel.
   • Confirm the clarity of the requirements’ status, whether they are in the sand or brick state.
5. End: Both Parties Confirm the Verifiability and Granularity Standardization of the Requirements

Related Concepts

Business Splitting Tips

For business personnel who have no ideas on how to proceed, the following splitting methods can be used as references:

Based on the recommendations from AgileLearningLabs (see Reference 1 below). We approach it from four directions:

Connectors

There may be connectors in the requirements, such as: and…, moreover…, when…, if…, but…, as long as…, or even a comma. These connectors are signals for potential splits; you can try splitting directly at these points.

Generic Terms

There are many generic terms in the requirements, such as nouns: vehicle…, personnel…, receipt…, record…, information… These generic terms can be replaced with more precise terms, and multiple specific terms can replace them. For example, …’s vehicle, receipt recording… information. Likewise, verbs: maintain…, update…, feedback…, trigger…, delete…, etc… The process of replacing generic terms with more precise ones is essentially the process of splitting.

Acceptance Criteria

Acceptance Criteria, also known as Conditions of Satisfaction, refer to the standards for a completed feature. These acceptance criteria can also be split into incremental requirements. It doesn’t necessarily mean one acceptance criterion turns into one requirement; a group of acceptance criteria can form a new requirement.

Timeline Analysis

Suppose this feature is implemented; how would you verify this requirement? What events will be triggered? For example, logging in, inputting certain information, clicking the search button, and performing several operations based on the search results. These points in time can serve as ideas for splitting. Just a friendly reminder, if the splits are too small, they can be bundled together.

Technical Splitting Tips

When it comes to splitting methods, some have been summarized by predecessors (see Reference 2 below). Sometimes the seemingly advanced content can be difficult to apply to specific tasks. After guiding countless teams, I’ve concluded that there are basically four methods that can split requirements down to the ideal granularity. These four methods are not used in isolation; when faced with a requirement, you can mix and match these methods, using one as the main method and others as supplementary.

Process and Interface

Most software applications have processes and interfaces, which are naturally perceptible to users. Therefore, splitting by process and interface is a default technique you should remember for any requirement. There are three different detailed approaches to splitting within processes and interfaces:

1. Step-by-Step Progression
   • From the perspective of processes and interfaces, break it down into screens or process nodes. Following the time sequence of the process, split all processes and screens one screen at a time. Once a screen and its related interactive functionality are completed, move on to the next screen. Build piece by piece. (For requirements with relatively clear design and structure)
   • Example: Login screen, output screen, search screen, maintenance screen…
2. Rapid Verification
   • The software has a main process, which is the core content of the software. Split it into requirements that can connect various process nodes and achieve the main process flow-through, then gradually add side processes to the main process. First, build a thin layer, then gradually thicken it. (For requirements that require trial and error or exploration)
   • Example: Key main process, side process of the first node of the main process, side process of the second node of the main process…
3. Start and End Process
   • There is an initial process and an end process in the workflow; first, complete the initial and end processes. Once users can perceive the start and end, gradually add content to the middle of the process. First, do the head and tail, then gradually enrich the middle. (For requirements that cannot be split using rapid verification)
   • Example: Key input + key output screen, enriched key input screen, screen after the second process node following the key input screen…

Algorithm and Display

For features that don’t have obvious processes or interfaces, they can be likened to a black box with some input and some output. Generally, this black box can only control two things:

1. Control Input
   • Control the number of input variables and the range of values.
   • Example:
     • A report has three input variables, defaulting to two data items, with only one variable adjustable before clicking the search button.
     • For insurance premium calculation, there are countless types of cars; start by calculating with a Toyota Corolla within one year.
2. Control Output
   • Control the content and presentation of the output.
   • Example:
     • First query certain fields in a report, then query other fields (this splitting method may not be applicable due to performance considerations).
     • First display key information, then display irrelevant information.

Dependency and Layering

If you’re dealing with software that has layers and complex logic, you can try the following ideas:

1. Layer-by-Layer Progression

   • Users may need to go through several layers of logic before returning a result. In this case, you can first have the top layer respond to the user request directly, then add the layers touched by the requirement.
   • Example: Several layers of TCP protocol in a switch can be split into the first layer protocol, then first and second layers, then first, second, and third layers.

2. Isolate Dependencies

   • For complex logic sections, you can isolate the parts with complex logic or dependencies, then have a requirement open this isolation.
   • Example: Dependent on a third-party algorithm, the algorithm interface is defined but not yet active. Split it into using a mock interface, then integrate the real interface.

Exploration and Research

Not all requirements are familiar to the technical personnel in terms of splitting and implementation due to uncertainty about the technical structure or implementation ideas. These often require exploratory (technical research) tasks to be carried out first. These tasks have two key points:

1. Timebox the Task, meaning this task must have a time limit. Whether it’s a day, two days, or even four days.
   • Example: One person’s two-day technical exploration.
2. Clearly Define the Specific Problem this technical exploration task aims to solve, with a very clear problem domain and completion criteria.
   • Example: Clearly identify the number of database table calls and the location of write operations in legacy code.

Feature or Epic?

Any Agile requirement should be relatively granular. High-level requirements are merely for better managing these granular requirements’ categorization and labeling. Of course, they may initially come from a large-granularity requirement, but once split, whether it’s a Feature or an Epic, they merely serve as labels to help us quickly locate these granular requirements.

Thus, the summary of the workload should start from the smallest granular requirements and gradually sum up to the requirement labels. Early standalone estimation for features and epics should not exist.

All decision-making recommendations should be based on discussing the smallest granular requirement as a whole, rather than working backward. The reason is that it is precisely at this level of granularity that the balance between technical and business concerns is struck. Smaller than this, people may feel it’s too trivial to discuss. Larger than this, the risks in technology and business may not be exposed.

Consideration of Atomic Agility

The core of the “Ping-Pong Splitting” method lies in the alternating perspectives between roles and the multiple refinements of requirements. This multi-layered balance is a concrete embodiment of Atomic Agility. During the requirement splitting process, the business and technical sides alternately refine the requirements, gradually transforming vague requirements into clear, verifiable tasks.

The success of this method lies in combining Broader Perspective|a broader perspective. By involving both business and technical stakeholders, it ensures that the final split covers all necessary verification points and technical details. This multi-angled scrutiny reduces potential blind spots, ensuring the team fully understands and addresses the requirements. It makes requirement splitting a collaborative effort, rather than the responsibility of one side.

At the same time, Stronger Discipline|stronger discipline plays a key role in this process (responsibilities are clear and can be exchanged). Business and technical personnel continually calibrate the granularity and verifiability of requirements in each perspective swap, ensuring that every split aligns with the project’s overall goals.

References

Reference 1: AgileLearningLabs’ splitting suggestions:

https://www.agilelearninglabs.com/2013/04/introduction-user-stories/

Reference 2: Agileforall’s user story splitting reference:

https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/