If not user stories, then what?
Although many teams use user stories to plan out the increments of software they are working towards, the scrum guide does not specifically say anything about user stories.
If a team were not to utilize user stories, what alternatives would they have? Are there any other viable alternatives to user stories?
I remember that up until about 4 years ago it was common for Use Cases to be included in a product backlog. These would map to one or more scenarios that would be treated much as tasks are today...a scenario would be given to a particular developer to work on.
I think the industry moved away from this partly because of the overhead involved in defining use cases and scenarios and partly because they weren't very good placeholders for a future conversation. They were treated as specifications or part-specifications. Although they could and were used in iterative-incremental processes such as RUP, I can't say they are particularly agile. In my experience Use Cases can lead a team deeper into the weeds of specification where they become absolute devils to estimate.
The other common way of representing requirements is as a Prioritised Requirements List. This is a hierarchical breakdown of requirements (possibly just in free text) which can roughly correspond to user stories, features, and epics. Spreadsheets have been used to capture scope this way for many years, often by organising it in terms of Must-have, Should-have, and Could-have requirements. Simple prioritised lists can certainly be used to constitute a Product Backlog as long as each entry can be given an estimate.
Why don't you want to use user stories?
Like you say; Scrum does not say anything about which approach to use about populating the backlog. As long as there is one, there is a shared understanding in the Scrum Team on what the items mean and the list is prioritised.
The reason why user stories are a good idea, is because they focus on functionality and on business value. It's easier for a product owner to sort the backlog if items are not technical. And to extend Ian's answer; user stories are a lot easier to order than a use case. And a lot easier to write with a PO.
In general, all other approaches will work if there is shared understanding in the team and the PO can priorise them. It's not about the processes and the tools, it's about humans and interactions :)
Some examples would be:
1) User Stories – simple format, easy to understand, drives conversations
2) Use Cases – formal syntax, more difficult to understand
3) Gherkin – “Specification by Example”
To be honest, I've never seen a team applying Scrum and NOT using User Stories, so perhaps it would be interesting to find out the reason why User Stories is not a preference?
Thanks for the very helpful posts. To update, i picked up the book "User Stories Applied" by Mike Cohn and it's answered my questions about user stories. I'd highly recommend it for anyone who's struggling with building out their product backlog.