Googling around the web, the Agile Sages considers use cases and user stories are two different things:

• Mike Cohn: User stories aren’t use cases
• Alistair Cockburn: A user story is to a use case as a gazelle is to a gazebo
• Extreme Programming.org: User stories serve the same purpose as use cases but are not the same.

Use case driven approach was one of the hottest technique for requirement capturing and some people now consider it is a kind of outdated, old style technique that associated with a lot of problem that causing your team NOT “Agile” due to the problems of use case:

• Upfront requirement – trying to define the detail of all aspects of the upfront will result in lots of wasted effort and time as much of the work will need to be redone.
• Functional Decomposition: The functional nature of use cases naturally leads to the functional decomposition of a system in terms of concrete and abstract use cases that are related by extends and include use case associations.

If you search around the Web with keywords “use case vs user story” you will find a long list of articles suggest about the drawbacks, problems or pitfalls of the use case approach, while there is even longer list of the benefits related to user story. Interesting, things change so quickly in the IT industry, and even quicker for the people switching from the used to be “trendy” things in the past to the “newer trendy” things of now.

Interestingly, some people like to perceive things in a binary pattern and chasing for trendy stuff by associating with them symbolically rather than actually practicing it genuinely. Some people even don’t want to let other people know they are still using use cases, or they might be considered to be outdated and old styled.

Now some people put an equal sign related to user story and user case:

• Agile = user story or Agile = user story + Scrum
• User story = just-enough & just-in-time
• User story = meeting user expectation & satisfactory
• Use Case = Upfront Detailed requirement capturing
• Use case = <<include>> + <<extends>> = functional decomposition
• Use case is “user input” -> “system response” only style
• Use case = old style & outdated

As a tool vendor, we are pretty neutral in methods, tools and techniques. Personally, I want to stress clear that I am a big fans of Agile development, user story and scrum process. Particularly, the underlining principles and best practices related to concepts such as:

• Requirement discovery rather than requirement delivery
• Under the principle above that yields two important properties in Agile development process
  • Just-in-time
  • Just-enough

(I will write more posts related the principles above with my own opinions, that is closely related to my PhD research area in 1992-1995 – metamodel & schema transformations)

Now, let’s go back to the topics “use case vs user story”. Well the heavy weight Agile Sages already casted the vote for that, am I so stubborn trying to overturn their “votes by arguing they are similar or even the same?

Let’s me show you an example to illustrate whether user story is “so different” from user case:

Example

Good user stories are much more than just statements. A standard user story consists of three parts, commonly referred to as the three C’s.

The first “C” of each user story should follow the standardized format of:

As a [role], I want [to do something], so that [benefits]

which is the minimal content of a user story to be put into the card.

The Conversations is the contents of the second “C” of a user story which represent the discussion between the end-users, project owner and the development team. In these conversion, it records the verbal discussion, or many other useful information such as, emails, wireframes or any other related contents for project.

The final “C” of a user story is confirmation which is the acceptance criteria used to confirm that the user story is implemented corrected and successfully delivered.

Let me elaborate a little bit further on how to develop the confirmation part of a user story. In here we use the most well-known template called Gherkin which adopts the Given-When-Then formula to guide the writing of acceptance tests for a User Story:

• (Given.. and) some context
• (When.. and) some action is carried out
• (Then.. and) Perform some actions

Tools such as, Cucumber and Jbehave testing frameworks encourage use of the Given/When/Then template for conducting automated testing, though it can also be used purely as a heuristic irrespective of whether a tool to be used.

Let’s gather all the information for the “register course” user story and put it in the 3Cs format:

I adopted the commonly used 3 Cs format for representing the “register course” user story. Likewise, I also adopted the most widely used format for describing for the same “register course” use case elaborated by a use case description. I numbered the steps of the confirmation section (the last C) of the user story which is associated with the step number that I put in the use case description. They are the same “nine-step” of the scenario to be put in each of the approaches with different order. I believe both of the model representation is acceptable for their corresponding sages and followers. Then, the question again, is user story is very similar to user case and yet they are different or the order of the steps causing all sort of criticism for use case approach?

Semantically Equivalent with Different Meaning?

Let’s investigate whether there is similar case in the modeling domain, so that compare against the situation here, or it might help us to cast our own vote on “user story vs use cases”, but not either blindly follow the crowd or repeating what the sages said like a parrot talk.

Example: Semantically Equivalent

In UML we can describe a use case scenario with a sequence diagram, but we usually don’t use a collaboration diagram for the same purpose; even through both of the diagrams are semantically equivalent. In other words, both sequence diagram and collaboration diagram are having the same number of objects participating in a scenario with same number of messages passing around the same set of objects for performing a task of a scenario. However, the former one is time focus and the latter one is space focus. Sequence diagram is more intuitive when using it with scenario modeling, while collaboration diagram is appropriate for modeling structural relationship among objects. i.e. you want to represent the scenario of participated object structurally into MVC framework (model/view and control layers).

Personally, I don’t think using user story will make my team become agile, and use case will cause my team to be “upfront”. Most important is how we apply and use those tools with what kind of mindset and best practices behind. I am not too worry about people considering me to be “old style” or outdated when I actually act agile.

I still recall in the structured analysis and design days, perhaps we can use Abstract Data Type in ADA to apply the object oriented analysis and design principles without having the support of OOP in 198x, right?  Unfortunately, you might not even come across the concepts of the Abstract Data Type at all! Oh! My God I accidentally disclose – I am old? Or, I should think positive – experienced?

What do you think? What is your vote on this? Let me know or correct me if I am wrong.