wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes What's best:  use cases, user stories, or features? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "What Watch "What New topic
Author

What's best: use cases, user stories, or features?

Benjamin Weaver
Ranch Hand

Joined: Apr 08, 2003
Posts: 161
I will soon lead a small project in a university research environment. The project will be to put ancient manuscripts and their greek texts online in full-text searchable form. Use of the software will be public and free, and the users community will be very small--150-300 specialists in ancient Greek literature tops. The design team will consist of 3 people, all of whom, including me, are experts in the field and users of the software.

What do you think? in my case, are full use-cases necessary? or are use-cases still good because they model hierarchies?

Or, given the intimacy of our users, and of our development and design team(all 3 of us), should I chuck the formalities and do away with all but bare-bones Agile user stories or FDD features (action-result-object)?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Who decides what you should implement? If it's the three of you, then there's no question in my mind about going with user stories. All you need is a "shorthand" to what needs to get done--the rest of the details you can easily discuss when the story at hand becomes relevant. Otherwise, I'd like to hear more about your project environment but I have a hunch that something like user stories are quite likely a very good match for your needs.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You can write very simple to very formal use cases, it's up to you. See Intro to system use cases for examples of various levels of detail.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I've been using this line more and more at work. For every artifact fill in:

"_____ reads _____ to learn _____ so they can _____"

Then once you know who needs what, see if the artifact in the second blank is the very best way to communicate.

If you have an audience with a need for permanent documents use cases can be pretty neat.

We had some terrible experiences with use cases for estimating, assigning and tracking work because they were too big. If you're filling in the blanks with giving developers tasks to do, something smaller like stories would be better.

We often find a use case author puts in everything they can possibly think of from the mission critical features to the least necessary gold plating. This is largely because they think they only have one chance to get every last requirement into the doc before sign-off and the onset of change prevention, er, control.

If you break a use case into many stories the customer can usually identify some that you have to do first and some that you can put off forever. We never tell our customers "no" on a goofy story. We write it up and let them prioritize it for some time in the next century.

Many teams find that they don't need the permanent use case record. They can develop a story and throw away the card and go on to the next. My team won't give use cases up any time soon so I encourage the people who think they are important to write them and leave the developers to work with story cards.

Any of that help? Raise more questions?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Benjamin Weaver
Ranch Hand

Joined: Apr 08, 2003
Posts: 161
Thanks a lot all of you for the info. I might use user stories for the simpler functionality--our searching and querying. Then use cases for updates, online editing and saving of our manuscript documents, and other transactions requiring some kind of database or application level lock. Stan, I might give that blank-filled template a try. Looks useful.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
XP says a story card is a promise to have a conversation. If you work with stories and want to maintain use cases you can say the use case is the record of the conversation. That even works with heavy-weight RUP because writing the use case is a form of user interview and requirements discovery activity. Write it one story at a time.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
XP says a story card is a promise to have a conversation. If you work with stories and want to maintain use cases you can say the use case is the record of the conversation. That even works with heavy-weight RUP because writing the use case is a form of user interview and requirements discovery activity. Write it one story at a time.


Good advice.

In vanilla XP, the conversation is recorded in acceptance tests instead of a use case, which has a number of advantages: http://www.xprogramming.com/xpmag/expCardConversationConfirmation.htm


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
On my team the same information is often duplicated in

* Change request
* Use case
* Programming assignment
* Data change request
* Data change script
* Code
* Test script
* Release notice

More than a few of these are also formally reviewed and tracked for status. Makes me want to scream.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What's best: use cases, user stories, or features?