Agile Business Coach

Hi Chris.

I think there is an underlying process difference that explains this. If you ask someone to come up with a use case then they are asked to think about failure scenarios and so that get dragged into multiple threads of execution. Developers are usually very good at following multiple strands of thought and backtracking (according to Sallyann), but not everybody else is. Faced with this level of detail people will retreat to concrete examples rather than goals. So in the tertiary theads you end up with something like...

"Must pop up a error page with the sales email address"

...rather than...

"Must be able to get help from a sales contact in the event of a problem with the minumum of fuss"

The former is stepping on the toes of the technical people. This is design up front disguised as requirements and gets worse if someone has to write a whole bunch of use cases in one go.

By writing a user story you are signalling that it is OK to go back to the details later. The problem then becomes how do you maintain the rigour of use cases when you move over to user stories?

yours, Marcus

I disagree with "An XP Story is a scenario. A Use Case is a collection of scenarios."
If you consider each scenario equates to a Customer Acceptance test, it is clear story may satisfy more that one. Also, you may chose to chop steps out of a scenario so an XP Story scenario is not the same as a Use Case secnario (usually a Use Case is framed as functionality required for the whole system to be delivered). The key differences between XP Stories and Use Cases is what you are using them for. Use Cases are analysis tools that help develop understanding of complete requirements. XP Stories are planning tools for incremental development of software.

I agree with Rachel. Use Cases, Scenarios, and User Stories are all different things. When you do use case analysis, you talk to the customer, trying to understand a user's point of view. And that's what you write down: your understanding of how the user uses the system. Sometime later, the developers make to-do lists from that understanding, and those to-do lists may be written down, or entirely mental.

A user story is like a high-level to-do list item. It's written in few words. Not too general, not too specific. It's sometimes called a "promise for conversation", and it's in that conversation that the use cases and scenarios are made clear. If you're talking to the customer frequently enough, you shouldn't have to write down use cases, and you can go into greater detail, to the story level.

A user story often covers the same territory as a use case or a scenario, which is the main cause for the confusion. But sometimes not... the main distinction is in their usage.

---

Hmm, now that I think about this post some more, one could interpret it to say "User Stories are to-do list items". But they're not quite that, either: a to-do list item is usually written to oneself, whereas a story is shared with a whole team. Actually, that's the only real difference I can think of at the moment; other differences are consequences of that. You write them on index cards and estimate them and associate them with acceptance tests because of that sharing.

XP Stories and Tasks :)

http://blog.targetprocess.com/2004/08/tasks-and-user-stories-in-xp.html

If I may be allowed the luxury of plugging my own book, readers of these postings might perhaps be interested in Scenarios, Stories, Use Cases (Alexander & Maiden, John Wiley 2004) -- see details and reviews at http://i.f.alexander.users.btopenworld.com/reviews/alexander_and_maiden.htm