Atomic Agility

Search

SearchSearch

Sand, Brick, and Diamond

Aug 21, 20249 min read

Context

In a requirements clarification process, it’s common to hear two types of voices echoing in the meeting room. One voice asks, “Did you review the document I sent in advance? Is there anything you don’t understand? I really don’t want to spend more time and energy on this cursed document—I’m swamped with work.” The other voice says, “Can the requirements be more reliable? Isn’t it the details that make up the requirements? I really wish there were fewer half-baked ideas.”

In such a meeting environment, it’s easy to get bogged down in details. Addressing one issue often leads to uncovering new ones, and discussing those new issues brings up even more. The focus remains on newly emerging problems, with little sense of overall progress.

This situation calls for a concept of requirement clarity: what does it mean to have something “fully discussed”?

Similar Concepts

We can draw analogies from the way requirements are defined during the implementation phase:

Kanban

  • Idea Pool (proposed) → Selected → Analyzed → Designed → Developed → Tested → Released.

Scrum Suggestions

  • To Do → In Progress → Done.

These methods use a grayscale approach to manage the transition from requirements (0) to implementation (1) from the perspective of requirement realization or the value-added process during development. This allows for more granular state management. For instance, in the To Do stage, we can see the work queue, and in the Doing stage, we can see the Work in Progress (WIP) information, enabling the team to achieve finer control.

Key Characteristics

Concept

This is a classification of the clarity of communication content:

Diamond

  • Complete Details:
    • For the current requirement, no details are missing. The requirement can guide development and testing at the most specific level.
  • Clear Boundaries:
    • What are boundaries? Requirement boundaries refer to the clearly distinguishable content covered by the requirement and what is not. Clear boundaries also mean that there is no scope creep within the requirement. Additionally, clear boundaries help distinguish between defects and new features.
    • What is ambiguity? The opposite of clarity is ambiguity. When a requirement reaches the diamond stage, no description should be vague. If the development team acknowledges that this is a diamond requirement, they can rely on a clear document or their understanding of the requirement. In any case, the requirement’s content must be clear.

A diamond requirement is like the low beams of a car at night, illuminating all covered details. The areas not illuminated, we call…

Sand

  • Potential Unknown Risks:
    • The requirement has not been communicated, split, or estimated.

This type of requirement is the dark area that the light hasn’t reached. The dark area could be a flat road or could harbor an unexpected obstacle.

Brick

  • Similar Granularity (split into manageable parts):
    • An unsplit requirement is unmanageable and unimplementable. Proper splitting into suitable granularity is crucial.
  • Estimated:
    • Without allowing developers to estimate, the depth of the water remains unknown. Estimation is both a method for gauging the approximate workload and a technique for managing risk.
  • Controllable Risk (feasible):
    • While splitting and estimation are used to control risk, other dimensions could also impact the requirement.

The desired requirement communication and implementation process is as follows: progressive requirement clarification.

At the start of a project, all requirements should be in the sand state, much like driving to explore an unknown continent. The brick state of requirements is like high beams, helping us ensure that the risks at the farthest known points are minimal. Closer in, we need to ensure even smaller risks, because the faster the car, the less abruptly we can steer.

Roles

In a requirements calibration meeting, two key roles are responsible for driving changes in the state of requirements and confirming their final state, while other roles support and validate the final diamond state:

Business Personnel

Or requirements analysts, product managers.

  • Primary Responsibility: Drive the change in the state of requirements.
  • Specific Tasks:
    • Explain and convey the business background and objectives of the requirements.
    • Push requirements from the sand state to the brick or diamond state.
    • Record the information or content needed for the requirement to move to the next state and ensure that these needs are followed up.

Development Personnel

Leads or key developers.

  • Primary Responsibility: Confirm the state of the requirements.
  • Specific Tasks:
    • Evaluate the technical details and feasibility of the requirements.
    • Determine whether the requirements meet the standards and can move from one state to the next.
    • Confirm the final state of the requirements, ensuring they meet clear and implementable standards.

Process

Requirements Calibration Meeting

In the requirements calibration meeting, the main goal of the team is to calibrate the state of the requirements, though the transition of states may occur at any time, either during the meeting or outside of it. The following are the key steps in the process:

flowchart TD
start1([Start]) 
short([Short-term])
long([Long-term])
out([Out-of-Scope])
start1 --> bz[Business Personnel]
bz -- Push --> t{"Technical Personnel
Confirm Status"} 
t -- Potential<br>Risks --> Sand 
t -- Risks Controllable<br>Similar Granularity --> Brick
t -- Details Complete<br>Boundaries Clear --> Diamond
t -. Blocked .-> r[Record as<br>To-Do]
Sand -. Long-term .-> bz
Sand --> out
Brick --> long
Brick -. Short-term .-> bz
Diamond --> short
  1. State Review and Initial Calibration:
    • At the start of the meeting, business personnel and development personnel jointly review the current state of all requirements, placing requirement cards in the area representing their current state (sand, brick, diamond).
    • The team confirms the current state of the requirements and discusses whether there is any content that needs further refinement or adjustment.
  2. Dynamic Adjustment of Requirement States:
    • During the meeting, the team may immediately adjust the state of certain requirements based on the discussion results. For example, if a requirement is deemed to meet the diamond standard after detailed discussion, its card can be moved from the brick state to the diamond state.
    • Similarly, if it is found during the discussion that the details of a requirement are still unclear, its state may need to be reverted from diamond or brick back to sand for further clarification and processing.
  3. Marking To-Dos and Follow-Up Actions:
    • For requirements that have not yet reached the expected state, the team marks to-dos that need further work and follows up on them after the meeting. This may include updating the requirements documentation, conducting further technical evaluations, or engaging in additional communication with stakeholders.
    • These to-dos may be completed outside the meeting, but the team will revisit the status of these requirements in the next meeting.
  4. Meeting Summary and Next Steps:
    • At the end of the meeting, the team confirms the current state of all requirements and plans the next steps. Specific individuals will be assigned responsibility to ensure substantial progress before the next meeting.
    • If any requirements change state outside the meeting, the team will recalibrate them in the next meeting to ensure a consistent understanding of the requirement status.

Through this flexible and dynamic requirements calibration process, the team can more efficiently manage the state of requirements in complex projects, ensuring clarity and consistency whether state transitions occur during or outside of meetings.

Relationship with Story Mapping

The concept of sand, brick, and diamond requirement states is closely related to and complements story mapping, enhancing the effectiveness of requirements management:

  • Requirement States and Story Mapping:
    • At the conclusion of story mapping, all requirements should reach the brick state, indicating that they have been preliminarily split and possess sufficient clarity.
    • Before entering development, some key requirements need further refinement to reach the diamond state, ensuring smooth development.
  • Structure and Decision-Making in Story Mapping:
    • Story mapping presents the overall structure of requirements in a two-dimensional manner, helping the team understand the big picture of the project and make priority decisions.
    • By mapping requirement states (sand, brick, diamond) onto the story map, the team can clearly see the progress and maturity of requirements.
  • Management of Sand Requirements:
    • Even if a requirement is in the sand state, it can still be included in the story map through the addition of assumptions or statements. This allows the team to discuss and plan requirements even when they are not fully defined.
    • As the project progresses, these sand requirements can gradually be refined and transitioned into brick or diamond states.
  • Complementarity:
    • Story mapping provides a global view of project requirements, while the sand, brick, and diamond concepts help the team manage and refine the state of each requirement. Together, they enable the team to grasp the overall progress of the project while ensuring that each requirement is appropriately handled and prepared.

Relationship with the DEEP Principle

The concept of sand, brick, and diamond requirement states offers an effective implementation for the “Detailed Appropriately” aspect of the DEEP principle:

  • Detailed Appropriately: Previously, this principle lacked a clear method of implementation. Now, the state management of sand, brick, and diamond provides clear detail standards for different stages of requirements: sand state requirements are relatively vague, brick state requirements have controlled risks, and diamond state requirements are fully and meticulously defined.
  • Estimated: Brick state requirements must be estimated to ensure they have a clear workload forecast before development.
  • Emergent: Requirements often become clearer during the project process, which has become the norm, except in fixed-price contracts.
  • Prioritized: Agile methodologies inherently emphasize prioritizing the most important requirements, which naturally aligns with the management of brick and diamond state requirements, requiring no further explanation.

This combination ensures that the DEEP principle can be effectively implemented in practice, making requirements management more systematic and efficient.

Considerations for Atomic Agility

The key challenge in requirements communication lies in the binary state of being clear or unclear. If all versions of the requirements are clear, it actually mirrors the traditional waterfall approach to requirement realization. Most Agile software development processes balance the proportion of sand, brick, and diamond requirements in the overall set of current requirements. We use the Clearer Gray Areas principle to clarify “Detailed Appropriately.” The addition of the risk-controllable brick state helps create a high-beam light for the delivery plan.

The Agile requirements communication process aims to balance the business and development sides, but many teams have turned into one-sided requirements briefing meetings. We hope for a two-way communication process, where the business side drives and the development side confirms, allowing both sides to gain a Broader Perspective. Of course, this way of clarifying requirement states also enforces Stronger Discipline.

Graph View

Backlinks