If you've worked on an an agile project before you're probably already familiar with the basic user story format i.e. "As a [User], I want to [Do Some Thing], so that I can [Get Some Benefit]". Which is great and all, but too often this ends up as a list of stories that look something like:

"As a User, I want to login to the application, so that I can use the software."

Clearly this doesn't communicate much more than the requirement for a login function. There's no context, no useful benefit and not much discussion that could happen around the edges. Instead of writing a story, you've requested a function which your developer will then dutifully build without any thought as to what it was for.

So let's break this down to try and make it more useful.

Step 1: Define the user properly

As a ___ ...

You may have already created customer personas or perhaps user roles for the application and that would definitely be a great place to start this story.  Stating "As a returning customer..." is a big step forward from "As a user...".

But don't stop there, try to express the specific need the customer has which is driving the story e.g."As a returning customer who needs to make a repeat purchase..."  

Now we have a much better idea of who this user is and what's driving their need.

Step 2: Think about the problem

...I want to ___ ...

Instead of simply specifying the function e.g. "...I want to login", consider the problem that the customer is facing and not how the customer will solve that problem. In this case it might be:

"...I don't want to waste time re-entering my contact details for each new order I make..."

At this point the engineering team is reading the story and understanding "oh okay we're gonna need to allow customers to save a profile and login to the system." but they will also be seeing where this functionality might extend e.g. access to past orders etc.

Step 3: Articulate the main goal

...so that ___ ...

If you haven't put the effort into writing Steps 1 and 2 properly, then articulating the main goal might be tough. However if you've got a clear understanding of the user, their current state, and the problem they're trying to solve - then explaining and even quantifying the main goal should be pretty straight forward e.g.

"...so that I save time and complete a new order within 5mins, which would be half the time it currently takes me."

Now the implementation team has a metric to work with i.e. I should be able to to access the system and process a repeat order within 5min.

You've now got a pretty powerful user story which will stimulate conversation and will ultimately help you to create a better product.