Can a user story be written from a developer's perspective?

User stories are always written from the perspective of the system's user. If you're writing it from someone else's perspective, then it could still be a story, but not a user story.

I'd also point out that the "As a X, I want Y so that Z" is the Connextra format for user stories. Originally, user stories were not written in this format. Instead, they were a brief title and longer description on a card. A team at one company developed a consistent format for their title and it grew in popularity. It could be beneficial for other teams, but the format doesn't make something a user story or even a story.

If you are using stories as a Product Backlog Item, a good question would be if the description of the story adequately communicates the value of the Product Backlog Item to key stakeholders. Would stakeholders outside the development team understand why "enhancing XYZ API to call ABC API" would be more valuable than some other piece of work? If not, consider how you can better write this title to more readily communicate value to all stakeholders.

Can a user story be written from a developer's perspective?

It's conceivable, but should it?

Bear in mind that not every Product Backlog item needs to be captured as a user story. None might be.

For eg:

As a developer, I would like to enhance XYZ API to call ABC API?

Why does the Developer wish to do that? A user story should make the value of doing so clear. For example:

• Is the Product an IDE for which the enhancement would add value from a Developer's perspective?
• Does the Developer wish to reduce technical debt? Undone work has a negative influence on the delivery of value.

As a developer, I would like to share my thoughts on whether a user story can be written from a developer’s perspective. User stories are typically written from the perspective of the system’s user, focusing on what they want to achieve and why. However, it is possible to write a story from a developer’s perspective, but it may not be considered a user story in the traditional sense. The “As a X, I want Y so that Z” format is commonly used for user stories. It’s important to ensure that the value of the work is clear and communicated effectively to all stakeholders.

User stories are not created from the perspective of the user, they are told by the user. Users describe their work or their needs.

A developer is a user of an API. So a developer can tell the devs behind the API about their needs. They, or their product owner would then create backlog items.

If those are the same people, however, it doesn't make much sense. Also in the case of API calls requirements are usually known upfront. So why bother with user stories?

I think the user story can still be written in the format, it's just that the user will be changed here. Instead of writing the story from the perspective of the developer enhancing the API, I would write it from the perspective of any user who is going to make a call to that API (since it is going to be helpful to all users/developers who would want to make the API call).

Rememeber, everyone in the team has to understand the stories in details to accomplish their tasks. Scrum team members without Dev background would have hard time understanding stories if you write from Dev prospective. I always suggest to write stories simple with some examples.