As Tech Republic’s Rick Freedman tells it, every time he posts on an agile topic, the most common argument he hears against agile methods is against the concept of estimation. That is, without exhaustive requirements documentation, how does a development team know what to do or even where to begin? Freedman’s right: This is, by far, one of the most prevalent knocks on agile. But in a post titled Â“Estimating the Unknown,Â” he makes a good case for why agile’s lack of comprehensive requirements gathering is nothing to get too worked up about.

According to Freedman, the first things that any development team will ask upon receiving a project are: 1) How much budget do you have? and 2) When does it need to ship? But, interestingly, in a more traditionally managed environment, the team would still put together an enormous list of requirements as if the project’s conditions were not limited in any way. Of course, they are limitedÂ—by budget and timeline. As Freedman suggests agile simply rephrases the question from Â“How much for all these features?Â” to Â“How many of these features can you include within this budget and time-box?Â” In essence, agile acknowledges that work does not occur in a vacuum, but is, in fact, subject to real-world conditions.

What Freedman doesn’t entirely address (he hints at it in the last sentence or two of the piece) is how requirements, like development in an agile environment, are gathered incrementally. That is, agile teams can afford to push some of the requirements gathering to later in the development cycle, when more information about the product is known. During that initial sprint, the team really only needs to know which functionality is most essential to the productÂ—the rest will become clear through sprint review meetings with the Product Owner and customer.