Product Backlog items
Now we are working on a project we are using user story as a format for our product backlog items, now if the client ask for a new task that can not be written as a user story or each time there is a task of user story not achieved during the sprint can we add the task as it is in the product backlog
Given this is the opening statement from the Scrum Guide section that describes the Product Backlog, what do you think the answer would be?
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
I really hope you said "yes". However, you really should be looking at these "tasks" to scrutinize their need. Not all work can be described using the standard "<as a user> I want to <do something> so that I can <gain benefit>" model so commonly used in user stories. But as long as a description of the value that needs to be delivered and how the Scrum Team knows that the value is present can be captured, it very well should be placed into the Product Backlog. However if this is just a task to do something like "add tests" or "update documentation for the changes we just made", I would not expect them to be put into the Product Backlog. Those should be done during the Sprint and if not, the team needs to understand why they weren't and how to get them done during the Sprint in the future.
There is no such thing as "user story format". A user story is a placeholder to have a conversation. There is the Connextra format for user stories ("As a {role}, I want {requirement}, so {outcome}"), but this is a format that one team found useful and shared with the world. The purpose of a user story is to remain focused on the user's needs and objectives rather than the features or functions of a system. Sometimes, focusing on the user means it's difficult to capture the work, so people may use job stories or problem stories or improvement stories.
If following a specific format is helpful to your team, try to use it where it makes sense. If there's important work that doesn't fit that format, feel free to look for other formats. As long as the Product Backlog is the single source of work for the Scrum Team and the way the content is presented makes the work clear and transparent to stakeholders, the format of Product Backlog Items is generally irrelevant.
Keep in mind, the user story is a business need, not a piece of functionality. Part of refinement is breaking down the need into smaller needs that can be satisfied, not functional breakdown. Stories aren't going to save the company, but the idea of business need rather than cascading system functionality will make it easier to break work into non-dependent pieces.
can we add the task as it is in the product backlog
Your Product Owner can choose to include the item, if he or she thinks it makes sense and is valuable enough.
Your team's challenge would then be to refine the item so it is Ready for future Sprint Planning, and can be Done by the Developers within one Sprint.