Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Benjamin Weaver
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Scott Ambler
author
Ranch Hand
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Benjamin Weaver
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic