Saturday, July 12, 2008

User Stories vs. Use Cases

I am consulting on a large government project, where we are using Agile/Scrum. Lately we have been having passionate discussions around whether or not User Stories are enough for capturing requirements for large projects. My answer is yes User Stories are good enough for capturing requirements for any size projects. However, the product owners on the project are of the opinion that User Stories need to be complemented with Use Cases. We couldn't come to an agreement and the discussions continue. I recently came across Jeff Anderson's blog that exactly captures the questions/concerns that my co-workers on the project have raised. So, I thought let me share my view that I already did with my co-workers.

User Stories do not provide context. The way to add context to user stories and linkage among them is by associating stories with themes/tags. We could either associate a story with a single theme or multiple themes. For example, say a story is - "I as an Admin can approve registration requests." We could associate this story with "admin," and "registration." Additionally, we could associate the story with "architecture." Maybe this is the first story to address how we would implement admin module as well as security roles. So, it is architecturally significant. Later we could filter all stories that are architecturally significant. The themes can also be organized in an hierarchical fashion. However, I would argue that the same thing can be accomplished without explicitly creating this hierarchy. This will make life much simpler and provide greater flexibility in organizing and viewing requirements.

User Stories do not capture appropriate level of abstraction. I agree that the implementable stories might not be suitable for tracking and reporting to sponsors and management. However, if we think about how stories naturally evolve, then we would realize that most stories start at an epic level. Then over time, we break the epic stories down until we find implementable stories. The epic stories should provide the abstraction that we are looking for. We could report to the stakeholders/management on progress at the level that we feel appropriate. Of course, we would need a good tool support to help us with tracking and managing the relationships among stories. Watch for ScrumPad to provide this capabilities soon. However, we could also do this using plain old Excel.

User Stories do not capture enough details. Well, we could capture any and all information related to a story that we could in a Use Case. The amount and level of details that we should capture depends on many factors. The trick is though the way to put the details and being able to understand when is too much or too little. This is more art than science and depends on individual experiences and preferences. However, the intention should be to make a story card a starting point for conversation and collaboration between developers and product owner. I see a tendency among product owners coming from Use Case background to put in a lot of details as an alternative to conversation. The fallacy in that is the details are known, understood and can be unambiguously communicated in written format. We all know how that works.

However, on our project we are mapping stories to Use Cases where we need to interact with an external team that is not familiar with User Stories. In general, User Stories can be used to manage requirements for any size project.


  1. Hi Sayed.

    I agree with you that user stories do not capture the necessary level of detail. In a perfect Agile world, they will not. They do however, leave plenty of room for having in depth discussions with the customer (or proxy) at the time the story is implemented. This is textbook however and may not "fit" all scenarios, but the original intent of stories is to provide a context for conversation between the team and the customer.

    I also find the parallel between use cases and user stories you present very well though out. Just as in an UP world, one would root out the architecturally significant use cases, you point out the need as an Architect to do the same with user stories.

    -Tim E.

  2. Sayed,

    great post, and you raise some excellent points on how user stories can actually provide context by using epics and themes.

    The problem with epics and themes, is that if we follow the letter of what a user story is, there are really only two levels epics & themes >user stories, while a use case hierarchy allows me to go up and down multiple levels.

    Of course there is nothing preventing a team from creating "super epics", and in effect getting the same type of the fact of the used entirety.

    A lot of the concerns around detail with user stories can also be addressed when specific acceptance criteria/test cases have been applied to the user story.

    The main point on my original post, was not that user stories couldn't provide value, but really that if you dress up a user story enough it actually looks a lot like a use case. In fact I find the difference to be so little that I can to go with whatever the client is more comfortable with.

    For example the following user story

    as a student,
    I can purchase books from the university website,
    so that I can complete my enrollment into a specific University program
    done when:
    I'm able to select a book from the online inventory and add it to my shopping cart
    I'm able to check out the shopping cart and receive a total equivalent to the total amount of the book (s)
    I'm able to associate a specific book purchase with a particular program that I am already enrolled in

    Would map cleanly to the following use case

    use case name: purchase books
    use case actor: student
    1) this use case starts after uc: browse for books has completed
    2) the student adds one or more books to the shopping cart
    3)after each book is added to the shopping cart, the system updates the student shopping cart, displaying updated shopping cart information
    4) when the student is finished, the student checks out his shopping cart
    5) the student associates his purchases with a particular program and course

    I think you get the idea. On my latest project I'm tending to start with a use case hierarchy that doesn't go into any more detail than the above, and then I'm decomposing my use cases into particular user stories with particular test cases.

    The single point of truth usually ends up being the user stories, as it's hard to keep the use cases up to date but using things like fitness and media wiki help a lot...

    I still like use cases at the start, as it helps me with sequencing and order. And I can hang other artifacts like service-level agreements right on a particular node of the hierarchy.

    The real issue here is whether
    1) you are letting user behavior and customer value drivetime you actually gather the requirements
    2) and that you don't spend too much time creating and maintaining these requirements
    3) and finally you don't build all these requirements and super detail up front.

    In my mind, as long as you are following the above three points and you are going agile