There is a conversation happening in nearly every large software organisation right now, and it usually goes something like this.
A programme director stands in front of a steering committee and says "we are running Agile." A few slides later, you see a Gantt chart that stretches eighteen months into the future, with locked phases, fixed budgets, and sign-off gates every quarter. Somewhere in the middle of that Gantt chart, under a heading called "Requirements Phase," there is a box labelled "User Stories."
That box is where the trouble begins.
This article is about what actually happens when teams try to use User Stories inside a Waterfall project. It covers why the combination so often fails, the situations where it can work, and the specific steps that stop the hybrid from becoming a bureaucratic nightmare. Along the way there are examples from real industries, a decision framework, and a plain breakdown of every major pitfall.
If you are an RTE, a project manager, a BA, or a delivery lead on a programme that does not fit neatly into one methodology, this is written for you.
First, let's get clear on what each one actually is
What Waterfall really means
Waterfall is a sequential delivery model. Work moves forward in phases. Requirements, design, build, test, deploy. Each phase has a defined output, a formal review, and a sign-off before the next one starts. In strict practice almost nothing goes backwards, at least not without a formal change process. Changes are expensive because every upstream document may need to be rewritten.
Waterfall is not a bad idea. The model has its roots in a 1970 paper by Winston Royce on software development, and it suits environments where requirements are stable, contracts are fixed, and predictability matters more than speed. Construction projects, hardware manufacturing, regulatory compliance programmes. These are places where a sequential model makes sense. You do not want the architect changing the floor plan after the concrete is poured.
The problem shows up when software teams, working in genuinely uncertain environments where users do not fully know what they want until they see it, try to operate the same way.
What a User Story really is
A User Story is a placeholder for a conversation — not a requirements document.
A User Story is not a requirements document. This is the most important thing to understand, and it is also the most frequently misunderstood.
A User Story is a placeholder for a conversation.
The classic format is "As a [type of user], I want to [do something], so that [I get this benefit]." It is short by design. It is vague by design. The vagueness is not a flaw, it is the feature. The story is a reminder that at some point the team needs to sit down with a real user or a product owner and figure out exactly what "done" looks like.
The detail lives in the conversation and in the acceptance criteria that emerge from it, not in the story itself. And those acceptance criteria can change as the team learns more.
This is why User Stories were born inside Extreme Programming, one of the methods that later shaped Agile. In a two-week sprint, the team picks up a story, has the conversation, defines the criteria, builds the feature, and shows it to a user. If the user says "that is not quite what I meant," the feedback loop is two weeks long. The cost of being wrong is small.
The collision: What happens when you put stories inside Waterfall
The story gets frozen
When a Waterfall project uses User Stories, the first thing that almost always happens is that the stories get written in the requirements phase and then locked. A change control process gets put in place. Any modification to a story requires a formal Change Request, a review board, an impact assessment, and sometimes a new project budget line.
In enterprise programmes, changing a "locked" User Story can trigger a multi-week change control process.
This is not a theoretical risk. It is what happens on the ground, repeatedly, in enterprise programmes across every sector.
Case Study: Public Sector IT Programme
A public sector IT programme replacing a legacy case management system ran for two years. In month two, during the requirements phase, the team wrote two hundred User Stories covering every function of the existing system. By month eight, when development was underway, the government had changed its data retention policy. Three of the most complex stories were now wrong. Getting them changed required a formal Change Request, a board review, and a four-week pause.
By month fourteen, the team had stopped even trying to update the stories. The developers were working from verbal instructions. The stories sat in a SharePoint folder, gathering dust. The project delivered something, but it was not what the stories said, and it was not quite what the users wanted either.
This is the core failure mode. The story is treated as a contract rather than a conversation, and contracts resist the reality of evolving user needs.
The story gets inflated
The second thing that happens is that the stories stop being stories and start being specification documents.
A healthy User Story might be "As a finance controller, I want to export a report in CSV format so that I can load it into our budgeting tool."
In a Waterfall context, the BA team, under pressure to produce something "complete" before the sign-off gate, expands this into a thirty-page document. It specifies the exact columns in the export, the date format, the encoding standard, the file naming convention, the error message text for every failure scenario, and the exact button label on the UI.
This document is then reviewed and approved. It is locked. Developers must implement it exactly as written. Three months later, a developer notices that the budgeting tool the client actually uses does not accept that date format. The fix takes fifteen minutes to make in the code. But changing the specification document takes three weeks of bureaucracy.
The backlog becomes a task list
In Agile, the backlog is living and prioritised. In Waterfall, it becomes a static list where every item has the same priority: "required for phase completion."
In a healthy Agile environment, the backlog is living and prioritised. Stories at the top are well-defined and ready to work on. Stories further down are rough sketches that get refined when the time comes. The Product Owner is constantly adjusting the order based on what the business needs most right now.
In a Waterfall programme with User Stories, the backlog becomes a static list of deliverables. Every item has the same priority: Required for phase three completion. The concept of reprioritisation disappears because the phases are locked.
Case Study: Retail Bank Mobile Platform
A retail bank implementing a new mobile banking platform had account statements in phase two and biometric login in phase three. Midway through the project, customer research showed that users cared far more about biometric login than statements — they rarely looked at statements in the app at all.
In an Agile team, the backlog would have been reordered in a single planning session. In this Waterfall programme, moving biometric login to phase two required a contract amendment with the system integrator, a revised testing schedule, and a revised UAT plan. The business case for the change was never approved. The project delivered the original sequence, and the first version of the app had disappointing adoption because the most-wanted feature came six months late.
The acceptance criteria problem
Acceptance criteria deserve their own section because they are where so much of the day-to-day pain lives.
In Agile, acceptance criteria are hypotheses. They are the team's best current understanding of what "done" looks like, written just before the story gets picked up. They might be three bullet points. They are expected to be refined during development.
In Waterfall, acceptance criteria become legal language. They are reviewed by lawyers, signed by the client, and referenced in dispute resolution. Every word matters.
This creates three distinct problems:
1. Over-specification
Teams write acceptance criteria so detailed that developers must follow them literally, even when the literal interpretation produces something unhelpful. A classic example: the criteria say "the system shall display an error message when the upload fails." The developer displays the message. It says "Error: upload failed." The user has no idea what to do next. The criteria are met. The user experience is terrible. The story is marked as done.
2. Under-testing
Because the acceptance criteria are so detailed, QA teams test against the document, not against the actual user need. They confirm that the error message appears. They do not test whether the user can recover from the error. The gap between specification compliance and user value grows wider throughout the project.
3. The change request nightmare
An insurance company building a claims portal found this out when they tried to improve error messages based on user feedback during UAT. Plain-English rewrites would take a developer half a day. But the acceptance criteria specified the exact text of every error message. Changing the text required a Change Request, a review, a sign-off, and a board meeting three weeks later. The clearer error messages made it into the product, but not before consuming forty hours of project management time for what was effectively a copywriting task.
The documentation double burden
One of the most underestimated costs of the hybrid model is documentation.
Agile values working software over comprehensive documentation. This does not mean Agile teams write no documentation — it means they write documentation that is useful, not documentation that is performative.
Waterfall requires comprehensive documentation because the documentation is the evidence that each phase is complete. Without it, you cannot get the phase sign-off.
The Maintenance Trap
A logistics software company built a route optimisation tool using User Stories in a Waterfall structure. For every story, the BA wrote an acceptance criteria document, the architect wrote a design specification, and the tech lead wrote a test case matrix. These documents were reviewed and signed off.
Six weeks into development, the algorithm team discovered that the approach described in the design specification did not scale beyond ten thousand routes. They redesigned the algorithm. The code worked brilliantly. But now the design specification was wrong. Nobody updated it because updating it would require another review cycle. The test case matrix, written based on the old design, was also wrong. But since the tests passed against the actual code, no one flagged it.
At go-live, a new team member joined to maintain the system. She read the design specification. She believed the system used the old algorithm. She made a change based on that belief. She broke the system in production.
The documentation was not just useless, it was actively misleading. Frozen documentation is worse than no documentation, because it creates false confidence.
Real-world examples of the hybrid going wrong
The examples in this section are composites drawn from real programmes across these industries. Details have been generalised and anonymised, but the failure patterns are real and repeat consistently.
Healthcare: The Patient Records Portal
A regional NHS trust in the UK built a new patient portal to replace a paper-based system. The programme ran on a Waterfall structure with fixed phases, but the clinical team asked the project manager to use User Stories because they had read about their benefits in a trade magazine.
The stories were written by BAs during a series of workshops in month one. They covered appointment booking, test results, medication requests, and GP communication. They were signed off by the clinical leads and locked.
By month six, the national body governing patient data had issued new guidance on how test results could be displayed to patients. The guidance required significant changes to three stories covering test results. The Change Request process took eight weeks. Development on those stories had to stop while the review was underway.
By month ten, two of the GPs who had signed off the original stories had left the trust. Their replacements had different views about how the appointment booking should work. Getting sign-off on the existing stories from the new GPs required renegotiation. Four stories were changed. Two were cancelled.
The portal launched fourteen months late. Most of the original stories were no longer accurate descriptions of what was built. They existed as historical documents that everyone agreed were wrong but no one had the budget to update.
NHS digital portals face the dual challenge of clinical requirements and national data governance — a context where frozen stories create serious delays.
Financial Services: The Core Banking Replacement
A mid-sized European bank replaced its core banking system over three years. The programme used a regulated Waterfall structure because the regulator required evidence that each phase had been formally reviewed and approved.
The programme director, familiar with Agile, introduced User Stories as the mechanism for capturing requirements within each phase. Each story would go through the Waterfall gate process: define, review, approve, build, test, sign off.
The approach worked reasonably well for the first phase, which covered basic account operations. The requirements were stable, the stories were short, and the acceptance criteria were clear.
It fell apart in phase two, covering payments. Payments are complex, cross-border, and subject to regulatory change. During the six months of phase two, the SEPA payment scheme issued two updates that affected the stories covering international transfers. Getting the Change Requests approved took three months each. By the time the second change was approved, the first change's implementation had to be reviewed again because the second change affected the same code.
The payments phase ran four months over schedule. The post-project review identified the Change Request process as the primary cause. The recommendation: stories covering regulatory areas should be written no more than four to eight weeks before implementation, not twelve months before.
This is actually an important insight. The problem was not User Stories in a Waterfall. The problem was User Stories written too early and then frozen too long.
Retail: The E-commerce Replatform
A European fashion retailer replaced its e-commerce platform over eighteen months. The project used Waterfall phases for infrastructure and integration work, and tried to use Agile sprints for the customer-facing features. User Stories were written for the customer features.
The hybrid model created a coordination problem that the programme had not anticipated. The infrastructure team was working to a fixed Waterfall plan. The customer feature team was working in two-week sprints. The infrastructure team could not respond to sprint-level requests because they were locked into their phase plan.
When the feature team discovered that the product search needed a different database index than originally specified, getting the infrastructure team to change the index took six weeks — because it was a change to the Waterfall plan.
The teams ended up operating in separate silos, with a growing list of integration issues that neither side had authority to resolve. The resolution was to establish a joint integration backlog, effectively a third process sitting between the two methodologies, that had to be reviewed weekly by both teams.
This added overhead that had not been budgeted. The programme ran over cost by fifteen percent. But the joint backlog actually worked reasonably well once it was established. It is an example of a workaround that eventually became a better model than the original plan.
When Waterfall infrastructure teams and Agile feature teams operate in silos, integration issues multiply — a joint backlog can bridge the gap.
When the hybrid actually works
The combination of User Stories and Waterfall is not always a disaster. There are specific conditions under which it delivers genuine value.
Regulated environments with phased delivery
In healthcare, finance, defence, and government, programmes often face a real constraint: regulatory bodies require formal evidence that each phase has been completed and reviewed before the next phase begins. You cannot simply adopt pure Agile because the regulator will not accept "we work iteratively" as evidence of compliance.
This is sometimes called "phased agility." It is practised successfully in medical device software development, where FDA or CE certification requires evidence of each development phase, and in financial services, where internal audit requires sign-off at each gate.
Success Story: Swedish Bank Open Banking APIs
A Swedish bank implementing open banking APIs under PSD2 used exactly this model. The regulatory compliance requirements were handled through a Waterfall gate structure. The technical implementation within each regulatory phase was handled through two-week sprints with User Stories. The stories were only written for the current sprint's scope, never further ahead than four weeks. The team delivered all three phases on schedule and within budget. The post-project review attributed this to the fact that the stories were never frozen too early.
Proof of concept phases
Large Waterfall programmes often include a PoC or pilot phase at the beginning. This is exactly where User Stories add value without causing friction.
The PoC is, by nature, exploratory. The team is trying to validate technical assumptions. User Stories are an excellent tool for defining the scope of what you are trying to prove. Once the PoC is complete, the lessons learned feed into the formal requirements for the main programme, which can then follow a more traditional Waterfall structure.
Success Story: Smart Meter Data Platform
An energy company piloting a smart meter data platform used this approach. The PoC lasted eight weeks and was run entirely with Agile sprints and User Stories. The team discovered that the original data model was wrong — the meters reported data in a format the system could not handle efficiently. This was discovered in week four of the PoC, not in week forty of the main programme.
The PoC stories were discarded after the PoC. The main programme started with accurate requirements because the PoC had done the discovery work. This is the User Story doing exactly what it was designed to do: enabling discovery.
Sprint-based execution within fixed phases
Sprint-based execution within fixed phases: the most commonly successful hybrid pattern for large ERP implementations.
This is the most commonly successful hybrid pattern. The overall programme has Waterfall phases with fixed dates and deliverables. Within each phase, the team works in two-week sprints, using User Stories to organise their work.
The constraints matter here. Stories are written for the current or next sprint only. The Product Owner has authority to reprioritise within the phase but cannot change the phase deliverables. Changes to phase deliverables go through the normal Change Request process, but changes to sprint priorities do not.
This model is used successfully on large ERP implementations, where the high-level scope is fixed (the contract with the system integrator specifies what will be delivered) but the detailed implementation approach evolves sprint by sprint.
The role of the Product Owner in a hybrid programme
In pure Agile, the Product Owner is the single most important role for making User Stories work. They own the backlog, they prioritise, they attend sprint reviews, and they have the authority to say "that is not what I meant, let us change it."
In Waterfall, this role often does not exist. It gets replaced by a Project Manager who manages the timeline, and a Business Analyst who captures requirements. Neither of them has the authority of a Product Owner, and neither of them is expected to change their mind.
Without this role, the hybrid model drifts. If the Project Manager is in charge, the stories get frozen. If no one is in charge, the stories become chaos.
Large programmes often create a specific role for this, sometimes called a Programme BA, a Delivery Owner, or a Chief Product Owner, who sits between the Waterfall governance structure and the Agile delivery teams. Note that in frameworks like SAFe, this authority deliberately sits with Product Management rather than with the Release Train Engineer, whose job is facilitation; the person protecting the stories needs decision rights over content, not just over process.
How to make the hybrid work: A practical guide
Define what is fixed and what is flexible
Before any stories are written, the programme needs to answer two questions clearly.
What is fixed? Fixed means it will not change regardless of what we learn. Typically the overall scope of each phase, the go-live date, the budget, and any regulatory or contractual obligations. These are Waterfall artefacts. They are documented, reviewed, and locked.
What is flexible? Flexible means it can and should evolve as the team learns. Typically the detailed implementation of each story, the acceptance criteria, the sprint priorities within a phase, and the technical approach. These are Agile artefacts. They are treated as conversations, not contracts.
Writing down this distinction at the start of the programme, and communicating it to every stakeholder, prevents most of the disputes that derail hybrid models.
Write stories as late as possible
This is counterintuitive for Waterfall programme managers, who want everything defined upfront. But it is the single most effective change you can make in a hybrid environment.
Stories should not be written more than four to eight weeks before they will be worked on. Stories written in month one for work that starts in month nine will be wrong. Not possibly wrong. Definitely wrong. The business will have changed, the technology will have changed, and the team's understanding will have changed.
Write stories for the current phase only. Use higher-level epics or capability statements to describe future phases. Refine those into stories when the time comes.
Separate the requirement from the story
A requirement is the fixed constraint. "The system must comply with GDPR" is a requirement. It will not change. It exists at the Waterfall layer.
A User Story is the flexible expression of how that requirement will be met by a specific user in a specific context. "As a customer, I want to download all the data the company holds about me so that I can check what has been stored" is a story. How that story is implemented — which screen it appears on, what format the download takes, how long it takes to generate — can evolve.
When teams conflate the requirement and the story, they freeze things that should be flexible. When they separate them, they protect the contractual layer while giving the delivery team the room they need to find the best solution.
Create a lightweight change process for stories
Change Requests are necessary for changes to fixed artefacts: scope, budget, phase deliverables. They are not necessary for changes to User Stories within an agreed phase.
Establish a clear policy: changes to sprint-level stories are handled by the Product Owner, reviewed at sprint planning, and do not require a formal Change Request. Changes to phase deliverables require a formal Change Request with impact assessment.
This keeps the governance process proportionate to the risk. A developer asking to change the wording of an error message does not need the same process as a stakeholder asking to add a new module to phase two.
Keep stories short and testable
This sounds obvious but is frequently ignored under Waterfall pressure. Every story should be completable within a single sprint. It should have two to five acceptance criteria, each of which can be verified by a tester in isolation. If a story has fifteen acceptance criteria, it is either too large or too detailed.
Stories that are too large should be split into smaller stories. Stories that are too detailed should have their acceptance criteria moved to a separate technical specification, which can be more detailed, while the story itself remains brief.
The story is the "what" and "why." The technical specification, if needed, is the "how." Keep them separate.
A decision framework: Which model should you use?
| Approach | Use When | Examples |
|---|---|---|
| Pure Waterfall | Requirements are fully stable and will not change. The client relationship is contractual and adversarial. Regulatory sign-off at every phase is mandatory. The team is inexperienced with Agile practices. | Defence procurement, large infrastructure projects |
| Pure Agile | Requirements will definitely evolve. The team has a genuine Product Owner with decision-making authority. The business can review and respond to working software every two weeks. There are no fixed contractual milestones. | New product development, early-stage startup builds |
| Hybrid | There are fixed phase milestones or contractual deliverables at the programme level, but detailed requirements are uncertain within each phase. The team has some Agile experience but operates in a regulated or large-enterprise environment. There is someone who can play the Product Owner role within the Waterfall governance structure. | Large ERP implementations, government IT programmes, multi-vendor enterprise transformations |
| Do not use hybrid | The team has no Agile experience and no one to guide the practice. The Change Request process is so slow that it will prevent any meaningful iteration. The project timeline is so short (under three months) that introducing a second methodology creates more overhead than value. | — |
The most common mistakes and how to avoid them
Mistake: Writing all stories in month one
This is the most common mistake and the most damaging. Stories written at the start of a long programme will be wrong by the time they are built. The team will spend months defending decisions that no longer make sense.
The fix: Write stories only for the current and next sprint, typically no more than four to eight weeks ahead of the work. Use epics or capability statements for everything beyond that.
Mistake: Treating story points as delivery commitments
In Agile, story points are a relative measure of complexity, not a promise of delivery by a specific date. In Waterfall, "we estimated this story at five points" gets translated into "you committed to delivering this by Tuesday."
The fix: Separate estimation from commitment. Estimates are the team's best guess about complexity. Commitments are the sprint goal — the outcome the team is aiming for. These are related but not the same.
Mistake: Creating "mock stories" that are really feature requests
A common pattern in hybrid programmes: someone takes a feature list from a requirements document and reformats each bullet point as a User Story. "The system shall export reports" becomes "As a user, I want to export reports." This looks like an Agile artefact but is actually just a requirement with different syntax.
The fix: A real User Story identifies a specific user with a specific need and a specific reason for that need. If you cannot fill in all three parts of the "As a / I want to / So that" format without being vague, the story is not finished. Go back and talk to an actual user.
Mistake: The Sprint Zero that never ends
Some teams spend an entire Sprint Zero writing all the stories for the whole project before development begins. This is Waterfall under a different name.
The fix: Sprint Zero should be a single sprint used to set up the environment and write stories for the first one or two sprints, no more.
Mistake: Maintaining stories and documentation separately
If the stories are in one system and the design documentation is in another, they will diverge. Within a month, no one will know which is current.
The fix: Pick one system as the source of truth. If the story changes, the associated documentation changes in the same place, in the same update.
The future: Where hybrid models are heading
Flow-based delivery: continuous work movement through defined stages, with User Stories flowing through a Kanban-style board within Waterfall phase boundaries.
The gap between Agile and Waterfall is narrowing, and not because Waterfall is being replaced. It is because organisations are finding more sophisticated ways to blend the two.
Flow-based delivery is one emerging pattern. Work moves through defined stages, similar to Waterfall phases, but within each stage, work is continuous rather than batch-processed. User Stories flow through a Kanban-style board within the boundaries of each stage. There are no sprints, which removes some of the Agile ceremony overhead, but there is still a living backlog and continuous refinement.
Outcome-based measurement is another shift. Instead of measuring whether a User Story was delivered on time, programmes are starting to measure whether the story delivered the intended user value. A story that was completed on schedule but that no user has actually used is not a success. A story that was delivered two weeks late but that increased user satisfaction scores by fifteen percent is a success.
AI-assisted story management is beginning to appear in enterprise tooling. Some vendors are adding features that analyse a set of User Stories and flag inconsistencies, identify dependencies across phases, or suggest refinements based on similar past stories. These features are still maturing and vary widely in quality, but they do not replace the human judgment required to write good stories; at best, they reduce the administrative burden.
The fundamental question is shifting
None of these trends resolve the fundamental tension between Waterfall's need for predictability and Agile's need for flexibility. But they do suggest that the choice between the two methodologies is becoming less binary. The question is not "Waterfall or Agile?" It is "what level of predictability do we need at what level of the programme, and how do we organise work flexibly within those predictability constraints?"
Summary: What actually matters
After all of this, the core message is simple enough to fit in a paragraph.
User Stories were designed to enable conversations about user needs, not to document requirements. When you put them into a Waterfall programme and freeze them, they stop being tools for discovery and start being bureaucratic artefacts. The team spends its energy managing the stories rather than building the product. The flexibility that makes stories valuable is the first casualty of Waterfall governance.
But the combination can work if you protect that flexibility deliberately. Fix the things that genuinely must be fixed: phase scope, budget, regulatory obligations, contractual milestones. Make everything else a conversation. Write stories late. Keep them short. Separate them clearly from formal requirements. Give someone real authority to manage them. And be ruthless about not expanding the process to justify its existence.