User Stories or Use Cases?

There seems to be a bit of a backlash against the UML lately; XP-ers are saying that producing documentation or formal diagrams is not agile, and therefore not XP; the MS camp (which have never been big into UML anyway, possibly because they didn't create it) seem to be moving in a slightly different direction with their "Class Designer" feature in VS 2005, and have referred to UML as "elitest", i.e. too abstruse for the average dev or user.

So, with this in mind, if you're an avid practitioner of agile methodologies (or are using that old catch-all methodology, "RAD"), should you utilise Use Cases or actively avoid them?

XP advocates the use of "User Stories", which are written by the users themselves; they are a very short narrative describing a feature. The reason for this is that they don't require any knowledge of diagramming notation to produce, hence are extremely agile: they're just words, and so you don't need to provide the customer with training to produce them.

It's important to note that Use Case diagrams don't need to take the form of a diagram; they can also be written as a narrative (Martin Fowler prefers this approach). Personally, I think that the diagram variety of Use Case is useful at the beginning of a project, when you're trying to get a feel for what the system will do at a high level; you can show the diagram to a user and talk them through it, and use it to spur their imagination. When you come to implementation, however, you need to dive into specifics. This is where the stories would come in, or activity and sequence diagrams if you're so inclined. Basically, I see Use Cases and User Stories as complimentary tools.

XPers might consider UML to be non-agile; but is UML just a formal process that you have to follow slavishly, i.e. produce formal docs at different stages of a dev cycle? The answer is no; use what works when it makes sense to do so. Do you have to produce formal documentation? Possibly, but only if your project demands it. Otherwise, sketch your use cases on white boards, the backs of cigarette packets, and in throw-away electronic copies to achieve what you need.

Are Use Cases too difficult to understand? Is UML elitest? Use Cases get slammed from two different angles; those that say they're way too difficult to follow (from those who underestimate their user's ability, and those who have never drawn a Use Case), and from the other side there are those that say Use Cases are so easy they are irrelevant (from those tech-snobs that think a diagram with a stick man on it is more of a cartoon for children than a serious design tool). In my opinion, Use cases are pretty easy to put together (you're dealing with circles connected by arows) - it's trivial to produce these and trivial to understand them.

There seems to be a misconception that Use Cases should cover all aspects of a system, which isn't true - they should show the high level view of what the system does, in simple language. It's not a flow chart, and so it shouldn't show error conditions or logic in any way. This stuff belongs in activity diagrams (which are the closest thing UML has to a flowchart).

See also: User Story And Use Case Comparison