Posted by: Craig Harding | September 1, 2009

What’s old is new again – Use Cases

What’s old is new again – Use Cases?

When I first started working on AGILE projects, I was unfamiliar with the term “use case”. I wasn’t sure if it was a new buzz word or a new technique for gathering requirements specific to AGILE style projects. As it turns out, I had been using them all along.

A use case is simply a way of describing a business task or action that takes part with in a system, process or application. Use cases should not be confused with the features of the system under consideration. A use case may be related to one or more features, and a feature may be related to one or more use cases. There are two kinds of use cases (Business and System), but for this posting I will only focus on the Business Use Case.

A Business Use Case is described in technology-free terminology, which treats the business process as a black box and describes the business process that is used by its business users (people or systems external to the business) to achieve their goals (e.g., manual payment processing, expense report approval, register a customer). The business use case will describe a process that provides value to the business user, and it describes what the process does.

About 15 years ago, I attended a training session presented by Trond Frantzen on Rapid Business Systems Analysis. In his methodology, he uses techniques for defining all of the “Events” of a business process or application in a very fast and concise manner. These events are essentially use cases. I have used this methodology successfully on many projects since that time and am now applying it when defining functional requirements (uses cases) in AGILE projects. Mr. Frantzen has now updated his publication to show how it can be applied within the AGILE framework. I would recommend reading his latest book Rapid ‘Agile’ Business Systems Analysis.

This methodology guides you through an event modeling process using JAD (Joint Application Development) sessions to develop ERD’s (Entity Relationship Diagrams), detailed Entity Data Dictionaries for logical database creation, as well as full narratives of the event as described by the business users. By populating entity relationship tables, you quickly identify all relationships in the process, as well as specific questions that need to be answered by the business. I have found that this process quickly provides the project team with a detailed functional business requirement in narrative and model form with all relationships between entities identified and specific data requirements documented. It is a quick and precise way of gathering detailed business requirements in use case or events form.

Whether you call them events, use cases, or detailed functional requirements, the end goal is the same. There are many effective and efficient ways of gathering this information. What are some of the methods or tactics you have used?





  1. Thank-you for the great information Craig. It’s a little over my head given that I am a beginner project manager, but thanks to blogs like yours I’m coming up to speed fairly quickly. I’m trying to jump directly into the agile methodologies from the beginning and skip some of the old-school waterfall methodologies. Have you had any experience with burn down charts? What is you take on them vs. tracking progress in a Gantt chart? Thanks!

    • Hey John;

      Glad you are enjoying the blog. It won’t be long before these terms and descriptions become part of your everyday life as a PM. With regards to burn down charts versus Gantts; I think they are both very useful depending on who your audience is.

      An updated burn down helps facilitate communication among team members and it keeps the team focused on delivering business value. It gives a clear picture of how the sprint is doing compared to the ideal burn down, if you are keeping it up to date on a regular basis. It is also useful when reporting progress at a high level to stakeholders. However, I do find that it lacks some very important information for me as a project manager, and that is when I turn to the Gantt.

      When you combine the planned (baseline) and actual Gantts on one chart you get much more detail that can help you as project manager to decide the course of action that may be required. From the Gantt you not only see how the schedule is progressing compared to the planned, but you can also see what tasks are on the critical path and which future tasks may be impacted based on the sequencing relationships you have created. You can determine what slack time you may have on tasks that will allow you to assigns tasks to different resources, assign more resources, or try to start tasks in parallel. This detailed information for scheduling is just not available in the burn down chart.

      I hope this answers some of your questions. Feel free to drop me an email directly and I may be able to provide some detailed samples.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: