Shalloway's Law of Requirements

If it can be misunderstood, it will be.

"Requirements that can be misunderstood will be misunderstood."


"Everything can be misunderstood."

Al Shalloway

In Agile development, clarity around requirements is essential, yet consistently elusive. Al Shalloway1 observed that if a requirement can be misunderstood, it will be. As a supplement to the law, he notes: everything can be misunderstood. This insight cuts to the heart of Agile communication challenges. While the Agile Manifesto values "working software over comprehensive documentation", it also champions collaboration and shared understanding. Unfortunately, even conversations and well-crafted user stories can be interpreted through different mental models, biases, and experiences. Misunderstanding is not a rare exception, it is the default risk. This leads many Agile practitioners to rethink not just what we capture in requirements, but how we convey them.

Impact on Agile Teams & Organizations

Misunderstood requirements generate costly ripple effects. Agile teams can build exactly what was described, and still miss what was needed. These failures often appear late, usually during acceptance or customer review.

  1. Misinterpretation leads to Rework::
    • Features built on incorrect assumptions must be torn down or reworked.
    • Velocity drops while frustration rises, often harming trust.
  2. Teams suffer from "Phantom Alignment":
    • Stakeholders believe alignment exists, but interpretations differ beneath the surface.
    • This weakens Backlog Refinement and Sprint Planning sessions.
  3. Delivery Confidence Decreases:
    • QA cycles take longer due to ambiguity in expected behavior.
    • Product Owners struggle to verify what "done" means.
  4. Feedback Loops get Distorted::
    • Customers respond to misaligned outputs.
    • Retrospectives focus on execution, not upstream communication.

Scenario

A team receives a user story: "As a customer, I want to receive notifications about shipment delays". After a conversation, the team assumes email is the channel. The Product Owner meant SMS, and the customer expected in-app messages. During demo, the stakeholder says, "This isn't what we meant."

  • Development took the story literally.
  • Testers validated that email messages were sent.
  • No acceptance criteria had outlined format, timing, or channel.
  • The Sprint ends with a sense of having wasted time.

This breakdown was not due to incompetence, but to assumption. Everyone operated in good faith, just not with shared understanding.

Ways to Mitigate the Effects:

To reduce requirement misunderstandings, teams must operationalize clarity. That means making ambiguity visible and creating mechanisms to counteract it.

  1. Strengthen Requirement framing:
    • Use acceptance criteria to anchor shared expectations.
    • Apply Job-to-Be-Done language to express value, not just behavior.
  2. Make Conversations Repeatable:
    • Record or summarize key decisions in collaborative tools.
    • Use visual models, mockups, or workflow sketches.
  3. Validate Early, not just at Demo:
    • Refinement should be a shared activity to align on value and clarity.
    • Trigger lightweight reviews before development begins.
  4. Shift from Documentation to Demonstration:
    • Use examples and test cases to illustrate outcomes.
    • Pair requirement writing with scenario-based discussions.
Conclusion:

Misunderstood requirements aren't an edge case, they're the silent majority. Agile's reliance on conversation and collaboration is powerful, but fragile when left to chance. Shalloway's insight invites teams to look critically at how requirements are structured, communicated, and confirmed. Leaning on acceptance criteria, visual models, and outcome-driven framing methods can close the gap between intent and implementation. In this sense, clarity becomes not just a byproduct of good Agile practice, but a prerequisite for it.

Key Takeaways

  • Misunderstanding is likely whenever ambiguity exists in requirements.
  • Acceptance criteria reduce ambiguity by grounding intent in observable outcomes.
  • Shared understanding cannot be assumed from conversation alone.
  • Techniques like Jobs-to-be-Done framing and visual artifacts strengthen alignment.
  • Validation must begin before coding, not at the Sprint Review.

Summary

Shalloway's Law reminds Agile teams that miscommunication is the default state unless actively corrected. Relying solely on stories, discussions, or documentation opens the door to multiple interpretations. Teams that elevate acceptance criteria and scenario-based clarification gain a sharper, shared understanding of the work. This not only protects against rework but accelerates delivery of what actually matters.