Our organization decided officially to employ Use Cases for all ‘Agile’ projects about a year ago. I’d been advocating the practice for the past two and half years, but historically we did requirements one way:
The system shall …
Since our adoption of use cases on Agile projects we’ve seen rapid adoption of the technique among everyone but the business analysts. On two of the Agile projects they’ve been forced to use use cases, but on all the others they’ve effectively balked or let someone else take on the business analyst role. So only about 20% of the business analysts have ever written a use case for a project. They have all been trained in at least a two day intensive course on how to write use cases. Instead:
- A developer wrote the use cases on one project.
- On another a developer/product owner wrote the use cases.
- On two projects PMs took over the use cases.
The transition to a newer technique for gathering requirements would seem to be easy in most organizations. Use cases are demonstrably better for defining functional requirements that a lot of ‘system shalls.’ In prior professional services projects I introduced them to our whole consulting firm, and several large government clients, who saw the value and adopted them wholeheartedly, though in many of these cases they had no dedicated business analyst organization.
My assumption is that the business analysts are balking at change. From my standpoint writing up “system shall” documents would quickly drive me nuts and anything from use cases to user stories would appear to be a nice change of pace. I’m still not sure how to help convince them that there are better ways to document requirements.
In the near future I’d like to experiment with user stories, but I fear leaving the business analyst group even further behind.