If we can’t finish all tasks, does this mean we are doing Scrum wrong?

Paiman,

Did you expect to start using Scrum, and that everything would proceed without issue?   Did you expect that your team would become the first in the history of Scrum to start out that way?

Jokes aside, it seems that your team is over-estimating the amount of work that it can complete in a given sprint.   There could be a variety of factors in play here, such as poor refinement of items, unresolved dependencies, overambitious forecasts, work being pushed to the team, etc.   

Assuming that this is discussed in your Sprint Retrospectives, what does the team believe are some of the root causes?

Perhaps you should try a few sprints where the team forecasts less work, and then pulls in additional items into the sprint as capacity dictates?

There are various reasons, but we seem never able to finish all items selected for an sprint.

Regardless of the number of items completed, are you meeting the Sprint Goal agreed between the Development Team and the Product Owner?

Timothy and Ian hit it perfectly. Set a Sprint Goal and don't over-estimate. 

Does your team have a Definition of Ready that is utilized in grooming/refinement? If not, you should craft a DoR so you're not selecting items that are not ready. 

Does your team have a Definition of Ready that is utilized in grooming/refinement? If not, you should craft a DoR so you're not selecting items that are not ready. 

This might be helpful, but a definition of "ready" can sometimes lead to a bureaucratic approach towards backlog refinement.

The Scrum Guide already defines "ready":

Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning

Simon, I agree but if we are honest, anything in Scrum can lead to a bureaucratic approach. From the OP's admission, the team is struggling to complete their Sprint Goal and Sprint Commitments. While there are many variables in play, I would bet that at least 1 aspect is that the team is not grooming their backlog effectively. This is where a DoR can help. 

A lot can be at fault here, which is why Scrum is so good at transparency and inspection.

In Daily Scrums are the estimates being checked in the Sprint Backlog?  It should be fairly evident if your teams are underestimating then they can hash it out in a daily.

Perhaps there is work not accounted for by the Product Owner like security or even UI enhancements.  Those need to be re-negotiated to be able to be in play for an increment.

Kanban puts an emphasis on the dev team in terms of throughput of customer value being created and takes a very deep look at WIP.  Pehaps setup a Kanban board?

You see, there's many things that could be the issue...you need to let your Dev team take a first at it and if they cannot resolve, the Scrum Master should be working to clear obstacles.