For the initial "Phase 0" or "Release Planning" effort, we want to arrive at enough of a plan to give the business some idea as to the approximate schedule and cost for what the business wants built. Normally, we use this up-front planning time to iterate with the business on just what will constitute a good first product release. That is, the business might have some ideas for features that cost more than they are worth. Conversely, the development team might have an approach in mind that makes other business value attainable. The point is that I like to work at a "level up" from the intended product. To understand the business environment and drivers surrounding the specific project is invaluable. This often allows us to come up with spectacular game-changing solutions because we aren't simply boxed in with an a priori idea of product shape (which naturally was formed within a set context).

We also let the business know that it is an "early-stage" plan, that we will continuously update with each iteration. Progress will be very visible to all participants throughout, allowing for adjustments along the way.

Business Modeling

Software is designed to solve business problems. In the beginning of a project, I like to have a series of meetings with the business to flesh out the core requirements with subject matter experts, architects, and stakeholders in the room. It is often helpful to think about the problem by working backwards from the endpoint. Many times, there is a core set of requirements needed to meet minimal business worth for the stakeholders. That is, without these features, nothing else matters. For example, what requirements will an insurance agent have for the system to allow them to place more business and manage their customers? What aspects of the system are needed for the insurance company's Underwriters to manage the lines of business rules and profitability/risk ratios? Add to this the unique aspects that the sales portal could provide (for example, through providing agents with a sales funnel concepts maybe?). The goal is to arrive at the sort of information we need to have on hand to make such functionality possible. Arriving at the core features helps us when deriving estimates and setting priorities. Non-core, or "mice to have" features can be shuffled to later in the project, or to version 2 following successful product launch.

Underlying the requirements gathering process (outlined below), we use object-oriented techniques. The domain information is placed into "Classes" with names familiar to the business, and appropriate associations. I use simple sticky notes and a whiteboard to start.

A great deal of emphasis is placed on the business model for the simple fact that this is where you make or break most software systems. By keeping the business model reflecting what you do for a living, we are more able to adapt to new feature requests or to move with the industry as changes inevitably occur.

To tie yourself to industry data formats, or database-specific calls, or user interface aspects, is to potentially cause future harm to the company. The results of doing such designs are often applications that are not easy to upgrade, apps that are hard to maintain, unpredictable schedules, and blown maintenance deadlines. All because of allowing "technical debt" to creep into the system and build up over time, unchecked.

Therefore, we tirelessly labor over getting the business model "front and center" in the application development effort. From this perspective, most other aspects "hang" off of the domain nomenclature: features, bugs, enhancements, etc., all use the same terminology

One more thing. We don't model "everything under the sun." If there is no need to record agent hair color (for example), we won't model that characteristic. If, however, the analytic logic could make use of number of times an agent's application was "referred," we would endeavor to record that in the business model.

Requirements Elicitation

As part of the process to discover the business model, we simply ask about the overarching business goals and the user's requirements. We do this in a very iterative and agile style, making successive passes until we're satisfied that we know enough to make a reasonable estimate and plan of attack.

Over time, the domain model and features list and cost estimate gain more and more information. In the early part of the process, we make huge steps with every day spent. As the process draws to a close, you will see less and less value coming from the time spent together, and fewer significant contributions to the overall understanding of the information leading to the estimate. You'll realize it is time to stop planning, and time to kick off development.

For most of my projects, the time has followed what FDD often cites: 10% of the overall development schedule. Three months for a three-year project. Two weeks for a 6-month project. Your mileage may vary.

System Purpose

It is critical to have a basic idea about what the system's purpose is, and any concrete features that it must have. At the outset of the project, it is imperative that we have folks in the room who are subject matter experts and who know what the system is intended to do. The System Purpose can be (indeed, I would go so far as to say "should be") quite simple (Peter Coad recommends 25 words or less):

SYSTEM PURPOSE:

Acme Insurance needs to build a "modern" web application to permit agencies to sell Acme insurance to the agency's clients. (1) Sell more insurance, (2) Reduce cost of sales, (3) Improve company's street cred with a modern app.

Initial Requirements Gathering

You do not need to gather all of the requirements in the first go. That is, we do not need volumes of written requirements to start. We need to have enough information to make an initial stab at what the basic application needs to be, how we might architect it, and approximately what season it might be near completion (given a certain team size and make-up). Usually, the business wants a ballpark cost estimate, or wants to know what can be done for a specific budget.

NoteThe more accurate the estimate needs to be, the more work you need to do prior to giving an estimate. The Law of Diminishing Returns applies.

As we bore deeper into the domain features, we continue to add to the domain model and build up a simple list of features -- either as class methods or a simple text list to start. The wisdom comes in knowing what is important to capture, what details can be skipped until later, and what constitutes good enough for the first high-level pass. The "depth" is tempered by the up-front knowledge of how accurate and detailed the estimate needs to be. The depth is also controlled by a sense of risk of estimating. That is, if a feature sounds potentially complex and risky, we'll want to spend enough time to dig a bit deeper. Maybe go down to the next level of sub-features, so to speak, or break down what is turning out to be a "Feature Set."

Balance Tip We are always playing a balancing game. Do too much upfront, and it may be wasted effort. Do too little, and you may provide the business with a woefully inadequate estimate, or get a nasty surprise at the end when that missing feature appears.

At the outset, we just need a reasonable title for the feature, maybe a sentence or two of prose. Enough to make a reasonable hack at estimating the size. When the time comes to actually schedule and produce the feature, we get back together and talk it out in more detail – again, preferably with a subject matter expert leading the way. This will lead to a more accurate estimate as it will incorporate more project learning.

Part of the agile philosophy is to prefer individuals and interactions over documentation – especially since there is no such thing as a perfect specification anyway. And, to spend double or triple the time on writing more documentation will experience the law of diminishing returns in a dramatic fashion.

Once we get to a point of having the bulk of the initial features, we will ask for them to be prioritized -- though sometimes we have gathered that information along the way when it was obvious. By concentrating on the highest priority ("must-have") features first, we begin to deliver recognizable value almost immediately as we produce working software each day of each iteration (admittedly, a releasable product requires a bunch of features before real value is delivered).

Balance Tip How do we estimate accurately? You may not have the development team intact when doing Phase 0. You may not feel comfortable with the technology. You may not be sure of some of the requirements. You must balance knowing enough about the app's requirements yet not having all of the detail.

Typically, you have to rely on your "gut feel" and those of your trusted senior architect/developer types. If there are high risks, you may need to counter by:

• Doing some investigation to reduce the risk
• Add a multiplier/padding to the estimate to attempt to account for uncertainty
  

So one quick-pass technique I use is to ballpark the cost of developing the basic domain model components (classes, tables, etc.). Gather the list of features into a spreadsheet or convenient issue tracker (but this usually takes more time than a quick spreadsheet). Add a column for estimate in hours. Add a column for "risk factor" in case you need to multiply the estimate to account for uncertainty of general "gnarliness" of the requirement. If you have a feel for the major UI components above and beyond the feature list, throw them into the mix as well. Anything else you can think of... setting up automated processes, various environments, and so on. Balance the numbers with the gut feel folks have about the app; for example, "I think a team of six can have that implemented in 4 months."

Risk Leveling

The way I like to look at this initial period, is to consider what we are trying to accomplish. We need to provide an estimate and rough "shape" of the application to a certain level of "risk" to make the stakeholders happy. If estimates need to be very accurate, then you need to squeeze out medium and high risks. You might even need to do an initial project to build out and test some aspects of your architecture. If you need a moderately accurate estimate and you have worked in this kind of an app many times, then maybe you only need to squeeze out the high-risk areas. The point is that not all features on the list are the same, unless you make an effort to "level" out the uncertainty.

"Doing" Complements Theorizing

Part of being agile means we seek to understand enough about what we are trying to accomplish to help provide meaningful estimates. Instead of producing purely paper output and schedules made with only best guesses, we will strive to uncover enough detail about what it is we'll be building, and what complexities we may run into.

For example, there are some technical challenges facing us with:

• Should we build a porting scheme for the 3rd-party back-end system (Sphnx)? Or should we access it in real-time?
• What details can we find out about the web service rating engine?
  
• We might need to scope out the Java/Flex architecture (thin slice) to see "how it feels" (and costs to develop)
  

How do we do this? We intend to explore a bit of the solution space itself to get a better handle on what we are up against. Our gut instinct tells us that we will want to ensure efficient means of integrating with Sphnx, for example.

By way of analogy... Think of developing an application with 100 features being akin to carrying 100 pumpkins from Point A to B by foot, one at a time (maybe 300 years ago). We could do some theorizing about how long it will take by guessing on the distance, and guessing at how much ground we might cover in a typical day. However, if nobody has ever gone from A to B before, how accurate do you think we would be? However, if we actually try to take one pumpkin to get a more realistic feeling for the complexity involved, we will likely learn some valuable details along the way. For example, we would learn about rivers to ford, possibly forests with bears. We would learn about what sorts of unexpected deviations might occur that add unpredictable variability to the equation.

At any rate, I hope you get the picture. By practicing delivering some features, even if a bit shallow at first, we will gain valuable knowledge to help the team going forward. At a minimum, we need to have a handle on the technical approach to lend credence to our initial rough release plan estimates.

Expected Results

We want the "Requirements Workshop" to help produce

• A reasonable understanding of the major features needed for this application
• A pretty solid business model able to take us through initial release
• A realistic "feel" for the application's technical aspects
• Some possible solutions for the more technically challenging aspects of this app
• A "slice" of the requirements in visible form, in a working piece of software

We will also produce an initial release schedule/roadmap. This will consist of a simple list of features to be delivered in the initial release and possibly a set for one subsequent release (if we have convinced the business that some features can wait until after the initial release). We will also put a "size" and schedule around what Release #1 will require. Often, I will break down larger pieces of the puzzle for Release 1 by roughing out an Iteration Schedule of how certain larger (major) feature sets will roll out. But this is always done with extreme simplicity since we do not want to waste excessive effort on any long-term planning details.