We’re in Orlando for a working session as part of the Core Team building BABOK V3 and over dinner this evening we got to discussing the relationship between user stories and use cases (it wasn't the only thing we discussed, we are also a social group ;-)).
We noted with concern that there have been a number of recent discussions (client, articles, blogs and general industry) of using both User Stories and Use Cases at the same time in Agile projects. This seems to us (with general agreement around the table) to be both a waste of effort and actively against the Agile philosophy of doing the simplest thing that will work and deferring the detail until just ahead of when the component of the product will be built.
We would like to outline the basic differences, considerations and risks of using this approach. Even it is seems to be a trending topic, we would like to fill the gap in addressing beyond the trend and move towards the practically and risks of using Use Cases on Agile projects.
“What we have here is failure to communicate.” This is the catchphrase of a once very popular movie. And while the theme of this movie has nothing to do with the corporate business world, its meaning most certainly does. But first, a disclaimer. I do not consider myself to be a practitioner of business analysis or requirements management. Nor do I see myself as a leading expert on the subject. There are many knowledgeable subject-matter experts who, on a regular basis, enlighten the unenlightened with their knowledge, technical insights, instructive books and articles. I consider myself to be an avid consumer of this information. And in my current and previous responsibilities as director of a number of Business Analysis Center of Excellence (CoE) areas, I struggle on a daily basis with how to promote greater awareness of this critical practice, its value and communicating the work effectively.
Very few projects and project management teams have the luxury of gathering requirements that stay just as they are, and do not evolve or change throughout the life of the development.
This process of requirements management and development has evolved in recent years, as cost and technology barriers to requirements management software have broken down. Conventional approaches, including that of manual (human) management and good old ‘pen and paper’ are now viewed as restrictive and limiting - as businesses demand more innovation, outsourcing, product roll out, cloud computing and increasingly intelligent technologies than ever before.
Since many projects that require complex requirements engineering and management fail as a result of uncontrolled scope creep and poor (or lack of) understanding of stakeholder requirements, development organisations now use a different method of requirement management. Requirement Management tools are now advanced to such a point that the process is automated.