Terje Sandstrom

------ Visual Studio ALM MVP ----- (also see new blog at http://hermit.no)

  Home  |   Contact  |   Syndication    |   Login
  64 Posts | 1 Stories | 116 Comments | 0 Trackbacks



Delicious Save this on Delicious Visual Studio Feeds


Tag Cloud


Company stuff

Interesting bloggers

Interesting companies


Microsoft Norge

Microsoft Regional Directors

Microsoft Test

MSFT Blogs



Other interesting stuff


Visual Studio

All these three terms are used to describe the behavior of an application.  They come from different process methodologies, and have different meanings, characteristics and are intended to be used differently.

Larry Guger also discuss these aspects and several others in his blog entries http://continuouslyintegrating.blogspot.com/2009/07/use-cases-and-visual-studio-2010-part-1.html and http://continuouslyintegrating.blogspot.com/2009/07/beginning-use-cases-identifying-actors.html.  

The Use Case is the term used in UML and in the different Unified Process based methodologies.  See http://en.wikipedia.org/wiki/Use_case for a good overall description.  A use case is often looked upon as a more formal way of describing behavior, and which has to be accompanied by a detailed description following certain rules.  However, a Use case can in fact be as light weight or as formal as one wants it to be.  I find that this depends more on the process methodology one uses more than characteristics of the use case itself.

The User Story comes from the Scrum based processes, and is meant as a short concise way of capturing a users need for a certain behavior.  See http://en.wikipedia.org/wiki/User_story for a useful description.

Scenarios comes as two different meanings, one is as a separate term used in agile modeling, see http://en.wikipedia.org/wiki/Scenario_(computing) for a description.  It is very equal to a User Story, but I tend to see it as a more general term.  The other meaning is as a certain path of actions for a use case.  One talks of a "happy path" scenario, or an alternate scenario. 

One can argue that a User Story can be converted into a Use Case, and there is a point in this.  A Use Case is meant to describe an application behavior, whereas a User Story is used more freely to catch behavior "as is" from the product owner.   This may lead to the case where multiple User Stories matches up to one Use Case, possibly as an Use Case with multiple scenarios, each scenario matching a User Story. 

In the TFS 2010 these terms are used at different places in the suite.  In the architect diagrams one can draw up a Use Case diagram, and in the Work Item store you can create User Stories.  You can even create a User Story item from the Use Case artifact in the Use Case diagram.  So these items can be related in TFS 2010.  However, since they are not coming from the same methodologies, the mixing of these can be confusing.  

I’m very pragmatic (even if I’m a theoretical guy), and I’ve noticed people have problems with these terms.  I often just say that it’s more important to catch the behavior aspect of the requirements, regardless of whether you call it Use Case, User Story or Scenario.  Scott Ambler has an interesting article on Agile Maturity (http://www.ibm.com/developerworks/blogs/page/ambler?entry=apmm_overview).  I’ve noticed the same thing, that dependent upon the maturity of the product owners, the developers (really all involved), one uses the process differently.  Also, dependent upon the size of the project, the maturity of the organization, the clarity of what is to be developed, and who’s the client and how is the contract specified, the need for formalized specifications vary based on these factors.   A use case specification is more formal, than a set of user stories.  Although as you so nicely shows, use stories can be converted into use cases.  I fully agree.  But I feel there is a one-to-many relationship between use case and user story.  And then I’m not quite sure if I want that within the TFS's work item system. It just becomes too much.

I tend to take a pragmatic approach to things like this, and just say that you could argue that these terms are "equal enough" to be used interchangeably.  In a real setting I would tend to try to catch as much as possible from a client (product owner) in terms of user stories, and during analysis convert these to Use Cases.  After having made my set of use cases, and made sure I had captured enough to start working with code, I would convert these into work items to start the show.  In order to make the terms less confusing, I would rename the User Story work item types into Use Case work item types.  No other changes really required.  And then I would simply use the actual User Stories as yellow notes in a customer meetings.

It is said that a Use Case need a more thorough specification, detailing the action steps it should take.  One thing I’ve started to recognize is that a set of test cases is very similar to a set of use case action steps, and should never be less than these steps.  So, to save on work to be done, one could simply skip the action steps, and just use the test cases with their steps as the specification.  It might be that the Microsoft guys have been thinking in this route when they connected the User Story so directly with the Test Cases.  It makes sense, and gives a leaner specification.  But, it makes the User Story look even more like a Use Case.

posted on Wednesday, July 8, 2009 7:07 AM


# re: Use Cases, User Stories and Scenarios - what are they - and how do they relate to TFS 2010 7/9/2009 2:55 PM Thomas Eyde
Domain Driven Design came to life as a reaction to the mistakes we make when we map business concepts to our technical concepts. When our product owner talks about Customers, we better use that name in our code. And when he says any Customer can have up to two Contacts, we better design our Customer with two Contacts, even if we use a List<T> and one-to-many relations in our database.

The point of all this is no mapping.

So when you are speaking of User Stories with your customers, we should also speak of User Stories internally. That means one less mapping to do.

Also, it will be interesting to see the improvements done to the TFS 2010 integration with Visual Studio. To be honest, the current integration leaves a lot to desire.

A story card approach like Zen would be nice :-)

See: http://agilezen.com

# re: Use Cases, User Stories and Scenarios - what are they - and how do they relate to TFS 2010 11/28/2009 6:13 AM John F Kidd
TFS 2010 allows us to group user stories against a use case. I think that a user story, perhaps using the BDD syntax (As a, I want, So that) replaces the need for scenario work items. For example, we may get several user stories telling us how the various actors would like to create a customer. We can then model a use case named "create customer" and using TFS we can link the user story work items against this use case. We can then link in developer tasks and test cases. Basically, we end up with a model of our system but maintain an agile approach.

Post A Comment