In agile, requirements are progressively detailed, with the finest details being developed as late as feasible. There are three main reasons for this just in time requirements detailing: no time is wasted on requirements that are possibly not going to be developed, decisions about requirements can take into account lessons learned in prior sprints and the requirements fresh in the mind of the team when they begin developing because the lag time between specification and implementation is short. Enabling flexibility in the requirements backlog and minimizing wasted work are just as important as detailing the requirements.
Design documentation has its highest value in helping work out the details of the software under construction, not as post implementation documentation. As a post-implementation artifact, documentation must be kept up to date with the software which adds to the cost of any software changes. If the documentation is even slightly out of date, the documentation looses credibility – the code becomes the ultimate documentation. Unless the documentation is automatically generated, design documentation is of limited value and should be prioritized low.