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.