Many, if not most, software shops prefer to use Agile instead of Waterfall. That makes sense, right? Short cycles where you see progress quickly that allows you to make changes without the sky falling; I like that too! Agile also affords a close environment where the team is co-located, so that communication can move freely, allowing everyone to know exactly where the project stands at any time. Despite the team co-location and ability to communicate at any moment, however, Agile development still needs requirements.
It’s true that Agile does not call for a traditional BRD or SRS, but that does not mean Agile developers should avoid documentation and software requirements. Thoughts still need to be written and managed. The developers still need a reference point other than their minds from which to develop. Working within Agile, a team is likely using a requirements management tool. Requirements would be written, managed in the tool, and prioritized to sprints allowing for changes.
After completing a sprint it’s 110% possible that requirements in a later sprint could be changed. Does that negate the benefit of defining requirements? Absolutely not. Think about the cost/benefit of requirements for a moment. How successful was any project with a budget of $1MM or more that had no written requirements? How painful was it?
Agile does offer continuous improvement and change that allows for project agility (no pun intended). It also allows for swift interaction within the team and shows progress more quickly than other types of software development methodologies. And yet, software requirements are still needed to communicate what the business asks, and what the software needs to do. Without requirements, even an Agile team would be lost.
