Providing a Rough Order of Magnitude Estimate

After entering requirements into your system, you should record a basic estimate for each of the requirements to capture some general information regarding how difficult or easy a feature might be to implement. If you are using MSF Agile–based projects to record requirements through scenario and quality of service work item types, you will provide only a rough order of magnitude estimate of your requirements. A rough order of magnitude estimate is a value that indicates the complexity of the requirement, represented numerically from 0 to 3, with 0 indicating the lowest level of complexity requiring no effort to achieve and 3 indicating the highest level of complexity. One of the best ways to gather rough order of magnitude values is to open the list of scenarios and quality of service requirements in Office Excel and simply go through each one with your entire team. For each requirement, have a brief discussion with your team, which should include your customer, developers, testers, and business analysts. As Cohn points out, you should act as a moderator during this discussion to ensure that your team doesn’t go off track or into too many design and implementation details. It should be clear that working together to establish a rough order of magnitude estimate does not require as much design and implementation details as task-based estimating, which we will describe later in this chapter.

When estimating scenarios at this level, you will be relying on expert opinion, estimate analogies, and requirement breakdown. Your team may have worked on similar projects in the past delivering similar requirements; in this case, their expert judgment is critical to the estimate. The use of estimating analogies refers to comparing scenarios to some known baseline. For example, suppose that the team agrees that the scenario called Enter Production Data has a rough order of magnitude of 2 because this represents a common scenario that the team has worked on many times before. The team would then compare other scenarios with this baseline scenario and ask whether this new scenario is much more difficult or easy than the Enter Production Data scenario. If it is much easier than the baseline scenario, the team would enter 1 as the rough order of magnitude, and if it’s much more complex, they would enter 3. Sometimes, the team may indicate that the problem is much too complex to even estimate. This is a clear indication that you will need to decompose the requirement into smaller and more specific requirements that are easier to estimate and understand. This process is called requirements decomposition.

Third-Party Requirement Tools for Visual Studio Team System

There are a number of third-party products that help with gathering and representing requirements that plug right into Visual Studio Team System. Here is a list of the more popular tools customers are using today:

CaliberRM from Borland You can find CaliberRM on the Borland site at http://www.borland.com. CaliberRM is a well known requirements management solution that provides a hierarchical representation of requirements and full traceability with work items stored within Visual Studio Team System.

Enterprise Architect from Sparx Systems You can find Enterprise Architect at http://www.sparxsystems.com. Enterprise Architect is a superb low-cost modeling tool that integrates with Visual Studio Team System and allows you to graphically represent business requirements in a variety of modeling standards.

stpBA Storyboarding for Microsoft Visual Studio Team System Found at http:// www.stpsoft.co.uk, stpBA Storyboarding seamlessly integrates with Visual Studio Team System process templates and generates screen flow diagrams, HTML storyboards, UI specifications, functional specifications, Visual Studio Team System work items, and test scripts.