Story versus task

I'm not sure that it matters.

A user story is just one method of capturing a user need. There are some formats and guidance around how to create and manage user stories, but they aren't anything special. There are plenty of other methods and formats that can be used, such as use cases. The important thing is to ensure that you are capturing the information needed to design, create, and verify the work.

Scrum, with respect to the Scrum Guide, is silent on the format of Product Backlog Items. Yes, user stories are common, but aren't required. I'd focus on problems. Are there problems with the way your team is managing their work? Or is this an area for improvement to ensure the team understands what to build to satisfy users?

The difference between a story and task is 1 letter.  Other than that there shouldn't be a difference in the Scrum world.  The real question is can stories and tasks deliver value?  As @Thomas points out the Scrum Guide refers to Product Backlog Items and not stories.  For example this excerpt form the Scrum Guide.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

A Story, Task, Bug, Epic, or any other Action Item can fulfill that statement. The key phrase is the middle sentence. If those attributes exist for every Product Backlog item, you can call it whatever you want. But using "story" as an analogy, I would say that any "story" that doesn't contain those attributes would be a fairy tale as compared to a self-help book.

So take a second look at the Product Backlog Items that exist.  Do they have all the attributes? If so, no problem exists. If not, that is what should be discussed with the team.

Thank you for the comments, maybe I shouldn't have said "story" or "task". The PBIs I have range from things that are things a user would want to see "New login screen" to things that say "create connection string to database". some items seem to be things you do in order to resolve a PBI rather than a PBI by itself.

Thanks for the comments. I probably shouldn't have mentioned "story" or "task". I have a list of items with some looking like something a user would recognize (new login screen) and see a value for and others looking like something a person does (change connection string) as part of creating that valuable item. 

It may not matter much how you manage the items (stories or tasks) from a backlog standpoint. I think  stories are proven way to capture user needs. It is a narrative from user how she/he sees the world (perspective) and what changes will improve her/his world. User stories feels like it has life than business requirements or tasks. Teams using stories will have more empathy towards user and can visualize better what user is going thru. Just my thoughts.

Might the PBI written in "user story" format be the what, and the "task" is the work on the Sprint Backlog to implement the PBI, also known as the how?  Does this help?

Thank you all for the comments and I think I have my plan of attack in coaching the team.

Keep in mind that a Scrum team is a self-organizing team so the difference between a "story" and a "task" are more about the culture of the company and the tool they are using.

Places that I have been involved with consider the difference to be the point of view that it is written.  A story is written from a customer/user point of view and a task is written from a developer/QA point of view.  Scrum doesn't define either.