Otis 
Many experts in the agile community will tell you to walk away from use cases and to never look back. Learn to write user stories, is and was the solution to the problem.
One very important aspect is missing however. There are many analysts out there that are experts in defining functional requirements through use cases. And since user stories are in fact a representation of the functionality that the system must render, why not look for areas where the two can complement each other.
A few years ago I worked for a company that was in the process of moving from traditional methods to agile methods. They wrote requirements using two different styles, and now had to look for ways to do so the agile fashion. Here is an example of how I solved the use case/user story dilemma back then.
Let’s take a simple example. Assume that the business need is: Providing a System Administrator the ability to configure system lock out settings.
Business analysts in that company were writing the functional requirements in two different ways as alluded to earlier:
* Analyst 1 (using shall statements): “The System administrator shall be able to specify the number of unsuccessful log on attempts before the system locks the user account”
* Analyst 2 (using use cases): “Specify the number of unsuccessful logon attempts”
In the subsequent use case narratives ( use case scenarios), Analyst 2 would specify in great detail the dialog that would take place between the actor and system.
Nothing is wrong with the two approaches in essence. You would certainly understand what the real requirement was when reading the two statements. Analyst 2 however, unwittingly, wanders into design while detailing the interaction between actor and system. And that is exactly where use case writers will get into contention with agile practitioners. Some of my agile coaches in the past argued that use cases should not be used at all. I disagree respectfully. As use cases and user stories are in essence a verbalization of the requirements from the point of view of the actor or user, I argued and proved that they can be used to populate an agile product backlog. In the example I just provided, I recommended my client (and they really wanted to move to agile methods), to write atomic use cases, but to refrain from detailing the interaction between the actor and the system. That is the caveat.
It effectively means, just stick with the “title of the use case”. But write the use case title properly, so that the goal to be achieved is clear, unambiguous and testable (I will spare you further details here).
An atomic use case such as “Specify the number of unsuccessful logon attempts” can easily be converted into a user story if need be.
The user story could look like:
‘As a System Administrator, I want to be able to “Specify the number of unsuccessful logon attempts” before the system locks the user account, so that I can minimize the risk of unauthorized access ‘.
A functional requirement with an identifiable actor can easily be transformed into a use case, or a user story. There is a close relationship between traditional requirements, use cases and user stories. The transition to user stories can easily be mastered with minimal training.
Where you would run into trouble, is when you need to document requirements that don’t have a user interface component, such as low level architectural requirements and some non-functional requirements.
So to conclude, place only the descriptive title of the use case in your product backlog. Don’t put the dialog between actor and system in the product backlog. If you have a backlog with say 500 one-line use cases (or user stories), that would already be a nightmare to manage.
Cheers!
