If your team uses user stories to define requirements, I highly recommend making sure you keep the user at the center of the stories. Let’s say a user comes to you and says, “We need to enhance the system to make sure we send certain key customers gifts on their birthday.”
Developers are technical folks, and it’s natural for them to immediately start thinking about how they’re going to implement this new feature. Because of this, their first instinct is often to write what I call a developer story rather than a user story. It will likely sound something like this:
As a developer I need to add the field DateOfBirth to the customer table so the system can know to send them a birthday gift
The problem with this is that when you work with the user to validate the story and gather acceptance criteria, these technical stories often cause them to disengage and feel they can’t contribute. If instead, stories are written from the viewpoint of the user, they’ll be much more likely to feel ownership and provide more useful feedback.
Given the birthday gift requirement above, a better user story might be.
As a customer service employee I need to be able to record a customer's date of birth so I can ensure we send them a gift for their birthday.
As a customer service employee I want to receive a notification two weeks before a key customer's birthday so I can ensure I have time to write a personal card for them.
As a developer I need to create a notification service in order to get notifications to customer service employees.
Of course, there are always exceptions. Sometimes a user story really is for the developer, but these cases are typically reserved for internal team or infrastructure stories. If the story is that the developers want a framework to start using ATDD, for example, writing that story from the standpoint of the developer is absolutely natural. In this case, the developers are the users receiving the benefits of the work.
Give it a shot. Your users and stakeholders will thank you.