Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

If not user stories, then what?
Last Post 21 May 2013 04:59 PM by Randy Ho. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Randy Ho
New Member
New Member
Posts:47
Randy Ho

--
10 Apr 2013 12:51 AM
    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?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    10 Apr 2013 10:26 AM
    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.
    Christiaan Verwijs
    New Member
    New Member
    Posts:5
    Christiaan Verwijs

    --
    18 Apr 2013 07:20 AM
    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 :)
    Chee-Hong Hsia
    New Member
    New Member
    Posts:71
    Chee-Hong Hsia

    --
    10 May 2013 08:20 AM
    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?
    Randy Ho
    New Member
    New Member
    Posts:47
    Randy Ho

    --
    21 May 2013 04:59 PM
    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-...0321205685
    You are not authorized to post a reply.


    Feedback