As far as I know, there are no alternatives to user stories, intended in their original meaning of “placeholders for conversations that we need to have”.

Stories cannot be more than placeholders because

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

is one of the 12 core concepts in agile.

On the other hand, you might be referring to the: “As a XXX, I want to YYY, so that ZZZ” format. In that case, there are infinite alternatives, because that format is just a simple way of putting a little formality on something that is essentially informal.

The three parts of “story form” are three very important pieces of information that are useful to remember at all times (who benefits, what’s the final objective, the value), nothing more.

In fact, Mike Cohn suggests that the “value” is optional.

In my user stories book and in all my training and conference sessions on user stories I advocate writing user stories in the form of: “As a , I want so that .” While I consider the so-that clause optional, I really like this template.

–http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template

Others like suggest the exact opposite, and put the value first: “In order to achieve ZZZ as a XXX, I want YYYY”.

Elizabeth Keogh suggests that business value is more important than user role and presents a revised template for writing user stories, which she credits to Chris Matts. The traditional format emphasizes the importance of the user, mentioning them first. The newly proposed variation switches the emphasis to the business value

— http://www.infoq.com/news/2008/06/new-user-story-format

In XP, extreme programming:

User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.

–http://www.extremeprogramming.org/rules/userstories.html

So they are free form.

In general, there is no predefined concept and whatever works for the current team is fine.

A back log of user stories happens to be a good way to facilitate the communication of requirements. But agile wouldn’t be agile, if you weren’t allowed to come up with an alternative approach. Just remember the following:

Embrace Change

The only way to avoid waste, and be ready for priority changes late into your project, is to group your requirements into ‘chunks’. Preferably, each chunk by itself adds some value to the product. And these chunks should be small enough, so that they can be completed in a short time. That creates many opportunities in your project to change the requirements. If you call these chunks ‘user stories’, or something else… that’s not so important.

People over Processes

Agile is also about human interaction. So instead of writing a lot of requirements and handing over a massive document, agile encourages you to use human dialog. So its okay if the requirements are not too detailed at first, and then more thoroughly discussed with the team shortly before implementation. (You might want to keep a digital record of the outcome of these discussions though).

Planning and Reporting

By doing the detailed requirements as late as possible, you also avoid wasted time in requirement gathering.

Then, why even bother writing something like user stories in advance? Well, you need at least some ‘hook’ for future requirements, to be able to do planning, and predict the future (eg. a release date) based on factual data from the past.

User Stories

Looking back at these requirements, users stories are not so bad: They are a light-weight (single-sentence) representation of a chunk of requirements (the details to be discussed later). Allowing you to plan ahead and visualize your strategy (eg. a back log). With minimal waste.