How to estimate change requests in requirements

How to estimate change requests in requirements

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?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

It is important to realize that estimation is not an activity in absolutes — your estimates are relative and can improve over time if you learn from your continuing experience.

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.

    • Software requirements gathering:
    Requirements engineering in an uncooperative environment

    Requirements gathering with storyboards

    Requirements reporting beyond use cases
  • 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.)

    This was first published in August 2008