Agile teams try to avoid the over-detalization of the customer requirements. In many cases the initial requirements are specified as loosely as in one sentence. In order to keep focus on the real customer demand (and not on what dialogs he'd like to see) the feature requests are often expressed in a form of "As a , I want [so that ]". For example, "As a network administrator, I want to monitor the most active nodes of the system so that I was able to easily balance the load". This form of requirement works very well until you start to work on it. It allows for capturing the original user need, while delaying the implementation specifics as long as possible, so that the team was able to work on it with as much information as possible.

Most if not all of the agile software development processes are based on the assumption that it is hardly possible or not possible at all to predict the real requirements and real workload size at the beginning on the project. The whole idea of agility is to try implementing the most critical stuff, see how it goes, get customer feedback and adjust the close plans.

Such limitation of the upfront planning minimizes the amount of time wasted on never used overplanning and on developing features, that after later consideration happen to be wrongly understood or unnecessary at all. Also the detailed plan non-existence welcomes changes easier. If there are no planning results to modify, there is no temptation to just follow the obsolete plans.