Estimation Techniques – Testing

Estimation Techniques – Testing ”; Previous Next Test efforts are not based on any definitive timeframe. The efforts continue until some pre-decided timeline is set, irrespective of the completion of testing. This is mostly due to the fact that conventionally, test effort estimation is a part of the development estimation. Only in the case of estimation techniques that use WBS, such as Wideband Delphi, Three-point Estimation, PERT, and WBS, you can obtain the values for the estimates of the testing activities. If you have obtained the estimates as Function Points (FP), then as per Caper Jones, Number of Test Cases = (Number of Function Points) × 1.2 Once you have the number of test cases, you can take productivity data from organizational database and arrive at the effort required for testing. Percentage of Development Effort Method Test effort required is a direct proportionate or percentage of the development effort. Development effort can be estimated using Lines of Code (LOC) or Function Points (FP). Then, the percentage of effort for testing is obtained from Organization Database. The percentage so obtained is used to arrive at the effort estimate for testing. Estimating Testing Projects Several organizations are now providing independent verification and validation services to their clients and that would mean the project activities would entirely be testing activities. Estimating testing projects requires experience on varied projects for the software test life cycle. When you are estimating a testing project, consider − Team skills Domain Knowledge Complexity of the application Historical data Bug cycles for the project Resources availability Productivity variations System environment and downtime Testing Estimation Techniques The following testing estimation techniques are proven to be accurate and are widely used − PERT software testing estimation technique UCP Method WBS Wideband Delphi technique Function point/Testing point analysis Percentage distribution Experience-based testing estimation technique PERT Software Testing Estimation Technique PERT software testing estimation technique is based on statistical methods in which each testing task is broken down into sub-tasks and then three types of estimation are done on each sub-tasks. The formula used by this technique is − Test Estimate = (O + (4 × M) + E)/6 Where, O = Optimistic estimate (best case scenario in which nothing goes wrong and all conditions are optimal). M = Most likely estimate (most likely duration and there may be some problem but most of the things will go right). L = Pessimistic estimate (worst case scenario where everything goes wrong). Standard Deviation for the technique is calculated as − Standard Deviation (SD) = (E − O)/6 Use-Case Point Method UCP Method is based on the use cases where we calculate the unadjusted actor weights and unadjusted use case weights to determine the software testing estimation. Use-case is a document which specifies different users, systems or other stakeholders interacting with the concerned application. They are named as “Actors”. The interactions accomplish some defined goals protecting the interest of all stakeholders through different behavior or flow termed as scenarios. Step 1 − Count the no. of actors. Actors include positive, negative and exceptional. Step 2 − Calculate unadjusted actor weights as Unadjusted Actor Weights = Total no. of Actors Step 3 − Count the number of use-cases. Step 4 − Calculate unadjusted use-case weights as Unadjusted Use-Case Weights = Total no. of Use-Cases Step 5 − Calculate unadjusted use-case points as Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights) Step 6 − Determine the technical/environmental factor (TEF). If unavailable, take it as 0.50. Step 7 − Calculate adjusted use-case point as Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF] Step 8 − Calculate total effort as Total Effort = Adjusted Use-Case Point × 2 Work Breakdown Structure Step 1 − Create WBS by breaking down the test project into small pieces. Step 2 − Divide modules into sub-modules. Step 3 Divide sub-modules further into functionalities. Step 4 − Divide functionalities into sub-functionalities. Step 5 − Review all the testing requirements to make sure they are added in WBS. Step 6 − Figure out the number of tasks your team needs to complete. Step 7 − Estimate the effort for each task. Step 8 − Estimate the duration of each task. Wideband Delphi Technique In Wideband Delphi Method, WBS is distributed to a team comprising of 3-7 members for re-estimating the tasks. The final estimate is the result of the summarized estimates based on the team consensus. This method speaks more on experience rather than any statistical formula. This method was popularized by Barry Boehm to emphasize on the group iteration to reach a consensus where the team visualized different aspects of the problems while estimating the test effort. Function Point / Testing Point Analysis FPs indicate the functionality of software application from the user”s perspective and is used as a technique to estimate the size of a software project. In testing, estimation is based on requirement specification document, or on a previously created prototype of the application. To calculate FP for a project, some major components are required. They are − Unadjusted Data Function Points − i) Internal Files, ii) External Interfaces Unadjusted Transaction Function Points − i) User Inputs, ii) User Outputs & iii) User Inquiries Capers Jones basic formula − Number of Test Cases = (Number of Function Points) × 1.2 Total Actual Effort (TAE) − (Number of Test cases) × (Percentage of Development Effort /100) Percentage Distribution In this technique, all the phases of Software Development Life Cycle (SDLC) are assigned effort in %. This can be based on past data from similar projects. For example − Phase % of Effort Project Management 7% Requirements 9% Design 16% Coding 26% Testing (all Test Phases) 27% Documentation 9% Installation and Training 6% Next, % of effort for testing (all test phases) is further distributed for all Testing Phases − All Testing Phases % of Effort Component Testing 16 Independent Testing 84 Total 100 Independent Testing % of Effort Integration Testing 24

Estimation Techniques – Discussion

Discuss Estimation Techniques ”; Previous Next Estimation techniques are of utmost importance in software development life cycle, where the time required to complete a particular task is estimated before a project begins. Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable. This tutorial discusses various estimation techniques such as estimation using Function Points, Use-Case Points, Wideband Delphi technique, PERT, Analogy, etc. Print Page Previous Next Advertisements ”;

Estimation Techniques – Analogous

Estimation Techniques – Analogous ”; Previous Next Analogous Estimation uses a similar past project information to estimate the duration or cost of your current project, hence the word, “analogy”. You can use analogous estimation when there is limited information regarding your current project. Quite often, there will be situations when project managers will be asked to give cost and duration estimates for a new project as the executives need decision-making data to decide whether the project is worth doing. Usually, neither the project manager nor anyone else in the organization has ever done a project like the new one but the executives still want accurate cost and duration estimates. In such cases, analogous estimation is the best solution. It may not be perfect but is accurate as it is based on past data. Analogous estimation is an easy-to-implement technique. The project success rate can be up to 60% as compared to the initial estimates. Analogous Estimation – Definition Analogous estimation is a technique which uses the values of parameters from historical data as the basis for estimating similar parameter for a future activity. Parameters examples: Scope, cost, and duration. Measures of scale examples − Size, weight, and complexity. Because the project manager’s, and possibly the team’s experience and judgment are applied to the estimating process, it is considered a combination of historical information and expert judgment. Analogous Estimation Requirements For analogous estimation following is the requirement − Data from previous and on-going projects Work hours per week of each team member Costs involved to get the project completed Project close to the current project In case the current Project is new, and no past project is similar Modules from past projects that are similar to those in current project Activities from past projects that are similar to those in current project Data from these selected ones Participation of the project manager and estimation team to ensure experienced judgment on the estimates. Analogous Estimation Steps The project manager and team have to collectively do analogous estimation. Step 1 − Identify the domain of the current project. Step 2 − Identify the technology of the current project. Step 3 − Look in the organization database if a similar project data is available. If available, go to Step (4). Otherwise go to Step (6). Step 4 − Compare the current project with the identified past project data. Step 5 − Arrive at the duration and cost estimates of the current project. This ends analogous estimation of the project. Step 6 − Look in the organization database if any past projects have similar modules as those in the current project. Step 7 − Look in the organization database if any past projects have similar activities as those in the current project. Step 8 − Collect all those and use expert judgment to arrive at the duration and cost estimates of the current project. Advantages of Analogous Estimation Analogous estimation is a better way of estimation in the initial stages of the project when very few details are known. The technique is simple and time taken for estimation is very less. Organization’s success rate can be expected to be high since the technique is based on the organization’s past project data. Analogous estimation can be used to estimate the effort and duration of individual tasks too. Hence, in WBS when you estimate the tasks, you can use Analogy. Print Page Previous Next Advertisements ”;

Estimation Techniques – Resources

Estimation Techniques – Useful Resources ”; Previous Next The following resources contain additional information on Estimation Techniques. Please use them to get more in-depth knowledge on this. Useful Links on Estimation Techniques Estimation Techniques Wiki− Wikipedia Reference for Estimation Techniques. Software Estimation Techniques − Software Estimation Techniques. Useful Books on Estimation Techniques To enlist your site on this page, please drop an email to [email protected] Print Page Previous Next Advertisements ”;

Estimation Techniques – Home

Estimation Techniques Tutorial PDF Version Quick Guide Resources Job Search Discussion Estimation techniques are of utmost importance in software development life cycle, where the time required to complete a particular task is estimated before a project begins. Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable. This tutorial discusses various estimation techniques such as estimation using Function Points, Use-Case Points, Wideband Delphi technique, PERT, Analogy, etc. Audience If you are an aspiring project manager or project leader, then this tutorial is definitely for you. It will take you through all the important estimation techniques. Prerequisites Before proceeding with this tutorial, you should have a basic understanding of the Software Development Life Cycle (SDLC). In addition, you should have a basic understanding of software programming using any programming language. Print Page Previous Next Advertisements ”;

Estimation Techniques – Delphi

Estimation Techniques – Wideband Delphi ”; Previous Next Delphi Method is a structured communication technique, originally developed as a systematic, interactive forecasting method which relies on a panel of experts. The experts answer questionnaires in two or more rounds. After each round, a facilitator provides an anonymous summary of the experts’ forecasts from the previous round with the reasons for their judgments. Experts are then encouraged to revise their earlier answers in light of the replies of other members of the panel. It is believed that during this process the range of answers will decrease and the group will converge towards the “correct” answer. Finally, the process is stopped after a predefined stop criterion (e.g. number of rounds, achievement of consensus, and stability of results) and the mean or median scores of the final rounds determine the results. Delphi Method was developed in the 1950-1960s at the RAND Corporation. Wideband Delphi Technique In the 1970s, Barry Boehm and John A. Farquhar originated the Wideband Variant of the Delphi Method. The term “wideband” is used because, compared to the Delphi Method, the Wideband Delphi Technique involved greater interaction and more communication between the participants. In Wideband Delphi Technique, the estimation team comprise the project manager, moderator, experts, and representatives from the development team, constituting a 3-7 member team. There are two meetings − Kickoff Meeting Estimation Meeting Wideband Delphi Technique – Steps Step 1 − Choose the Estimation team and a moderator. Step 2 − The moderator conducts the kickoff meeting, in which the team is presented with the problem specification and a high level task list, any assumptions or project constraints. The team discusses on the problem and estimation issues, if any. They also decide on the units of estimation. The moderator guides the entire discussion, monitors time and after the kickoff meeting, prepares a structured document containing problem specification, high level task list, assumptions, and the units of estimation that are decided. He then forwards copies of this document for the next step. Step 3 − Each Estimation team member then individually generates a detailed WBS, estimates each task in the WBS, and documents the assumptions made. Step 4 − The moderator calls the Estimation team for the Estimation meeting. If any of the Estimation team members respond saying that the estimates are not ready, the moderator gives more time and resends the Meeting Invite. Step 5 − The entire Estimation team assembles for the estimation meeting. Step 5.1 − At the beginning of the Estimation meeting, the moderator collects the initial estimates from each of the team members. Step 5.2 − He then plots a chart on the whiteboard. He plots each member’s total project estimate as an X on the Round 1 line, without disclosing the corresponding names. The Estimation team gets an idea of the range of estimates, which initially may be large. Step 5.3 − Each team member reads aloud the detailed task list that he/she made, identifying any assumptions made and raising any questions or issues. The task estimates are not disclosed. The individual detailed task lists contribute to a more complete task list when combined. Step 5.4 − The team then discusses any doubt/problem they have about the tasks they have arrived at, assumptions made, and estimation issues. Step 5.5 − Each team member then revisits his/her task list and assumptions, and makes changes if necessary. The task estimates also may require adjustments based on the discussion, which are noted as +N Hrs. for more effort and –N Hrs. for less effort. The team members then combine the changes in the task estimates to arrive at the total project estimate. Step 5.6 − The moderator collects the changed estimates from all the team members and plots them on the Round 2 line. In this round, the range will be narrower compared to the earlier one, as it is more consensus based. Step 5.7 − The team then discusses the task modifications they have made and the assumptions. Step 5.8 − Each team member then revisits his/her task list and assumptions, and makes changes if necessary. The task estimates may also require adjustments based on the discussion. The team members then once again combine the changes in the task estimate to arrive at the total project estimate. Step 5.9 − The moderator collects the changed estimates from all the members again and plots them on the Round 3 line. Again, in this round, the range will be narrower compared to the earlier one. Step 5.10 − Steps 5.7, 5.8, 5.9 are repeated till one of the following criteria is met − Results are converged to an acceptably narrow range. All team members are unwilling to change their latest estimates. The allotted Estimation meeting time is over. Step 6 − The Project Manager then assembles the results from the Estimation meeting. Step 6.1 − He compiles the individual task lists and the corresponding estimates into a single master task list. Step 6.2 − He also combines the individual lists of assumptions. Step 6.3 − He then reviews the final task list with the Estimation team. Advantages and Disadvantages of Wideband Delphi Technique Advantages Wideband Delphi Technique is a consensus-based estimation technique for estimating effort. Useful when estimating time to do a task. Participation of experienced people and they individually estimating would lead to reliable results. People who would do the work are making estimates thus making valid estimates. Anonymity maintained throughout makes it possible for everyone to express their results confidently. A very simple technique. Assumptions are documented, discussed and agreed. Disadvantages Management support is required. The estimation results may not be what the management wants to hear. Print Page Previous Next Advertisements ”;

Estimation Techniques – FP Counting

Estimation Techniques – FP Counting Process ”; Previous Next FP Counting Process involves the following steps − Step 1 − Determine the type of count. Step 2 − Determine the boundary of the count. Step 3 − Identify each Elementary Process (EP) required by the user. Step 4 − Determine the unique EPs. Step 5 − Measure data functions. Step 6 − Measure transactional functions. Step 7 − Calculate functional size (unadjusted function point count). Step 8 − Determine Value Adjustment Factor (VAF). Step 9 − Calculate adjusted function point count. Note − General System Characteristics (GSCs) are made optional in CPM 4.3.1 and moved to Appendix. Hence, Step 8 and Step 9 can be skipped. Step 1: Determine the Type of Count There are three types of function point counts − Development Function Point Count Application Function Point Count Enhancement Function Point Count Development Function Point Count Function points can be counted at all phases of a development project from requirement to implementation stage. This type of count is associated with new development work and may include the prototypes, which may have been required as temporary solution, which supports the conversion effort. This type of count is called a baseline function point count. Application Function Point Count Application counts are calculated as the function points delivered, and exclude any conversion effort (prototypes or temporary solutions) and existing functionality that may have existed. Enhancement Function Point Count When changes are made to software after production, they are considered as enhancements. To size such enhancement projects, the Function Point Count gets Added, Changed or Deleted in the Application. Step 2: Determine the Boundary of the Count The boundary indicates the border between the application being measured and the external applications or the user domain. (Refer Figure 1) To determine the boundary, understand − The purpose of the function point count Scope of the application being measured How and which applications maintain what data The business areas that support the applications Step 3: Identify Each Elementary Process Required by the User Compose and/or decompose the functional user requirements into the smallest unit of activity, which satisfies all of the following criteria − Is meaningful to the user. Constitutes a complete transaction. Is self-contained. Leaves the business of the application being counted in a consistent state. For example, the Functional User Requirement − “Maintain Employee information” can be decomposed into smaller activities such as add employee, change employee, delete employee, and inquire about employee. Each unit of activity thus identified is an Elementary Process (EP). Step 4: Determine the Unique Elementary Processes Comparing two EPs already identified, count them as one EP (same EP) if they − Require the same set of DETs. Require the same set of FTRs. Require the same set of processing logic to complete the EP. Do not split an EP with multiple forms of processing logic into multiple Eps. For e.g., if you have identified ‘Add Employee’ as an EP, it should not be divided into two EPs to account for the fact that an employee may or may not have dependents. The EP is still ‘Add Employee’, and there is variation in the processing logic and DETs to account for dependents. Step 5: Measure Data Functions Classify each data function as either an ILF or an EIF. A data function shall be classified as an − Internal Logical File (ILF), if it is maintained by the application being measured. External Interface File (EIF) if it is referenced, but not maintained by the application being measured. ILFs and EIFs can contain business data, control data and rules based data. For example, telephone switching is made of all three types – business data, rule data and control data. Business data is the actual call. Rule data is how the call should be routed through the network, and control data is how the switches communicate with each other. Consider the following documentation for counting ILFs and EIFs − Objectives and constraints for the proposed system. Documentation regarding the current system, if such a system exists. Documentation of the users’ perceived objectives, problems and needs. Data models. Step 5.1: Count the DETs for Each Data Function Apply the following rules to count DETs for ILF/EIF − Count a DET for each unique user identifiable, non-repeated field maintained in or retrieved from the ILF or EIF through the execution of an EP. Count only those DETs being used by the application that is measured when two or more applications maintain and/or reference the same data function. Count a DET for each attribute required by the user to establish a relationship with another ILF or EIF. Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs. Grouping will depend on how the EPs use the attributes within the application. Step 5.2: Count the RETs for Each Data Function Apply the following rules to count RETs for ILF/EIF − Count one RET for each data function. Count one additional RET for each of the following additional logical sub-groups of DETs. Associative entity with non-key attributes. Sub-type (other than the first sub-type). Attributive entity, in a relationship other than mandatory 1:1. Step 5.3: Determine the Functional Complexity for Each Data Function RETS Data Element Types (DETs) 1-19 20-50 >50 1 L L A 2 to 5 L A H >5 A H H Functional Complexity: L = Low; A = Average; H = High Step 5.4: Measure the Functional Size for Each Data Function Functional Complexity FP Count for ILF FP Count for EIF Low 7 5 Average 10 7 High 15 10 Step 6: Measure Transactional Functions To measure transactional functions following are the necessary steps − Step 6.1: Classify each Transactional Function Transactional functions should be classified as an External Input, External Output or an External Inquiry. External Input External Input (EI) is an Elementary Process that processes data or control information that comes from outside

Estimation Techniques – Quick Guide

Estimation Techniques – Quick Guide ”; Previous Next Estimation Techniques – Overview Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable. Estimation determines how much money, effort, resources, and time it will take to build a specific system or product. Estimation is based on − Past Data/Past Experience Available Documents/Knowledge Assumptions Identified Risks The four basic steps in Software Project Estimation are − Estimate the size of the development product. Estimate the effort in person-months or person-hours. Estimate the schedule in calendar months. Estimate the project cost in agreed currency. Observations on Estimation Estimation need not be a one-time task in a project. It can take place during − Acquiring a Project. Planning the Project. Execution of the Project as the need arises. Project scope must be understood before the estimation process begins. It will be helpful to have historical Project Data. Project metrics can provide a historical perspective and valuable input for generation of quantitative estimates. Planning requires technical managers and the software team to make an initial commitment as it leads to responsibility and accountability. Past experience can aid greatly. Use at least two estimation techniques to arrive at the estimates and reconcile the resulting values. Refer Decomposition Techniques in the next section to learn about reconciling estimates. Plans should be iterative and allow adjustments as time passes and more details are known. General Project Estimation Approach The Project Estimation Approach that is widely used is Decomposition Technique. Decomposition techniques take a divide and conquer approach. Size, Effort and Cost estimation are performed in a stepwise manner by breaking down a Project into major Functions or related Software Engineering Activities. Step 1 − Understand the scope of the software to be built. Step 2 − Generate an estimate of the software size. Start with the statement of scope. Decompose the software into functions that can each be estimated individually. Calculate the size of each function. Derive effort and cost estimates by applying the size values to your baseline productivity metrics. Combine function estimates to produce an overall estimate for the entire project. Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost estimates by breaking down a project into related software engineering activities. Identify the sequence of activities that need to be performed for the project to be completed. Divide activities into tasks that can be measured. Estimate the effort (in person hours/days) required to complete each task. Combine effort estimates of tasks of activity to produce an estimate for the activity. Obtain cost units (i.e., cost/unit effort) for each activity from the database. Compute the total effort and cost for each activity. Combine effort and cost estimates for each activity to produce an overall effort and cost estimate for the entire project. Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from Step 2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if widely divergent estimates occur conduct further investigation concerning whether − The scope of the project is not adequately understood or has been misinterpreted. The function and/or activity breakdown is not accurate. Historical data used for the estimation techniques is inappropriate for the application, or obsolete, or has been misapplied. Step 5 − Determine the cause of divergence and then reconcile the estimates. Estimation Accuracy Accuracy is an indication of how close something is to reality. Whenever you generate an estimate, everyone wants to know how close the numbers are to reality. You will want every estimate to be as accurate as possible, given the data you have at the time you generate it. And of course you don’t want to present an estimate in a way that inspires a false sense of confidence in the numbers. Important factors that affect the accuracy of estimates are − The accuracy of all the estimate’s input data. The accuracy of any estimate calculation. How closely the historical data or industry data used to calibrate the model matches the project you are estimating. The predictability of your organization’s software development process. The stability of both the product requirements and the environment that supports the software engineering effort. Whether or not the actual project was carefully planned, monitored and controlled, and no major surprises occurred that caused unexpected delays. Following are some guidelines for achieving reliable estimates − Base estimates on similar projects that have already been completed. Use relatively simple decomposition techniques to generate project cost and effort estimates. Use one or more empirical estimation models for software cost and effort estimation. Refer to the section on Estimation Guidelines in this chapter. To ensure accuracy, you are always advised to estimate using at least two techniques and compare the results. Estimation Issues Often, project managers resort to estimating schedules skipping to estimate size. This may be because of the timelines set by the top management or the marketing team. However, whatever the reason, if this is done, then at a later stage it would be difficult to estimate the schedules to accommodate the scope changes. While estimating, certain assumptions may be made. It is important to note all these assumptions in the estimation sheet, as some still do not document assumptions in estimation sheets. Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often treated as though they are accurate. The best way of expressing estimates is as a range of possible outcomes by saying, for example, that the project will take 5 to 7 months instead of stating it will be complete on a particular date or it will be complete in a fixed no. of months. Beware of committing to a range that is too narrow as that is equivalent to committing to a definite date. You could also include uncertainty as an accompanying probability value.

Estimation Techniques – Overview

Estimation Techniques – Overview ”; Previous Next Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable. Estimation determines how much money, effort, resources, and time it will take to build a specific system or product. Estimation is based on − Past Data/Past Experience Available Documents/Knowledge Assumptions Identified Risks The four basic steps in Software Project Estimation are − Estimate the size of the development product. Estimate the effort in person-months or person-hours. Estimate the schedule in calendar months. Estimate the project cost in agreed currency. Observations on Estimation Estimation need not be a one-time task in a project. It can take place during − Acquiring a Project. Planning the Project. Execution of the Project as the need arises. Project scope must be understood before the estimation process begins. It will be helpful to have historical Project Data. Project metrics can provide a historical perspective and valuable input for generation of quantitative estimates. Planning requires technical managers and the software team to make an initial commitment as it leads to responsibility and accountability. Past experience can aid greatly. Use at least two estimation techniques to arrive at the estimates and reconcile the resulting values. Refer Decomposition Techniques in the next section to learn about reconciling estimates. Plans should be iterative and allow adjustments as time passes and more details are known. General Project Estimation Approach The Project Estimation Approach that is widely used is Decomposition Technique. Decomposition techniques take a divide and conquer approach. Size, Effort and Cost estimation are performed in a stepwise manner by breaking down a Project into major Functions or related Software Engineering Activities. Step 1 − Understand the scope of the software to be built. Step 2 − Generate an estimate of the software size. Start with the statement of scope. Decompose the software into functions that can each be estimated individually. Calculate the size of each function. Derive effort and cost estimates by applying the size values to your baseline productivity metrics. Combine function estimates to produce an overall estimate for the entire project. Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost estimates by breaking down a project into related software engineering activities. Identify the sequence of activities that need to be performed for the project to be completed. Divide activities into tasks that can be measured. Estimate the effort (in person hours/days) required to complete each task. Combine effort estimates of tasks of activity to produce an estimate for the activity. Obtain cost units (i.e., cost/unit effort) for each activity from the database. Compute the total effort and cost for each activity. Combine effort and cost estimates for each activity to produce an overall effort and cost estimate for the entire project. Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from Step 2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if widely divergent estimates occur conduct further investigation concerning whether − The scope of the project is not adequately understood or has been misinterpreted. The function and/or activity breakdown is not accurate. Historical data used for the estimation techniques is inappropriate for the application, or obsolete, or has been misapplied. Step 5 − Determine the cause of divergence and then reconcile the estimates. Estimation Accuracy Accuracy is an indication of how close something is to reality. Whenever you generate an estimate, everyone wants to know how close the numbers are to reality. You will want every estimate to be as accurate as possible, given the data you have at the time you generate it. And of course you don’t want to present an estimate in a way that inspires a false sense of confidence in the numbers. Important factors that affect the accuracy of estimates are − The accuracy of all the estimate’s input data. The accuracy of any estimate calculation. How closely the historical data or industry data used to calibrate the model matches the project you are estimating. The predictability of your organization’s software development process. The stability of both the product requirements and the environment that supports the software engineering effort. Whether or not the actual project was carefully planned, monitored and controlled, and no major surprises occurred that caused unexpected delays. Following are some guidelines for achieving reliable estimates − Base estimates on similar projects that have already been completed. Use relatively simple decomposition techniques to generate project cost and effort estimates. Use one or more empirical estimation models for software cost and effort estimation. Refer to the section on Estimation Guidelines in this chapter. To ensure accuracy, you are always advised to estimate using at least two techniques and compare the results. Estimation Issues Often, project managers resort to estimating schedules skipping to estimate size. This may be because of the timelines set by the top management or the marketing team. However, whatever the reason, if this is done, then at a later stage it would be difficult to estimate the schedules to accommodate the scope changes. While estimating, certain assumptions may be made. It is important to note all these assumptions in the estimation sheet, as some still do not document assumptions in estimation sheets. Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often treated as though they are accurate. The best way of expressing estimates is as a range of possible outcomes by saying, for example, that the project will take 5 to 7 months instead of stating it will be complete on a particular date or it will be complete in a fixed no. of months. Beware of committing to a range that is too narrow as that is equivalent to committing to a definite date. You could also include uncertainty as an accompanying probability value. For example, there is a

Estimation – Planning Poker

Estimation Techniques – Planning Poker ”; Previous Next Planning Poker Estimation Planning Poker is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in Scrum. Planning Poker combines three estimation techniques − Wideband Delphi Technique, Analogous Estimation, and Estimation using WBS. Planning Poker was first defined and named by James Grenning in 2002 and later popularized by Mike Cohn in his book “Agile Estimating and Planning”, whose company trade marked the term. Planning Poker Estimation Technique In Planning Poker Estimation Technique, estimates for the user stories are derived by playing planning poker. The entire Scrum team is involved and it results in quick but reliable estimates. Planning Poker is played with a deck of cards. As Fibonacci sequence is used, the cards have numbers – 1, 2, 3, 5, 8, 13, 21, 34, etc. These numbers represent the “Story Points”. Each estimator has a deck of cards. The numbers on the cards should be large enough to be visible to all the team members, when one of the team members holds up a card. One of the team members is selected as the Moderator. The moderator reads the description of the user story for which estimation is being made. If the estimators have any questions, product owner answers them. Each estimator privately selects a card representing his or her estimate. Cards are not shown until all the estimators have made a selection. At that time, all cards are simultaneously turned over and held up so that all team members can see each estimate. In the first round, it is very likely that the estimations vary. The high and low estimators explain the reason for their estimates. Care should be taken that all the discussions are meant for understanding only and nothing is to be taken personally. The moderator has to ensure the same. The team can discuss the story and their estimates for a few more minutes. The moderator can take notes on the discussion that will be helpful when the specific story is developed. After the discussion, each estimator re-estimates by again selecting a card. Cards are once again kept private until everyone has estimated, at which point they are turned over at the same time. Repeat the process till the estimates converge to a single estimate that can be used for the story. The number of rounds of estimation may vary from one user story to another. Benefits of Planning Poker Estimation Planning poker combines three methods of estimation − Expert Opinion − In expert opinion-based estimation approach, an expert is asked how long something will take or how big it will be. The expert provides an estimate relying on his or her experience or intuition or gut feel. Expert Opinion Estimation usually doesn’t take much time and is more accurate compared to some of the analytical methods. Analogy − Analogy estimation uses comparison of user stories. The user story under estimation is compared with similar user stories implemented earlier, giving accurate results as the estimation is based on proven data. Disaggregation − Disaggregation estimation is done by splitting a user story into smaller, easier-to-estimate user stories. The user stories to be included in a sprint are normally in the range of two to five days to develop. Hence, the user stories that possibly take longer duration need to be split into smaller use-Cases. This approach also ensures that there would be many stories that are comparable. Print Page Previous Next Advertisements ”;