Why Spend Time on Use Cases in Agile Projects?

Someone at a recent conference asked me how to respond to project stakeholders when they say that Use Cases take too long in an agile environment.  I was presenting a talk on “BA Toolkit for an Agile Project (or any other for that matter).”  Here are my answers with some added depth. (Thanks to Justin Roebuck for the great question.)

1. How else are you going to specify the details needed to turn a user story into useful code? Relying on developers to do that without use cases has three huge flaws. Skipping use case development is:
   1. Inefficient. Eliciting requirements at the same time as writing code is another way of saying you will do multi-tasking. Several studies have shown that people are less efficient when trying to multi-task. (See a 2009 study done by Stanford University for a recent example.) Why would eliciting requirements and creating software be any different? Doing analysis, design, and coding during a sprint is inefficient unless your scope is really small.
   2. Inadequate. We need to get to the right level of detail to avoid rework and to provide software that the business wants and can actually use. To think we can consistently jump from user story to functioning code without use cases is wishful thinking. True, experienced agile developers might be able to work with experienced product owners, but getting to the necessary level of detail is hard for most organizations. Most developers and testers benefit from the consistency of use cases to ensure a successful end-product. For more on the need for an appropriate level of detail, please see Karl Weigers’ article on how detailed to make requirements: https://bit.ly/sw7pS5.
   3. Incomplete. It takes the type of questioning and digging that business analysts are good at to uncover complete requirements. Again, use cases and their complementary modeling techniques of prototyping, data modeling, and process modeling are standard ways to ensure requirements are complete.  If teams are trying to cover all of these during a sprint, then they are not spending adequate time designing, building, and testing software.  These should be done while grooming the product backlog.
2. How do you know when you are done? One of the key concepts of Agile is knowing what “done” means before starting the development. One aspect of “done” is the boundaries of the delivered software. By using the concept of pre- and post-conditions that are inherent to use cases, we have a built-in device mechanism for knowing what the boundaries are, and helping know when the user story is complete.
3. How do you know the acceptance criteria? This is the other component of “done.” People who work with Agile and Scrum are fond of talking about the importance of acceptance criteria. I don’t disagree. What they don’t often tell you is how they come up with them. Techniques like use cases are the premier way we have found for determining and then specifying acceptance criteria. There is no better way today in the software industry. Good criteria take time, and another suggestion to convince people to spend time developing use cases is to tell them you are developing “acceptance cases.” We use that term to describe the lowest level of a use case. Instead of converting a detailed use case to an acceptance test, we recommend instead that you develop a first-level “discovery level” use case, then go straight for the acceptance case. It will be faster because you don’t have to do any conversion.

I plan to turn this into an article and show some examples based on the presentation. Check back for more on this topic!

=========

To learn more:

• Read the two links mentioned in the post.
• See our other articles on use case and requirements in https://www.watermarklearning.com/articles.php.
• Get practical training in use cases. Check out our course outline for details.