I've just read through the page(s) on UserStory and am hoping you can help resolve some of my confusion.....?
J.Stephen M., with the following questions (Thanks for any light you can shed this way (Use high wattage for best results...):
I see how a UserStory can be hierarchical in many ways (risk, priority, etc.), but where is there a process for aggregating stories that are similar? (Or do we assume that the client has a consistent, organized story to begin with?) I suspect that this is the hierarchicality (new word?) that Alistair was talking about...maybe?
(ies) are not hierarchical. They just are
are hierarchical. That's one of the differences. "Aggregating stories that are similar" is an odd phrase. Wouldn't one "coalesce or separate stories that are similar", removing the redundancy, or "aggregate stories that form a larger story"? The former is a process step that should be done in all cases, as part of thinking about the requirements. The latter is part of the UseCase
theory (but not UserStory
doesn't have a theory, actually, UserStory
says, "Tell me story."
Also, how can the UserStory be both simpler and heavier that Use Cases? Like Peter, I'm trying to reconcile the RationalUnifiedProcess and ExtremeProgramming and half a dozen other processes/methodologies/rubrics. Is it possible that the iterative nature of RUP (going from creating a business model to testing for each "phase" (inception, collaboration, construction? and deployment?) adds the elements of testing (possibly prototyping at the beginning) that seem to be missing from a Use Case? I'm thinking that the UserStory is, possibly the Uberthingie..(pick a name) for this whole process?
can't be simpler and heavier, IMHO, that's a goof. They are simpler and lighter. "Tell me a story. (I'll write it down)." Can't get much simpler and lighter than that (and that's the idea).
I feel sorry for anyone merging methodologies. I've watched a number of people do that, and they usually end up with a heavy, unusable mess containing the kitchen sink. I recall several teams telling me in the early 90s how they were taking the merge of Booch, Rumbaugh and Shlaer-Mellor (cringe).
I don't think you can reconcile RUP and XP. I do think you can do XP. I also think you can do RUP and also do automatic regression tests and short increments and sitting-in-one-room and user-on-board and even pair programming. Except just be sure to call that "RUP and a number of good practices".
can't be an Uberthingie, because it's, well, a user...story. You still have team structure and schedule and final requirements and designing and programming and testing and migration and deployment and training to settle. UseCases
the same. A UseCase
does not contain any testing or design. It contains only the behavioral part of the requirements.
Some people make UseCase
an Uberthingie because it holds together the conversations the team needs to have. UserStories
can function in the same way.
Those are all the light bulbs I have here in my room. -- AlistairCockburn
Alistair is right on IMO. UserStory
is a slimmed-down UseCase
far as I can tell. The point: show what to do, and be tangible. --RonJeffries
Hmmm.. still absorbing the luminescence from some of these replies...but, at
the risk of stepping outside the rainbow, maybe I should have used the
word "Organized" instead of hierarchical...although...If the UserStories
organized by risk and priority and...what was it? time to complete?,, then
there is some organizational structure to them, but not one that seems to
combine, coalesce, group, UserStories
that are similar, abstracting up a bit
until you get the most global, and most important, key UserStories
; as in Use
As to the oddity of my phrases, you'll have to consider the source.
And yes, I have a kitchen sink, and it is getting clogged. Could I have an Uberthingie stuck in there?
Thanks for your help.
J. Stephen M.
I think that XP is already compatible with RUP. If you strip away all the optional parts of RUP, you get a very simple set of constraints that XP does not violate. So, IMHO, XP is an extremely simple form of RUP. It would be fair, IMHO, to do XP and say you were doing RUP. -- RobertCecilMartin
Am I right in thinking that one difference between UserStories
in XP and UseCases
in RUP is scope?
I am no expert on RUP but aren't UseCases
requirements which apply to a release (a release being made up of several iterations), which allows some scenarios of a use case to be partially implemented in one iteration and the remaining scenarios in another. Contrasted with XP where UserStories
are requirements implemented in a single iteration and not partially implemented across iterations.
are preserved as documentation in RUP but in XP UserStories
may be thrown away once a release is accepted by a customer, and we just keep the AcceptanceTest
s not the cards.
Because a Use Case is supposed to model a complete interaction between a user and the system, the scope of a UserStory
tends to be smaller
than that of a UseCase
(Rational's description at
is useful here.)
User stories describe system behavior in context, which often means they talk about specific features or actions not entire interactions. For instance, "The System should offer a choice between email, hardcopy, and web browser reports."
That's not a Use Case, but it is a legitimate User Story.
It could, however, be part of a Use Case in which the user asks for a report, specifies its contents, chooses the delivery form, previews the results, and confirms the action.
A user story could certainly have the same
scope as a use case.
Although I can imagine a user presenting a story that spans the scope of several use cases, I would expect developers to usually want to see such a story broken down further:
it's hard to see how it would ever be appropriate for the scope of a user story to be larger
than a use case, but I haven't thought about this a lot.
I think that in practice, a RUP use case would map most directly to one or more XP acceptance tests, whereas a user story would usually be demonstrated by one or more unit tests. [Does this sound right? Kent? Ron? Others?]
Note that I'm talking about scope
here. This is a different issue than weightiness
as discussed in UserStory
I believe AcceptanceTest
s rather than UnitTest
s would be used to check that an XP story implementation satifies a customer.
Although a suite of automated unit tests are an essential part of an XP project, a unit test tests a part of a software application (such as a class)from the inside rather than the whole application from the outside.
I've decided to reopen this old can of worms. I want to play a game where we move from some UseCase
s to some UserStory
s and even further to some EngineeringTask
s. The page for this game is at UseCaseToUserTask
. Thanks -- DanRawsthorne
Why do engineers and designers always have to complicate everything? I think people get too wrapped up around syntax; maybe so they can sell books or maybe so they can make there mark for their "15 minutes" of fame. User story vs. use case, I don't see the difference or the need for new terminology. I remember 10 years ago reading in academic literature that use cases should NEVER be used for requirements determination. Within 5 years, the importance of use cases in business analysis and requirements enginerring had been promoted to the importance of sliced bread. You can split hairs but at the end of the day it's about understanding the needs of the client. Use cases can be just as effective as user stories because they're the same. It all depends on who writes them. Whatever you call it, it's just another tool that can be used if properly applied. If all you have is a hammer and a butter knife with no imagination, then good luck! --MQ