Có một quan niệm sai lầm ở đây: Agile không khuyến khích các yêu cầu của dự án thay đổi. Nó thay vào đó cho phép thay đổi mà không lãng phí công việc, hoặc hy sinh các lĩnh vực phát triển quan trọng.
Có bốn hạn chế cơ bản cho bất kỳ dự án kỹ thuật nào; phạm vi, chi phí, thời gian và chất lượng. Thác giả định rằng những điều này sẽ là tĩnh. Đó là một giả định không chính xác; một hoặc nhiều trong số những LUÔN LUÔN thay đổi. Creep phạm vi, ngân sách bị cắt giảm và các "ẩn số chưa biết" khác LUÔN LUÔN can thiệp vào một dự án, thay đổi các ràng buộc. Thác nước không lường trước được điều này, vì vậy khi nó xảy ra, dự án thay đổi theo những cách không mong muốn; các tính năng quan trọng chưa được thêm vào sẽ bị mất đi hoặc nhanh chóng được thực hiện hoặc phải giải phóng bản phát hành hoặc chi phí bóng bay khi Thủ tướng ném tiền vào các nhà phát triển mới để tham gia và giúp hoàn thành công việc.
Agile, ngược lại, cho phép các ràng buộc thay đổi, và thực sự mong đợi nó. Nó thực hiện điều này bằng cách thực hiện công việc trong các phần nhỏ, có thể sử dụng được, theo các ưu tiên của chủ sở hữu, và do đó các phần này là lý tưởng ngay lập tức hữu ích cho chủ dự án. Do đó, giảm tiếp xúc với những điều chưa biết bằng cách không thực hiện các kế hoạch lớn trong một khung thời gian mà những điều chưa biết là lớn. Nếu dòng thời gian thay đổi, các nhóm có thể được thêm hoặc các tính năng ít quan trọng hơn "khử phạm vi" và hệ thống mà nhóm đã xây dựng không bị ảnh hưởng.
Nó cũng cung cấp các ước tính tốt hơn về thời gian và chi phí cần thiết để sản xuất phạm vi nhất định với chất lượng yêu cầu. Mọi người nổi tiếng là xấu khi ước tính công việc lớn; phải mất rất nhiều kinh nghiệm và tính toán trả trước nhiều hơn để thực hiện đúng. Ngược lại, mọi người thường là những người đánh giá tốt về những gì họ có thể hoàn thành trong một ngày, hoặc một hoặc hai tuần. Điều đó nhanh chóng tạo ra trạng thái ổn định nơi bạn có thể ngoại suy thời gian và chi phí công việc còn lại phải hoàn thành dựa trên tốc độ lịch sử của bạn, với độ chính xác hợp lý.
Đối với việc xác định điểm cuối, bạn đúng; một dự án Agile CÓ THỂ tiếp tục mãi mãi. Tuy nhiên, SLDC truyền thống cũng vậy; khách hàng thường quay lại với nhiều tiền hơn và một danh sách mong muốn nâng cấp. Sự khác biệt là không có một ranh giới rõ ràng giữa "phân tích", "thiết kế", "phát triển" và "bảo trì" khi nhìn tổng thể dự án; tất cả xảy ra từng viên gạch, chạy nước rút bằng nước rút. Nếu tại bất kỳ thời điểm nào, chủ sở hữu muốn gọi dự án là "đã hoàn thành", họ có thể và họ sẽ có tổng số "viên gạch" mà họ đã trả trong một "bức tường" vững chắc; nó có thể không cao hoặc kéo dài như dự định ban đầu, nhưng nó chắc chắn, thực hiện công việc và có thể được thêm vào một ngày sau đó với mức tối thiểu bị phá vỡ.