If not user stories, then what?

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 my teams, we actually tend to use a fairly ad-hoc approach. We make use of user stories as much as possible. Some tasks are very hard to describe in terms of user stories, so we also add more or less 'technical tasks' to a backlog if absolutely necessary. But we make sure that the PO understands what they mean. For smaller projects, we often don't even write (formal) user stories. We just identify logical chunks that we need to and write them down on a card (like 'Order a product' or 'Search for product'). As long as they are vertical instead of horizontal slices (e.g. every chunk has to represent a stand-alone piece of functionality).

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.

http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321…

I'm surprised by the number of responses that center into explaining why user stories are so great, but not many actually provide an answer about alternative ways to document requirements in an agile way.

The assumption many make is that by asking if there's an alternative to user stories it means I don't want to use them. But the question could be presented as a thinking exercise. Why do we use user stories and not anything else? Is there anything else? Should we all suppose that user stories is the superlative to capture requirements?

Is "agility"  a quality inherent to user stories?

What does Feature-Driven Development or Agile Modeling practitioners use to document their requirements? 

I have stated my opinion on multiple threads of this nature.  Are User Stories the only way?  Absolutely not.  The User Story format originated in eXtreme Programming as part of the "planning game".  At conception they didn't even include Acceptance Criteria as part of the story.  That was added later as people started to understand that just having the story statement wasn't enough to determine completion. The format has also evolved to include formats to convey Technical User Stories because the "person" based format doesn't always when the consumer is another technological entity.

While I don't advocate that User Stories are the only way to communicate the problem I do believe that the basic information the User Story was created to convey is critical.  Who benefits from the problem being solved, What is the need, How does the "who" benefit.  And add Acceptance Criteria to determine how you know that this problem has been solved properly. Understanding all of those items will help a Development Team build a solution that is going to be valuable to the stakeholders. 

User Stories have become an accepted industry practice because it helps people focus on conveying the correct information.  I find them useful when a team is newly introduced to agile development.  But over time many of my teams start to stray from them as they learn the principles of conveying problem statements in a way that can be understood by anyone reading them.  I have 3 teams now that will vary the way they write up their Product Backlog Items based on the actual problem. They still use the User Story format for some of the problem statements but they will also do some by writing a narrative as that is the best way to convey the information. 

If you look at the Scrum Guide there is nothing mentioned about user stories. In fact they are called Product Backlog Items (PBIs). Actually searching the guide for the word story results in 4 occurrences of the word history. The only place in the guide that I can find that actually defines any attributes of a PBI is this found in the section describing the Product Backlog (emphasis added by me):

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

Notice that 2 of those attributes(order and value) have nothing to do with the actual statement of the product. It could be argued that "value" should be part of the actual description but I feel is an implied value based on the information provided and the order of it in the Product Backlog. There are references to shared understanding of the PBIs as a team.  The Product Owner is responsible for ensuring that shared understanding exists and the Scrum Master has a service to the Product Owner to help them understand the need and benefit of that shared understanding.

So for the TL;DR of my post.  If the User Story format works for your team, do it. If there is another option that the team prefers and it still leads to shared understanding, do it.  As with all things Scrum and Agile, the only right way is what works for the people involved in the work. 

There are a number of different approaches to backlog items - Even Mike Cohn recorgnises that user stories are not the only way to build a backlog. To answer the original question, this Medium post lists three other story formats and Feature Driven Development: David Evans and Gojko Adzic like other formats - and tell us not to obsess over the format. Which is almost exactly what the scrum guide suggests by saying nothing about the format of product backlog items.

The value of the user story is that it forces the requirements to be defined from the perspective of the user/customer. It focuses on who, what, and why (as Daniel says above). Building a backlog of items that are user focused is valuable and serves agile principles well. So I would suggest when considering other formats if they answer those three questions: in particular, do they express the value of the feature simply and concisely. User stories are not perfect, but they are widely used because they are widely useful.

If I or my team were looking to not use user stories for the product backlog items, I'd also closely examine the reasons why (something like a root cause analysis). Depending on the reasons, this might suggest how to approach the backlog. For example:

• Is it because the user stories being written well. This is common: I've frequently seen stories that repeat the why as the what ("As a user I want to view the customer list so that I can see the customers we have"). The solution may be to learn new approaches to writing user stories or to look to improve refinement.
• Is it because stories are well written but because of the nature of the product or some features they are becoming complex or convoluted. This is common with things like technical tasks, technical debt, or non-functional requirements. In this case, differernt approaches may serve to better capture the value.
• Is it because the team is struggling to think about users, their problems, and the value of the solution. If this is the case, then a shift in thinking is called for. Changing the format of the backlog items could be a tool to help shift thinking - but it is important to be clear on what the change of format is meant to achieve.
• Is it because the team is just a little sick of user stories - so they need a change. User satories can become repetitive and stale. If so, alternative formats may serve that well.
• Is it because the team is relativly new to agile or otherwise struggling with other aspects of the approach. I've worked with teams that are wedded to other approach - long requirements documents, complex use case modelling, etc. Their desire not to use user stories was part of their resistence to change. I've had to pick which areas to focus for improvement - and enforcing a user story approach might not be the right starting point. So adopting a format that is transitional to move them from other approaches to requirements to a prioritised, value oriented backlog may be better.

As a final point, it's unlikely that one approach will be the right answer for any given product. The best teams I've worked with have used user stories extensively but not exclusively. Being willing to adopt different approaches for different backlog items is a healthy sign in a team.