Problem solve Get help with specific problems with your technologies, process and projects.

How to estimate change requests in requirements

Software requirements are often subject to change; using a sound estimation process helps greatly to manage change. Requirements expert Betty Luedke explains, in detail, how to implement good estimation techniques.

I am working in an organization where the requirements come only for a small change request. Can anyone let me...

know, with an example, how to estimate for a small requirement by using any good estimation technique?

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.)

    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.)


This was last published in August 2008

Dig Deeper on Software Requirements Gathering Techniques



Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.