Agile Series Part 4: Beware of Unclear Business Needs

Context: This post is part of a retrospective series written during my transition out of Credimi, reflecting on the reality of scaling a fintech engineering organization. As we grew from a founding team to multiple squads, the primary risk shifted from technical execution to organizational alignment. We learned that the hardest question isn’t “can we build it?” but “should we build it?” This series details the specific management structures and Agile patterns we adopted to prevent chaos and ensure our processes scaled alongside our headcount.

Unclear business needs present risks in both Agile and Traditional Project Management approaches—though for different reasons.

The Problem

The consequences of ambiguous business requirements are significant: teams make suboptimal choices, implementations miss the mark, and projects experience cost overruns and delays.

Everyone nods along in the meeting. Everyone thinks they understand. Then work begins, and it becomes clear that nobody was talking about the same thing.

Same Risk, Different Causes

Traditional PM Perspective

Reliance on extensive upfront documentation creates a false sense of clarity. Shared documents could lead to a false sense of shared understanding.

Documents contain implicit assumptions that non-expert readers may not grasp. The author knows what they meant. The reader interprets through their own lens. The gap between these interpretations only surfaces when code is written and expectations collide.

Agile PM Perspective

While Agile reduces documentation, the risk doesn’t disappear—it transforms. The challenge becomes ensuring stakeholders genuinely understand requirements without comprehensive written specifications.

Long specification documents in Traditional Project Management are replaced by conversations in Agile Project Management. But conversations can be just as misunderstood as documents if we’re not careful.

Three Mitigation Tools

1. Acceptance Criteria

Define explicit checklists of conditions that must be satisfied.

Vague: “The system should play music throughout the house.”

Concrete: “I can play music from Spotify in the living room, terrace, and kitchen simultaneously.”

The second version leaves no room for interpretation. Either it works or it doesn’t. Either you can hear Spotify in all three rooms at once, or you can’t.

2. User Stories

Replace lengthy specifications with narrative descriptions emphasizing the who, why, and what.

The format “As a [user], I want [goal] so that [benefit]” forces clarity about purpose. It’s harder to write a user story for something nobody actually needs.

Like painting the Mona Lisa, requirements become clearer through iteration. You start with a vague concept (“woman in pastoral setting”), sketch the outline, add color, refine details. Each iteration brings you closer to the vision.

3. Story Mapping

Create visual hierarchies showing coarse-grained needs and their relationships. This helps teams understand the “big picture” and plan phased delivery to maximize early value.

This story map phases the flat-furnishing project. Top-level needs (sleeping, eating, social life) break down into specific requirements. The horizontal axis shows delivery phases: essentials for moving in, additions for the housewarming, and aspirational items for your dream home.

Story mapping answers questions like: “What’s the minimum we could ship that would still be useful?” and “What depends on what?”

The Bottom Line

Understanding requirements remains critical regardless of methodology. The Agile approach prioritizes conversation and iterative refinement over static documentation.

Documents lie through omission. Conversations reveal assumptions. The best requirement is one that’s been tested against reality and refined based on feedback.

Write less, talk more, ship early, learn fast.