Sprint planning

Trying to add something to @Kiron´s comments above you can consider user stories (or what you use to specify needs/requirements) as documentation. Key inside them is acceptance criteria. Adding to add you could consider DoD (Definition of Done) and DoR (Definition of Ready) like documents too. But the key thing is the goal or the commitment about what the team will be deliver at the end of ths sprint/iteration. The format and place where you document all these varies from company to company.

Feroz -

As per the Scrum Guide, sprint planning should identify one or a few sprint goals which may be documented based on the team's ways of working and a sprint plan which might just be a shift in product backlog items from a product backlog queue to a sprint backlog queue in either a physical or online work management system.

Anything else is optional and left to the the needs of the team and other key stakeholders within that specific product context.

Kiron

Feroz -

As per the Scrum Guide, sprint planning should identify one or a few sprint goals which may be documented based on the team's ways of working and a sprint plan which might just be a shift in product backlog items from a product backlog queue to a sprint backlog queue in either a physical or online work management system.

Anything else is optional and left to the the needs of the team and other key stakeholders within that specific product context.

Kiron