I admit I am not a big fan of heavyweight methodologies which get in the way of delivering solutions. In all my years within the industry, I have never had a customer turn to me and say "Thanks for the mountain of documentation you provided, pity however, that the solution wasn't on time". 

I am firm believer that technology's role is to enable business to achieve on their goals, whatever that may be. This is one reason why Salesforce is so success: the products and platform are business enablers, not technical projects.

With that said, however, as I see more and more custom cloud implementations, the importance of a well-defined solution is critically important. Over the past few years, many companies have adopted agile methodologies like scrum, xp etc. to address the need to deliver custom solutions, without the requirement to spend months on design and documentation. But Agile methodologies have had it's share of criticism as well.

So how do we continue to get the level of requirements we need to deliver successfully without the mountain of paper? Agile methodologies promote User Stories which are great, but at times, they lack some structure. My preference is to leverage the idea of short user stories, but borrow from concepts from heavier methodologies like RUP.

Enter Agile Use Cases.

Traditional Uses Cases have been around for some time, but seen to have fallen out of favor recently. Perhaps they are still seen as part of the heavyweight approaches of the past —I don't know? I continue to sing their praise, albiet in a slightly modified version as a way to accurately, and quickly work collaboratively with a customer to define their solution. The great thing with agile use cases is that, when done well, are written in simple terms and concepts that everyone involved can understand, and use as a road map to success: business users can walk through the process, developers can decompose the activities into stories and tasks, and testing can derive test scripts and acceptance criteria.

To me, an Agile Use Case is nothing more than a structured User Story, typically 1 page in length with perhaps a supporting state diagram or wireframe. This type of use case works exceptionally well in conjunction with the Custom Cloud, and the Force.com platform, as by their nature, the Custom Cloud and Force.com platform allow you to focus more on solving business requirements, and less on the technology plumbing so to speak. The Agile Use Case doesn't need to concern itself with installation of servers, failover etc — so why should the business? With the Force.com platform, these requirements are taken care of.

So, enough of the discussion: what are some tangible steps to be successful using Agile Use Cases on the Force.com platform, and Salesforce. Here are my top 5 best practices:

1. Keep it simple. If a use case is less than 1-2 pages (even 2 pages is a stretch imo), then you probably need to decompose it into sub processes, and look for ways to use and extend other use cases. In addition, try and keep to less than 5 use cases when defining a solution. Too many use cases can be a sign that you haven't really nailed down those critical business cases. You can always add additional use cases later, but it is important to show quick successes and build upon it. Remember, success is best when proven, rather than planned.

2. Identify the pre and post conditions of each use case. You should be able to identify 2-4 bullets which describe the system state before and after the use case completes. Not only do these conditions help tease out additional requirements, they are also perfect candidates for test cases, and acceptance criteria

3. Write your uses cases in conversational pseudo code: simple language which describes what the actor is doing, and how the system should respond, with an emphasis on the logic involved. This step is the trickiest to master: How do you capture the business requirements, but put enough system-level logic that the developer can ascertain exactly what is needed to be built. It takes practice, but stick at it; in the end it is worth the results.

4. Identify the users, or in use case parlay, actors. Actors are the roles or profiles that need the functions contained within the use case to perform their job. You should avoid tying a use case to a specific named person, and rather, make it related to a role or profile. The benefit of role/profile based use cases is that it not only makes the use cases more susceptible to being candidates for extension, and inclusion into other use cases, but this best practice also assists in the identification of the roles/profiles required within your org.

5. Give the use case to the business users, and developers for a day or two to chew on them. While I am a fan of collaborative design sessions to flesh out all the requirements, many people think best when thinking about something completely unrelated; for me this is running —I can't tell you how many times a solution, or missing piece of functionality has jumped out at my while I have been pounding the pavement. Give your users/customers/team time to pound the pavement; the result is a well thought out process.

Next time you are looking at customizing Salesforce, or perhaps building out a Custom Cloud solution with the Force.com platform, try dusting off your old Use Case books, and following the steps above. You might be surprised how well this old favorite fits into the Salesforce.com, and Cloud Computing model. 

Finally, I will be at the Code Consultation sessions as part of the Developer Zone at Dreamforce over the next few days. I would love to see you there, and make sure you bring your Agile Use Cases with you!