Requirements analysis in Scrum - Understanding the "as is" state
As a business analyst, one of the things I find more difficult on Scrum projects (working with user stories) than I used to on RUP projects (working with use cases) is understanding what the current ("as is") requirements for the system are.
As I'm not working on greenfields projects, this is a critical thing for me to be able to do. When working with use cases, it was straightforward - the use cases would be maintained as a versioned, living artefact over the years of the product's existence, and if I wanted to understand what the current requirements were for a particular feature (in order to change them) I'd go and read the use cases for that feature.
With user stories, this becomes a nightmare. I've found that trying to understand what a feature is currently supposed to do by diving through a dumpster of historical user stories (I think that's the right collective noun) is difficult, inaccurate and time-consuming. Every time I'm trying to piece together an incomplete jigsaw puzzle just to get an understanding of the baseline, in order to ask the right questions of stakeholders.
How do other Agile BAs deal with this problem? Are there other artefacts (over and above user stories) that people would recommend Scrum projects use to make BAs' jobs easier?
User Stories are primarily a way to manage work. They are not meant to be used as documentation. You could technically still use Use Cases alongside your User Stories for documentation purposes but I prefer to use automated acceptance tests resulting in living documentation (with a tool like Cucumber/Specflow) as much as possible.
> I've found that trying to understand what a feature is currently supposed to do by diving
> through a dumpster of historical user stories (I think that's the right collective noun) is
> difficult, inaccurate and time-consuming.
A user story is a placeholder for a conversation about a possible requirement. Those conversations occur during agile development. Once the Definition of Done has been met and an increment delivered, the relevant stories ought to be retired, as the conversations for that work have then finished. New or revised work would constitute new stories on the Product Backlog, reflecting the new conversations that will need to be held when developing the next increment.
Scrum is agnostic about how Product Backlog Items are expressed. User stories are merely a convention, although they are a good one because they encourage the feature-complete delivery of small pieces of work. There's nothing to stop you from adopting Use Cases instead if that's a better fit, although I'd be concerned about the level of granularity being too high, and too much work-in-progress accumulating.
User stories can be delivered as documentation, or used as the basis for such documentation, with each increment. If this documentation is required then it may be stipulated as a criterion in the Definition of Done. Alternatively, as Bart has suggested, you may prefer to value living documentation. A BDD approach using Cucumber or SpecFlow is especially useful because they are executable requirements specifications and are traceable to code.