In Agile documentation is followed very limited which causes inconvenience in managing some important QA Artifacts. What is the best way to handle it?

Your stakeholders must understand the total cost of ownership (TCO) for a document and your stakeholders must explicitly decide to invest in that document. There is no solid relationship between project success and writing comprehensive documentation, and in fact it is more likely that the more documentation that you write the greater the chance of project failure. What would you rather have,-page system document that is likely to have a significant number of errors . Documentation includes interim work products such as project plans and specifications that you may not decide to retain at the end of the project. For long iterations, four or more weeks, write the documentation in the iteration that the corresponding functionality was developed in.

For short iterations, two weeks or less, consider writing the documentation the following iteration (although strive to write it that iteration). As you migrate to an Agile software development process you will constantly run into people who are not as agile, people who see nothing wrong with documentation handoffs. Point out that there are better ways to communicate-face-to-face conversations, video conferencing, telephone conferencing-that you should consider before writing documentation, and whenever possible try to find a better way that fulfills your needs.