How to estimate change requests in requirements

First and foremost, your estimation "measuring stick" should match your situation and draw on your experience. Estimating techniques range from simple to complex, so keep your estimation process as simple as you can without introducing undue risk. (Other estimating techniques include function points, use case points and user story points, among others.) You can introduce risk if your estimation process is too simplistic, but you have created a bad situation if you choose a laborious estimation process that takes more time to complete than it does to make the requested change.

It is important to realize that estimation is not an activity in absolutes -- your estimates are relative (this change will take more time to implement than this other change) and can improve over time if you learn from your continuing experience. Do you know what makes implementing a particular type of change take more effort than another type of change? If you do, that is a start. Start with your "gut feel" because it is probably based on your experience, but the next step is to determine why one change feels "bigger" than another.

Let me give you a non-IT example to illustrate how you can distinguish a BIG EFFORT from a SMALL EFFORT. In this scenario, you have invited some guests for dinner. One of the guests has a friend visiting and asks if it is OK to bring a friend. So, "Is it OK to bring a friend?" is the requested change. As the chart below illustrates, the impact on the two situations (formal dinner versus buffet) identified is quite different -- just like which module a change is to be applied to can make a huge difference in the amount of effort. (Click the picture for a larger image.)

In your situation, just like the situation above, you need to evaluate the effort it will take to make a requested change. There will be areas that you need to consider when determining your estimate. Start with what you know, but see if any of the following areas apply:

• Screen
• Module
• Interface/Integration
• Database
• Documentation
• Dependency
• Production
• Test
• Deployment

As you look at each applicable area, an inventory -- of screens, modules, interfaces/integrations, database tables, documentation and so forth -- will emerge, but it is also important to note the characteristics of a small/medium/large effort that are applicable across an inventory of screens, modules, etc. Some possible characteristics to consider are:

• Existing…new
• Modify…add
• One change in one place…multiple changes in multiple places
• Simple…complex
• Immediate deployment…wait for next release

Also realize that characteristics:

• Help you remember...help you estimate
• May relate to effort needed or calendar time needed.

(Document the differentiating characteristics from your current experience, but you get to modify this as you learn more.)

The Change Request Estimate-ActualTemplate below includes estimate and actual for effort and comments. As you will see in a moment, you can use this template to record your estimate-actual information for each change request you work. (Click the picture for a larger image.)

Now that you have a starting point, you can begin improving your estimates. Use your inventory and your "gut hunch" about the effort needed in each of the areas you have identified as important to determine your ability to provide an estimate. Here are a couple of hints:

• Determine the smallest unit of time that you will estimate a task (1 hour, 1 day, etc.). It is OK if, for example, you overestimate because there is some aspect that you have probably not thought about at all.
• Use the Change Request Estimate-Actual Template to record your estimated and actual effort -- don't cheat! If the requested change took longer (or shorter) than expected, determine why and modify your Estimating Guideline accordingly. These are your Estimating Guidelines! You can improve your future estimates by learning from your "spot-on" estimates and from your "not so spot-on" estimates.
• Leverage your Change Request estimate and actual to refine your Estimating Guidelines so that you can provide more accurate estimates. The example below illustrates that in Change Request 111 (CR111) what was originally estimated at two hours turned out to be an 18-hour effort because of "whatever was not known/understood/…" at the time. If this learning is reflected in your Estimating Guidelines, the estimate for Change Request 222 (CR222) will benefit from this learning.

• (Click the picture for a larger image.)

  Summary
  Start with what you know. Record what you guessed and record what you actually did. (You do not have to show this information to anyone!) Your estimates will improve if you remember and learn from your experience. Be honest with yourself and take the time to determine why an estimate was "off." This learning will help you estimate more accurately in the future. Below is a summary of the suggested steps. (Click on the picture for a larger image.)