That's likely to be highly dependent on the kind of project.
In the case of software development for example, I would generally recommend you apply the principle of documenting the *product*, not the project. Keep in mind that product documentation will be for at least two audiences with potentially quite different needs: the users and the technical team. Consult those groups about what documentation they need and in particular how to deliver it. Wikis and backlogs tend to work better than static documents when it comes to software systems. Saving Changes...
"Necessary" is going to vary - maybe by company, maybe by project, maybe by the agile approach you're using. Some people will tell you NO documentation (I've heard that from developers), but that's not what the agile manifesto says.
A Scrum team might only care about user stories, but the larger project might have additional documentation requirements. A scaling approach (Scrum@Scale, LeSS, SAFe) might have additional documentation requirements beyond what the dev team needs. Saving Changes...
We need to separate documentation from project management information. The former might be lighter-weight and fit for purpose ("How") but the information captured will need to address control and delivery objectives (the "What").
The team will have significant influence over this but so will applicable organizational standards and industry regulations which is why stakeholders outside the team should usually be involved in developing the list of required documents.
"When one door closes another door opens; but we often look so long and so regretfully upon the closed door that we do not see the ones which open for us."
Community Champion
