A Scrum team would like to defer creating Acceptance Criteria until after they've implemented the associated User Story. Why do many Scrum proponents discourage this approach?

Defining Acceptance Criteria prior to the sprint provides an opportunity to validate the story's correct behavior with the Customer (i.e., the team can know if they are on the right track).

Acceptance Criteria can only be defined after the Team knows how the code works

Defining Acceptance Criteria prior to the sprint reduces the Team's velocity

Defining Acceptance Criteria prior to the sprint can improve the story's estimate

Defining Acceptance Criteria prior to the sprint improves the Team's planning of what Tasks are required to implement the User Story

Which of the following activities occur during the Sprint Planning meeting?

		The Team populates the upcoming Sprint with as many User Stories as appropriate given the estimates of the stories and the Team's historical velocity
		The Sprint Planning Meeting is timeboxed to 15 minutes
		Developers volunteer to implement Tasks
		The Product Owner decides what work needs to be done in the following sprint, and the development team clarifies whether or not they can commit to the work or not.
		Select work (e.g., User Stories) from the Product Backlog (in order of their priorities) to implement in the upcoming sprint
		The team ignores the Acceptance Criteria since they will not be used until the final incremental release of the product to the customer
		The team creates a new Sprint Backlog for the upcoming sprint
		Create new Tasks in the Sprint Backlog that will be required to implement the User Stories selected for the upcoming sprint
		The Team demonstrates the product to the customer to obtain their feedback
		Each team member reports what they did yesterday, what they plan to do today, and what impediments they were unable to resolve