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)?
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.
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
Joined: Apr 08, 2003
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.
Joined: Jan 29, 2003
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.
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.
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
Joined: Jan 29, 2003
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.