If not user stories, then what?

Last post 05:59 pm May 21, 2013
by Randy Ho
4 replies
Author
Messages
01:51 am April 10, 2013

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?

11:26 am April 10, 2013

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.

08:20 am April 18, 2013

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 :)

09:20 am May 10, 2013

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?

05:59 pm May 21, 2013

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…