Agile - Use Cases, Scenarios and Stories

[jgwors]

Hi,
I'm transitioning a project that started off as waterfall to agile.

I'm seeking guidance on how best to represent stories in EA, especially with regard to visability in the generated HTML output. Further down the line I'll need to know how to get these grouped as a product backlog to go into sprints.

So far I've tried modelling stories as features and as scenarios within the use case. Features seem to be preferable as scenarios are hidden in the depths of the use case and aren't very visible in the HTML output. Anyone got any experience of doing this?

[AndyJ]

From my point of view, the structured scenarios are both very valuable and quite frustrating.

If it is visibility of the final product that is at issue, you could export them to rtf documents via the Structured Scenario template.

I take this the extra step and use the rtf as the source document for links within very structured (and corporate standard) word documents.

Visibility becomes more of an issue if you are trying to do requirements traceability down to the flow level in a Use Case (and I can see some value in doing that).

Andy

[neil_albiston]

We've used Use Cases for both real Use Cases and agile User Stories.
The stereotype User Stories can be used to distinguish them from the real use cases.

The extra fields from the stories ( Done, planning score, etc ) can be added as tagged values. The tag values need to be added to the RTF templates for them to appear in your documentation.

This keeps the visibility and you can also use the relationship matrix ( ( User stories to Classes/ Features or Requirements ) to keep a track on your sprints / product backlog.

If you create a package ( folder) for each sprint and place the user stories ( Use Cases ) within that package you will be able to report against individual sprints or the whole project.

[Peter Doomen]

First and foremost: user stories are a "promise to talk". "Agile" means that you keep as little documentation as possible (but not less than that). On the other hand, "agile" does not mean you don't do analysis: instead, you only do analysis when it's needed for delivering the increment of the product. User stories are one way of accomplishing that.

In short the relationship between user stories and use cases (I'll publish more on my website soon): a user story can be part of a use case, but ideally, it describes one or more paths from precondition to postcondition. A user story is a way of partitioning the work intended for organising and planning, while a use case is an analysis technique in the first place.

In Enterprise Architect, I would do the following:

• keep "use cases" as use cases, but avoid to analyse them in detail before needed in a sprint.
• document "user stories"  (stereotype "requirements") and connect them to the right use case. Avoid to overanalyse them, just put the "as a <role> I want to <feature> so that I can <goal>" in the name.
• Hook the user stories "requirements" to one of three "activity regions": TO DO, In Progress, Done. This can be your virtual taskboard.

This is more or less the same technique I also described in my book on Enterprise Architect. Works very well for me.