Why Agile Didn't Solve the Problem

Two years ago, your team introduced Scrum. The change was noticeable almost immediately. No more multi-hundred-page specification documents. No more waterfall gates before a single line of code was written. The ceremonies were lightweight. The rhythm felt right. The developers were relieved - and honestly, so was everyone else.

And then - quietly, without announcement - your team started writing user stories.

Someone was drafting them. Someone was clarifying requirements in Slack, mid-sprint. Someone was sitting with a stakeholder on a Tuesday afternoon, figuring out what "the notification should do" actually means. Someone was making judgment calls in sprint planning about what "done" would look like.

That work didn't disappear when you adopted Scrum. It went underground.

This is the thing I had to learn the hard way, after spending two years genuinely believing we'd solved the requirements problem with a good agile process. We hadn't solved it. We'd just stopped seeing it.

Where the work went

When Agile arrived, requirements engineering didn't leave the building. It distributed itself across the team - into informal conversations, into Slack threads, into the comments section of Jira tickets, into the fifteen-minute pre-planning call where someone finally asks the question that should have been asked in refinement two weeks earlier.

The work is still there. It just has no address anymore.

In the era of formal specification, RE had a home. A phase, a role, a document. You could look at the process and point to it: this is where requirements are gathered, this is who does it, this is what gets produced before building starts. You could criticize that approach - and many of the criticisms were valid — but you could at least see the process. You knew when it had happened and when it hadn't.

Agile replaced that with something more flexible, and more honest about uncertainty. The big upfront analysis was genuinely wasteful. Agile was right to challenge it. What Agile didn't do was hand anyone a replacement for the actual work of figuring out what to build. It assumed that work would happen - in sprints, in conversations, just-in-time. The assumption is reasonable. The problem is that "will happen informally" is not the same as "will happen well."

Who's responsible

So who actually does requirements work in a Scrum team?

The Scrum Guide says the Product Owner is responsible for maximizing value and managing the product backlog. Stakeholder communication, prioritization, backlog ordering - that's the official territory. Structured requirements engineering isn't mentioned. The framework's own creators have explicitly said the PO role was never intended to be a requirements engineer role.

In practice, every team fills this gap differently. Some POs write the user stories and consider that done. Some teams write the stories themselves during sprint planning, based on whatever they think was discussed. In too many teams, the answer to "who owns requirement quality?" is a long pause followed by everyone looking at the PO, who hasn't had time to think about it because they've been in three other meetings.

It's been contested for years. Practitioners in the field - including the IREB community - are consistent on this point: requirements engineering matters just as much in an agile environment as in any other. It just gets performed differently. Someone still has to do it. Agile doesn't specify who.

What Scrum is - and what it isn't

The problem isn't that Scrum is a bad framework. The problem isn't that your team is doing Scrum wrong. The problem is more specific - and more useful to name clearly: Scrum structures delivery. It does not structure requirements.

Scrum is good at rhythm: delivering working software in short increments, with ceremonies that create accountability. Sprints tell you when to integrate. Reviews tell you when to demonstrate. Retrospectives tell you when to stop and reflect. That's real and valuable.

What Scrum doesn't tell you is whether the thing you're about to deliver was the right thing to define in the first place. It assumes that question has been answered - or that it will answer itself through sprint-by-sprint conversation. Sometimes it does. Often it doesn't. And when it doesn't, the delivery machine runs perfectly while building the wrong thing.

That's not a Scrum failure. That's a framework doing exactly what it was designed to do, in a space it was never designed to address. It's not a weakness of your team. It's a gap in the framework.

Three things already happening in your team

In every agile team - yours included - three requirements engineering activities are happening whether the team names them or not.

Elicitation is figuring out what stakeholders actually need. It happens when someone asks in a refinement meeting "what should this feature do?" It happens when a developer pings the PO on Slack about an edge case. It happens when a customer complaint arrives and someone has to interpret it before it becomes a backlog item. Elicitation is constant. It's just rarely structured, rarely prepared for, and rarely owned by anyone in particular.

Specification is what writing a user story is supposed to do - turning what was elicited into something a developer can build from. It's what acceptance criteria are for. In practice, specification often stops at the format: the three fields get filled, the story lands in the backlog, and the conversation that should have produced the content never fully happened.

Validation is your sprint review. The demo where a stakeholder says "yes, that's what I meant" - or doesn't. Also the bug report two or three sprints later that isn't really a bug. It's a requirements gap that finally made itself visible in production.

These three activities are running in your team right now. The question isn't whether they're happening. The question is whether anyone is steering them - or whether they're running in the margins, driven by whoever has the most energy that day, filling in gaps as they surface rather than closing them before they open.

Implicit RE doesn't eliminate the problems. It makes them harder to see. The problems are still accumulating - they're just distributed across Slack threads and sprint review comments rather than concentrated in a specification document you could at least criticize.

The user story trap

User stories are where this becomes clearest.

The most useful way I know to think about what a user story actually is comes from Ron Jeffries, who proposed what he called three C's: card, conversation, confirmation. The card is just the reminder - the thing on the sticky note. The real work is the conversation that surfaces the actual requirement. The confirmation is the acceptance criteria that capture what was agreed. In Jeffries's framing, the story is a prompt for requirements work, not a substitute for it.

That distinction matters because the format doesn't carry the requirement. The conversation does. When a conversation actually draws out what users need, what constraints apply, what "done" is supposed to mean - that's requirements engineering happening. The user story is where you record the output. It's the container. It's not the content.

When a user story lands in the backlog with a vague "who" and an unclarified "why," the container is there. The content isn't. What you have is a request: someone wants something, for some reason, and the team will figure out the details as they go. Sometimes that works. More often - if the causal chain from the last lesson is still fresh - you've just added an item to the list of requirements decisions that will surface as a problem several sprints from now.

It sounds like a small distinction. It isn't. Writing "As a user, I want to export my data so that I can analyze it elsewhere" is not requirements engineering. It is the starting line for requirements engineering. The question of who the user is, what data, in what format, for what kind of analysis, on what schedule - that's the work that has to happen before the story is ready to carry. If it hasn't happened, the story is a placeholder with a well-structured sentence on it.

This is where most teams land. They have a process that works for delivery. They write the stories and run the sprints, and the same requirements problems surface, sprint after sprint - because the process assumes the RE has been done, while the RE is happening in the margins, unsteered, by whoever is available.

That's not a failure of effort. It's a failure of visibility. And the first step is simply seeing it: requirements engineering is already happening in your team. It's just not being treated as craft.

The next lesson looks at what that craft actually means - for a team without a dedicated requirements engineer, working under sprint pressure, with stakeholders who come to meetings with opinions rather than requirements.

Further Reading