Statistically speaking, user story maybe the most popular requirement technique in Agile but I am curious to know the alternatives and why.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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
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.
Others like suggest the exact opposite, and put the value first: "In order to achieve ZZZ as a XXX, I want YYYY".
In XP, extreme programming:
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:
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.
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.