Writing test cases in Agile projects

Dmitry, Scrum has nothing to say about whether the team writes test cases or not. What it says is that, at the end of every Sprint, what is produced has to be “done”. This means that it has to be production-ready, potentially shippable and as a result carefully tested.
Acceptance criteria are basically test cases. They provide a great deal of information that the programmers can use in advance of coding a user story and testers can use as a reference to check if the story is fully and correctly implemented. Here it is vital that testing be viewed as part of the development process, not something that happens after coding is done. That's why many Scrum implementations, and my as well, use TDD, BDD or both.
It's very important that acceptance tests (criteria) should be written by PO (possibly with someone from software development team / a tester) rather than by a developer. And tools such as FitNess or Selenium are very effective for this kind of work.

> How do you conduct testing? Are test cases necessary for projects or
> is it a wasted effort and the main thing is to read written requirements
> and meet Acceptance criteria?

To reduce wasted effort, how about discussing the requirements instead of just reading them, and meeting acceptance criteria by designing tests first?

Test scripts will ensure that the acceptance criteria is met and might elaborate the scenario of what has been done or tested against a specific user story. Having that said, it is possible to Not write test scripts but ensure that user stories covers full details including performance, load, negative scenarios which is bit of a over ask sometimes.

Writing test cases is one of the most time-consuming activity in agile. There is a lot of documentation required to maintain throughout the project. Sometimes, documentation is necessary but it is not important for new requirements in testing.
Instead of writing test cases, you can prepare a checklist of all tests you need to do. This helps you to do more testing in a short span.

I think writing check-list might lead to individuals having their own interpretation of the scenarios and success/failures thereby delivering something different than what is intended. I might work for few simple and obvious functionality but again it is very relative term as to what we can call it simple depending upon the domain knowledge and composition of the Dev team.