I don't understand the differences between the following terms:

How do these terms work in the agile methodology? What's the difference from the waterfall approach?

  • What is the point of adding links to wikipedia articles? Everyone knows where wikipedia is. This is a good question, because it attracted an answer which is much more concise and useful than reading 5 Wikipedia articles on related subjects.
    – jwg
    Commented Oct 22, 2015 at 11:16
  • 3
    There are few benefits for OP to add links to articles: (1) showing effort and research (2) helping the next guy, who will find this answer (3) train new question askers to use wikipedia first, because many do not (4) saving the time for person answering this question Commented Oct 22, 2015 at 21:32

4 Answers 4


I've seen TDD/BDD/ATDD used interchangeably with Scrum/Kanban/Agile, so the confusion is understandable. Here's my take on the differences:

  • Waterfall is a software development methodology where each kind of development activity happens in a separate phase (requirements gathering, design, development, testing...). Typically, waterfall projects work best where the problem the software is intended to solve is fully knowable and clearly defined. Not many software projects meet that criteria - it's the unknown unknowns that cause problems.
  • Agile is a software development philosophy that aims to focus more on short cycles with all development activities happening simultaneously (although not on the same parts of the project at the same time - as new requirements are discovered, the team builds them into their design while working on developing and testing areas they designed in previous cycles). There are a number of Agile methodologies including:
    • Scrum, which focuses on constant communication between team members via frequent short ceremonies. I've often seen Scrum used as the framework for an agile process, with a Kanban board used as the primary tool to communicate progress to people outside the team.
    • Kanban, which focuses on the Kanban board (at least in my experience). The board holds the tasks agreed on for an iteration, and team members choose tasks to move them to the different state columns as they work.
    • There are other agile methodologies, but the Scrum/Kanban combination is one of the more common varieties.
  • TDD/BDD/ATDD are software development techniques that can be used in any methodology although aspects of all three are often part of a team's agile approach.
    • TDD is Test-Driven Development: the idea is that unit tests are written first, then enough code is written to make the tests pass. The pure TDD cycle is to write one failing unit test, then enough code to pass the test. Then a second failing unit test, then enough new code to pass both tests. And so forth.
    • BDD is Behavior-Driven Development: this technique operates at a slightly higher level than TDD while still following the basic principle of writing the test, then coding to pass the test. BDD is usually the lowest level that will use the Given-When-Then pattern to describe the test (e.g. "Given that I have logged in, When I click the My Orders link Then I will be directed to the Order List page"). It can be difficult to distinguish between BDD and ATDD - the difference here is subtle.
    • ATDD - is Acceptance-Test-Driven Development: this and BDD are often, in my experience, used interchangeably, particularly if the acceptance test is expressed in the Given-When-Then pattern (such as: "Given that I am a logged-in user, When I go to My Orders Then I will see a list of all the orders I have made in the system, ordered from the most recent to the oldest.")
  • It's not uncommon to see blends of all three techniques used:
    • User requirements are written as one or more user acceptance tests (that fail)
    • Each acceptance test is decomposed into one or more behaviour tests (that fail).
    • Each behaviour test is decomposed into one or more unit tests (that fail).
    • At this point coding begins and each level iterates until all the user acceptance tests are passing.
  • 6
    Great summary. As an addition to your description of 'Waterfall', in my experience the Waterfall approach seems common in situations where life/safety are involved or hardware costs are considerable. E.g. medical, military, flight, space, nuclear, etc. Important that all possible modes are considered before beginning design, coding, etc. The newer approaches (Agile, etc.) seem to be used where the cost of "do overs" is lower.
    – JS.
    Commented Oct 21, 2015 at 22:06
  • 1
    @JS - that's a good point: in those areas the problem domain tends to be well-defined(or definable), so a Waterfall approach makes sense.
    – Kate Paulk
    Commented Oct 22, 2015 at 11:24

The difference between Waterfall methodology and an iterative methodology (agile, Scrum, etc.) is that Waterfall requires each step of a defined process be performed to completion in a particular sequence. In an iterative methodology you complete small slices of the problem at a time by gathering just a few requirements and coding each one to completion, then seeking feedback from your users.

The Waterfall

In Waterfall you follow a rigid pattern. You gather all the requirements you can, then you analyze them, then you design a solution, then you code a solution, then you test the solution, then you deploy the solution. This originated in the engineering processes of the physical world long ago, and was carried over to the software world because it's a process that is well understood.

The problems with Waterfall

The main problem with Waterfall is that if it's not perfectly done up front, costs or quality will suffer. If the tester finds a bug, they report it to the coders. The coders look at it and may say "well that's a flaw in the design", and hand it up to the designers. The designers say "well, this is what's in the requirements." So they go back to the analysts, and so on, and so on. They fix the requirements, pass the fixed requirements to the designer, who modifies the design, who gives it to the coders, etc. Every mistake is extremely expensive to fix. To avoid this cost Waterfall requires intense attention to every detail at every step. The requirements must be reviewed by designers, testers, and the stakeholders. The designs must be reviewed, the code must be reviewed, etc.

And this is where Waterfall can lead to poor quality. If the tester passes a bug to the coders, the coders may look at it and say "this will take a big design change to fix correctly, or we can just put a patch here." Management will almost always say "do the patch, because it's faster than fixing the entire design and we have a deadline to meet." And it doesn't take a lot of patches to turn a flexible design into a brittle product.

The other problem with Waterfall is the lack of continual feedback from the users. The Waterfall process can take months or years. By the time their product is fully delivered, the team may have interpreted the requirements differently, and developed something completely different from what was intended or desired. Or the market for the product may have changed, and the product is no longer needed. All that work becomes a sunk cost that never delivered a dime of value.

Iterative product management

In an iterative approach that uses Behavior Driven Development and Test Driven Development the cycle of product development is dramatically shortened. In some methodologies such as Scrum, iterations can be defined in terms of weeks; in others, iterations can be done in days, hours, or even minutes. With BDD requirements are gathered, and then specifications are written in the form of functional tests. One common complaint of developers is that requirements are poor; in BDD a poor requirement is immediately identified because it's impossible to write a test for it. So the requirements are fixed almost as soon as they're being written. This reduces many problems.

These functional (behavioral) tests obviously fail, because there is no code written yet to pass them. The developers then write just enough code to pass the tests (they do this in short TDD cycles, building up the feature by creating a quick skeleton first, then adding bits of the feature one piece at a time.) During this activity, the developers may discover flaws or omissions in the specifications; fixing them is often as cheap as asking the stakeholder a clarifying question, fixing the test, then fixing that code module. The key is the faster the feedback, the cheaper it is to course correct.

Test Driven Development then builds code through a three step process: red, green, refactor. When they start development, they write a test that fails (failing tests show up as red). By the act of writing the test first, the developer must think about the interface to the module they're writing, and how to make it easily testable. Stateless logic is easier to test than stateful logic, so they have incentive to write stateless code, dividing their code into service objects and value objects. Code that is easy to test is code that is modular and easy to use. This provides the first step in good design. They then write enough code to pass the test (it's green.) Now they can refactor the code with confidence. They refactor the code they've just written in order to eliminate duplication, and to adhere to the SOLID design principles. The act of refactoring imparts good qualities associated with modularity: tight cohesion and loose coupling, which make the code module easy to use and easy to reuse. And the tests serve as continual proof to the developers that their changes are not harmful.

The Waterfall is inverted

TDD turns the Waterfall model upside down: you test the requirements first, then you test your code, then you write your code, and then you finally impart good design to the code. Because the team is producing tiny slivers of functionality that are always fully tested, quality starts high and stays high. Because the design principles are followed during refactoring, the code is modular, flexible, and reusable. And because the stakeholders are continuously involved in reviewing and using each little sliver of functionality, they can make changes at any time without incurring huge costs.

Iterating works because it's continually answering two questions: "are we building the product right?" and "are we building the right product?"

The problems with iterative

And this is where iterative approaches have limits: meeting deadlines with a specific list of features. A product owner needs to see that the team is heading to a goal, and they can even get a measure of the pace of progress, but the actual features available on date X can't be perfectly predicted very far in advance.

This also becomes a problem when an iterative team has to interface with external teams. If both teams are agile, they'll understand each others' issues; but if one team is a hardware team or service organization, their flexibility is often out of their control. This can lead to friction and such interactions must be carefully managed.

How to choose between Waterfall and Iterative

There are long debates on whether Waterfall is the best choice to develop a product, or iterative. The arguments in favor of Waterfall are that it has been successfully used for a very long time. Some people are really good at Waterfall. Managers and executives have to work with budgets and deadlines, and the Waterfall steps are easy to understand.

It's not intuitive that iterative approaches produce higher quality products; it's also uncomfortable to be told "we'll have some kind of product for you on January first, we can assure you that it'll work perfectly, but it may not be the product you're thinking of today." These debates go on and on, but don't help answer the question of which methodology to choose. It turns out the debates are focusing on the wrong things. There is an easy test to determine whether a product should be built with waterfall or iterative, and that is to measure the cost of deployment.

The cost of deployment

Consider a web site. You can deploy a new version of the web site by clicking a mouse - that's as cheap as it gets. Consider a smartphone app that can be deployed by sending a new version to the app store - also fairly cheap. Even a traditional computer program can have updates delivered to clients via the web.

Now consider a tough-to-deploy client, such as the software that runs an alarm clock. You can iterate all you want in the comfort of your office, but once you send those clock orders to an offshore factory, and 10,000 clocks are sitting in a shipping container on the dock or have been delivered to the store shelves, it's far too late to be updating their software. The production and installation of hardware makes iteration of those steps too expensive.

And then there are the impossible to iterate products. Anything that impacts health or safety has certain standards of design and testing that are mandated by government or industry agencies; and the current standards do not allow for iterative approaches to design. You can't deliver 5% of an air traffic control system and expect planes to keep safely flying.

Mixing Waterfall with Iterative

Back to the alarm clock example, it's tempting to use iterative development on the software or firmware portions of the product in order to guarantee high quality, and to use Waterfall to effectively manage the production of the hardware. Such a mix has to be done carefully. Iterative approaches cannot guarantee deadlines will be met, but factories, component orders, installers, and freight shipping is usually scheduled months in advance and can't be delayed without significant costs. In these cases you may have to look at custom approaches. Perhaps the hardware can be designed to be flexible - a dummy blank button on version 1.0 of the product could hide the missing SuperWakeyAlarm feature that gets delivered with version 2.0. Perhaps the boxes get printed without the missing feature, but when it's delivered to the factory, the boxes get a "New! Improved!" sticker that touts the new feature.


In general, iterative approaches deliver higher quality software faster and cheaper than Waterfall; but not every project is suitable for iterative product management.

  • 1
    I think your description of Agile as being Waterfall backwards is a bit forced and not really accurate. Design doesn't only happen in the end with Agile, for instance.
    – jwg
    Commented Oct 22, 2015 at 11:17
  • I started reading this comment and thought "oh great someone is about to rehash software engineering 101" but this is actually insightful even if you're already familiar with the concepts. Commented Oct 22, 2015 at 13:26
  • @jwg, I've seen the practice called "emergent design". Instead of doing all the big definition up front activity of designing classes, etc., you add a slice of functionality, then refactor as needed. If done well, this will result in a domain model that models your problem, without expending the design efforts up front. Developers still need to understand design, of course, but they don't have to do it until it's needed. Commented Oct 22, 2015 at 14:58

Kate's answer is great, but I want to throw in my 2 cents for differentiating TDD/BDD/ATDD.

TDD is writing tests first and letting those tests drive the development of your application. This introduces the idea of Red/Green/Refactor. The basic process is to:

  1. Write a failing test
  2. Make the test pass with application code
  3. Refactor the application code for maintainability, performance, etc. (while keeping tests green)

Note that TDD is a high level concept and can be applied at any level of testing in the pyramid (unit, integration, acceptance).

BDD is a technique for doing TDD. You frame your tests so that they test application behavior and NOT specific scenarios. That may seem a bit nuanced, and it is. And it is the reason that BDD is so interchangeably used with TDD and ATDD. Consider this test:

describe Calculator do
  it "returns 2 when I add 1 and 1" do
    expect(Calculator.add 1, 1).to eq 2

What does this test? Well, we've framed it so that it ONLY tests that 1 + 1 == 2. We're not testing a behavior, but instead, a specific data set. We're not proving that 2 + 1 == 3. Or 99 + 1 = 100.

But what if we framed our test like this?

describe Calculator do
  context "when adding 1 to a number" do
    it "returns the next sequential number" do
      expect(Calculator.add 1, 1).to eq 1.next

This seems super trivial (and my example definitely is), but this test proves that 1 + 1 == 2 and 6 + 1 == 7 and 1500 + 1 == 1501.

That's BDD in a nutshell.

BDD is a high level concept too and can be applied to any level of the testing pyramid. A declarative approach to acceptance testing is kind of inherently BDD. But you can do imperative acceptance testing that is more tied to specifics and generally less BDD in nature.

Unit testing should be BDD in my opinion. I find that it often is, though it's not often framed that way.

ATDD is testing from the business' perspective. We're not concerned with the HOW but the WHAT.

Where a unit or integration test concerns itself with the implementation (the API returns the correct status code), an acceptance test concerns itself with the result (the user can log in).

ATDD is taking this tenet of acceptance testing, automating it, and letting those tests drive the development of the application. Thus you can see how the TDD fits into ATDD.

Of course, all of these terms have been mixed, picked apart, and redefined too many times. When I'm discussing their implementation with a coworker, I think it's helpful to define them to set a common foundation. My BDD is not always the same BDD that my coworker is referring to. The same goes for ATDD and (to a lesser extent) TDD.


Changed a bit about BDD to clear up my thoughts.

TDD is a process. BDD and ATDD are techniques for doing TDD. Writing a unit test, then coding to make that unit test pass is also TDD.

But TDD has become synonymous with that last example, and I think this is where a lot of the confusion comes from.

  • Great answer but I think the OP might get confused/puzzled regarding the BDD example. That's a tough nut to crack though (BDD) Commented Oct 21, 2015 at 16:04
  • CAR ANALOGY ALERT: TDD is the engine and tire and brake testing, BDD is "when I put the car in reverse, drive backwards." It's not (as) (deeply) concerned with how the code does it.
    – Kyle Hale
    Commented Oct 21, 2015 at 19:07
  • 1
    I think we've tied TDD to unit testing too much. But from that (very common) perspective, your analogy works. In my mind, TDD is just the term we use (or should be using) to refer to writing tests first. BDD is TDD. ATDD is TDD. And writing a unit test for a private function then coding to make that test pass is TDD. Basically, TDD is a general term that refers to a process. BDD is a technique to see that process through, as is ATDD. TDD == unit testing is where a lot of the confusion comes from, IMO.
    – Johnson
    Commented Oct 21, 2015 at 19:26

Kanban and Scrum are Agile process frameworks and therefor have short iterative development cycles as compared to the longer separate phases of waterfall projects. Agile projects focus on getting a working product in short iterations, each iteration should deliver a piece of deploy-able product.

BDD, TDD and ATDD are not development methodologies and can be used in waterfall projects. They are techniques to design requirements and test-cases which can be automated. Often they are used in Agile software development, because they give a fast feedback cycle for requirements and code under development.

Because Agile development does not have a separate testing phase its important that most if not all testing is automated. Applying BDD or TDD makes sure each new development has automated test coverage and the behavior is safe guarded iteration after iteration. This is why these practices are more important in Agile development than in Waterfall.

I would read the Art of Agile book, although it describes another Agile flavor eXtreme Programming. It clearly describes technique's like TDD how and why they are used. Another good read is Agile Testing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.