Presenting several drafts of a feature requirement for the team to review during the preparation process ..

When you think about the software requirements process, the simple process that comes to mind is about the Business Analysts or the Product Manager studying the business needs, and then coming out with the requirements. In a number of cases, there is the expectation that the Product Manager or the Business Analyst will spend time on these business cases and then there will be a Requirements Documents that will be released to the team for the next part of the cycle, the design and architecture phase. In the case where the work is being done for a client, the Requirements Documents generated by the Business Analyst can be sent to the business people from the client end so that they can verify that whatever is being done is right. However, there is a black hole about the requirements process, with the team getting a completed document.
When you consider the case where the team has worked on the product before (which is true in most cases of product development, or even in cases of client work where the team has worked with the client on their software previously), the team has a great deal of knowledge of how the software works. This also means that the team is a valuable knowledge base that the Product Manager or the Business Analyst should be exploiting. However, it is equally true that there are Product Managers who consider themselves to be above taking support of the team (at least in the process of generating the Requirements Document).
If the Product Manager was to take the help of the team for generating the Requirements Document, how would this happen. Well, for a complete process of taking help,
- The Product Manager would need to start out with forming a small team that would assist him or her in this process, taking the more senior folks from the development and testing team.
- The Product Manger would need to lay out the high level points of the requirement, and put them in a list or form that the team can review and get back in terms of comments that they may have. At this stage, it is unlikely that the team would have substantial comments since these are high level requirements.
- Once the Product Manager starts detailing out these requirements, converting them into more detailed requirements, or into User stories, this is where the team can really contribute. These can be put onto a document or internal web page that the team can review and comments posted, followed by a meeting. In some cases, I have known that team members taking care of the development or testing of a specific area have more knowledge of the details of the workflow and have made corrections, or even suggested some improvements that have added value. However, it remains at the discretion of the Product Manager to decide which of these points should be taken or not (it makes for a more cordial relationship though if the Product Manager does explain the reason why something is not taken).
- This can be an iterative process, but once it is done, then Product Manager has a set of requirements that form the basis of the work that happens next, and the advantage is that during this process, the team already has a great idea of the requirements flow; and equally important, understand the amount of work required, which also helps in determining the resource requirements and time needed for all these requirements (or atleast, gives a much better feeling in terms of increased accuracy of the resource estimation).

Dot / Patch release: Estimating the features where there is a change required

One of the previous posts I wrote about was that of a Dot / Patch release (Estimation of dot / patch release) where there was an effort to show what are some of the reasons for a dot release or a patch release and the broad level points about how to estimate the amount of overall effort needed as well as the generation of schedule needed for the release. This needs to be done even if you already have a hard date for the release of the patch / dot release, since if the generated schedule is going far beyond the required date, then there is something wrong which would need to be solved (possibly by adding more resources, although that cannot be done in every case).
This post talks about actually doing an estimation of the changes required by working on the different features to see the overall impact of the change. Consider a case where a dot release has to be made for the application, with a change made in one of the features for a major defect. Now, the dot release has to be made in a couple of months, with the exact release date being decided based on the estimates for the different areas of the release (development effort, testing, localization, etc). One of the starting points for this estimation effort is figuring the effort needed for development, and for that, there needs to more detailed investigation of what areas need development effort.
How do you do this ? The first and most important starting point is to ensure that you have an experienced developer to do the investigation and estimate. The actual effort can be done by somebody in the development team, but the investigation should be done by a senior and experienced developer. How do you start:
- First, make sure that the developer has been given details of the change needed in terms of requirements
- Give the developer some time to discuss with other team members about the areas which are impacted.
If this is a core area, then the developer would need to go across the application to determine the impact. For example, there may be a need in the user security framework, and that would spin across all the application. If the change is localized to a specific area, then it is easier to make the effort estimate of the change. There is no great complexity in this area, as long as the developer does a thorough job.
- The senior developer should spend time with the actual developer who is going to work on the release and make sure that he has enough understanding of the changes required, and depending on the skill of the developer assigned, make sure that the correct estimate is given (which may included a required buffer).
- The developer also needs to ensure that he has spent time with people from the localization development team and the installer / release teams so that he has an idea of the amount of time needed from their side and can also include these in the effort estimate.
- The developer needs to spend a fair amount of time with the testing team so that they have a good understanding of all the changes that are going to happen in the release as well as the actual impact of the change including all the areas of the application that are impacted. 

Being able to estimate effort needed for smaller releases (patch / dot release)

One of the most difficult tasks to estimate are the smaller projects that a team needs to do. Consider a long project, the typical new version release of a software (for a typical long example, consider the schedule for the release of a new version of Microsoft Office - is it always typically more than 1 year); now even when the team is busy doing this release, there will be always be the need for doing a dot release or a patch at the same time (or even multiple such releases). Why would this happen ?
- There could be a security issue for which an urgent patch needs to be released,
- There could be some new feature that is meant to be pushed through before the next release
- Because the release schedule is long, defects that are found during the next few months are collected and released in an interim release that is then released
- And this is one of the most interesting reasons for a release - I know several people who will not take a new version of a Microsoft until a service pack has been released, since that is when it would have stabilized - so this puts pressure on a company to do a release within a few months

With all this, who does these interim releases ? For products where there is already a definite schedule of interim releases, a small sub-team can be setup to take care of these releases. Such a team will soon gain expertise in doing these smaller releases, and can work on the main release if there are no interim releases ongoing. However, for teams where there is no definite schedule of release of these interim releases, it does not make sense for a team to put dedicated folks to work on the product. Even more, in my experience, when people are assigned to such interim releases, there is a need to rotate the people working on such releases, since these are seen as essential but maintenance, not with the excitement of working for something new.
Now, once people are assigned to do the project, there is a need to figure out the schedule for such a release. However, in most of these cases, the end date is already fixed - the Product Manager already has a date in mind about when these releases need to be released. But, the team still need to define the estimate and a probable schedule in mind:
- Whether this be a dot release or a patch (a patch is a small set of files that is downloaded and can be installed, a dot release is typically the full installer with a few changes in the files). The advantage of having a dot release is that it can replace the original installer
- Define the change that is happening (this typically means the files and features that are being changed, and the estimated impact of this change)
- The amount of time needed for the development team to make the required changes
- The amount of time needed for the testing team to test the area and surrounding areas (this would also include the installer created for the release)
- Typically most products have language versions, and those need to be created and tested when a dot release or a patch is made. So, the estimate for the amount of time needed for these activities also need to be incorporated into the schedule.

Together, all of these can be woven into a schedule for the interim release. If it turns out that the deadline given is less than the projected schedule end, then you need to push back. For a small release, it is next to impossible to meet the project with the required quality principles, unless sufficient time is given. We once had a situation where a particular variation in the installer made a small error in the registry, which then prevented those who installed from being able to install another update, and there was a lot of backlash over that - we had to release another patch for that one.

Read more about the estimation done by a senior member of the development team.

Risk planning - Accounting for when estimates are prepared by one person and task done by another

Let me admit it straight out, this is a pretty difficult topic to write about. In all my years of experience as a manager, trying to have a simple equation or factor for working out what happens when somebody prepares an estimate and somebody else has to do the actual development / coding for that work was not possible. There was no one size fits all for this kind of situation. In the previous post on this topic (Using a confidence level for estimates for later refinement), I put some initial thoughts on this subject. The idea was that estimates are prepared at the beginning of a cycle and can be different from the actual effort put in when the work happens on that features.
It could be argued about why estimates are needed to be prepared at the beginning of the cycle, but there can be many reasons for that. One of the biggest reasons was about wanting to have a good idea about the number of features that would be possible to be done in the given cycle. This is necessary for the team, and this is very important for the stakeholders and sponsors of the team. In a number of cases, the plan for the release will not be approved until there is an assurance that a Minimum Viable Product has not been planned. Given that the release of a product can have profound implications on the financial status of an organization, it can be very important to do planning about the number of features that can be fit into the release.
Doing this estimation also allows the team to do the required resource planning, and even though the number of resources may not change too much between releases, if there is a need to do a big bang release, then the team would want to know the number of extra resources that are required for this release. So, let us work with the assumption that the team needs to do the initial estimation for the features that are planned for the release.
Now, the biggest problem that occurs is that when the work for a release is being estimated, the people doing the estimation are the more senior developers in the team. Typically, the estimation exercise can only last for around 5-10% of the total time of the release, and it is really not possible to do the logical task of breaking down the features into detail deep enough that the estimate would be very accurate. So, a lesser number of people are drafted in to do this kind of work, and an equal assumption is that the estimation is primarily done by the person using their previous experience to determine the scope of work for the details of the feature and using this for the future.
But when it comes to doing the actual development work for the feature, you cannot have these senior people doing all the work. The work is shared among the team members and this is where discrepancies come in. You can have the senior person being very skilled in doing such work, but the person who is actually doing this work is not so skilled and you end up with more effort required for doing this work. So, whenever the work allocation is being done, there is a need to map the estimate with the person who did the estimate, and the person who is actually going to be doing the work. A skilled manager who knows both these people would be able to do this to a large extent and be pretty accurate in this. At the same time, the project manager should continue to track and compare the effort discrepancy mentioned by the engineering manager with the actual effort discrepancy.

Risk planning - Using a confidence level along with estimates so that these are refined later in the schedule

The normal cycle we would follow was for a 6 month period of software development. Every 6 months we would release the next version of our software, and towards that end, we had a list of features ready for the Product Manager to consider for prioritization and decide which features would make it in the next version of the software, and which would be taken up in future versions of the software. Once such a list was prepared, the next step was to get the Product Manager to spend time with the designer and break down the feature set into a slightly more detailed set, something like Use Cases. However, the level of detail that we could do in the time period that we had was of a level higher than Use Cases (the actual Use Cases would be generated only when work on the features was about to start).
Once this level of detail was generated, the next step was to get the senior engineering leads talking to the Product Manager and the designers to get some idea about the feature, look at some workflows and implementation, and then, start looking at how to estimate these. There are many methods of estimation, but in most cases we used the method called heuristics, which is a fancy word that we took to mean that these people knew how to do feature development, they had been doing it for quite some time, and as a result, they would be able to use their experience to determine the typical effort required for doing the feature.
Next, all the effort for the list of features was tabulated, and then assigned to the different members of the team while doing balancing, ensuring that everybody got a mix of interesting and boring work (wherever possible if there was exciting work, since that would help in terms of morale). There was some rationalization of the effort reported to take into account that some of the team members were more capable while others were not so capable. Finally the list of features would be generated to be presented to the stakeholders of the team and the organization.
However, once the team would start actually doing work on these features, then the actual effort would come into play. It was quite possible that the initial effort that was listed was the final effort once the team started implementation, but there was also a high chance that the effort would change once the team actually started implementation. There could be design issues that were not expected before actual implementation started, or there could be other setbacks that happened. It could be that the person doing the estimate had not done a correct estimate and this was clear when the team actually started the estimation.
This has an impact on risk planning. Part of the continuous effort to monitor the risk involved in the project is to determine the actual state of the project and also to determine whether the features that were expected to be done in the initial planning are on schedule or not. However, it should be part of the risk matrix to try and determine the level of inaccuracy present in these estimates (even though it can be pretty difficult) and to estimate the impact this could have on the feature schedule. It is critical that the Project / Program manager has been tracking the estimate accuracy of the features and is not majorly surprised if a feature is running late because of estimation issues.

When to re-estimate? What is a better way to estimate : Story points or Ideal Days?

When to Re-estimate?

Story points and ideal days are estimates of the size of a feature which helps you to know when to re-estimate. Re-estimate is done only when your opinion of the relative size of one or more stories has changed. One should not re-estimate just because progress is not coming as rapidly as expected.

Velocity should be allowed to take care of most estimation inaccuracies. Velocity is considered to be a great equalizer. The reason behind this is that the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. As long as we are consistent with the estimates, measuring velocity over the first few iterations will allow us to have a reliable schedule.

At the end of an iteration, it is not recommended giving partial credit for partially finished user stories. The preference is for the team to count the entire estimate towards their velocity (if they completely finished and the feature has been accepted by the product owner) or for them to count nothing toward their story otherwise.

However, the team may choose to re-estimate partially complete user stories. Typically, this will mean estimating a user story representing the work that was completed during the iteration and one or more user stories that describe the remaining work. The sum of these estimates does not need to equal the initial estimate.

A team can choose to estimate either through story points or ideal days. Each has its advantages.


Benefits of Story Points
1. They help drive cross functional behavior.
2. The estimates derived by story points do not decay.
3. Story points are a pure measure of size.
4. Estimation through story points is faster.
5. Unlike ideal days, story points can be compared among team members. If one team member thinks that it will take him 4 ideal days, and another member thinks that it will take him 1 ideal day, both of them may be right yet there is no basis on which to argue and establish a single estimate.

Benefits of Ideal Days
1. They are more easily explained to those outside the team.
2. They are easier to get started with.

The advantages of story points are more compelling as compared to benefits of ideal days. one way is if a team is struggling with estimating the pure size, they can start off with estimating with ideal days and gradually switching to estimating by story points.

What are different techniques for estimating used by agile teams?

Expending more time and effort to arrive at an estimate does not necessarily increase the accuracy of the estimate. The amount of effort put into an estimate should be determined by the purpose of that estimate. Although it is well known that the best estimates are given by those who will do the work, on an agile team we do not know in advance who will do the work. Therefore, estimating should be a collaborative activity for the team.

Concepts on Estimating

- Agile teams acknowledge that we cannot eliminate uncertainty from estimates, but they embrace the idea that small efforts are rewarded with big gains.
- Agile teams can produce more reliable plans because they frequently deliver small increments of fully working, tested, integrated code.
- Agile teams do not rely on single expert to estimate. Estimates are best derived collectively by the team.
- Estimates should be on a predefined scale.
- Features that will be worked on in the near future and that need fairly reliable estimates should be made small enough that they can be estimated on a non-linear scale from 1 to 10 such as 1,2,3,5, and 8 or 1,2,4, and 8.
- Larger features that will most likely not be implemented in the next few iterations can be left larger and estimated in units such as 13,20,40, and 100.
- Some teams choose to include 0 in their estimation scales.

Four common techniques for estimating are:

1. Expert Opinion
- In this approach, an expert is asked how long something will take or how big it will be.
- The expert relies on his/her intuition or gut feel and provides an estimate.
- This approach is less useful on agile projects as compared to traditional projects.
- In an agile project, estimations are made on user stories or other user-valued functionality. It requires lot of skills by more than one person which makes it difficult to find suitable experts.
- Benefit of expert opinion is that it does not take very long.

2. Analogy
- In this approach, the estimator compares the story being estimated with one or more other stories.
- If story is twice the size, it is given estimate twice as large.
- You do not compare all stories against a single baseline, instead, each story is estimated against an assortment of those that have already been estimated.

3. Dis aggregation
- It refers to breaking a story or feature into smaller, easier to estimate pieces.
- Be careful not to go very far with this approach.

4. A fun and effective way of combining these is planning poker.
- In planning poker, each estimator is given a deck of cards with a valid estimate shown on each card.
- A feature is discussed, and each estimator selects the card that represents his or her estimate.
- All cards are shown at the same time.
- The estimates are discussed and the process repeated until agreement on the estimate is agreed.

How does agile teams estimate the size of the project?

Agile teams separate estimates of size from estimates of duration. There are two measures of size:
1. Story points
2. Ideal time

Estimating Size with Story Points

- Story points are a relative measure of the size of a user story.
- A point value is assigned to each item when we estimate story points.
- Relative values are more important than raw values.
- A user story estimated as ten story points is twice as big, complex, or risky as a story estimated as five story points.
- A ten-point story is similarly half as big, complex or risky as a twenty-point story.
- The most important thing that matters are the relative values assigned to different stories.
- Velocity is a measure of a team's rate of progress per iteration.

- At the end of each iteration, a team can look at the stories they have completed and calculate their velocity by summing the story point estimates for each completed story.

- Story points are purely an estimate of the size of the work to be performed.
- The duration of a project is not estimated as much as it is derived by taking the total number of story points and dividing it by the velocity of the team.

There are two approaches to start with:
1. First Approach: Select a story that you think is one of the smallest story and say that story is estimated at one story point.
2. Second Approach: Select a story that seems somewhat medium and give it a number somewhere in the middle of the range you expect to use.

Estimating Size in Ideal Time

Ideal time and elapsed time are different. The reason for the difference, of course, is all the interruptions that may occur during any project.
- The amount of time a user story will take to develop can be more easily estimated in ideal days than in elapsed days.
- Estimating in elapsed days require us to consider all the interruptions that might occur while working on the story.
- If we instead estimate in ideal days, we consider only the amount of time the story will take.
- In this way, ideal days are an estimate of size, although less strictly so than story points.
- When estimating in ideal days, it is best to associate a single estimate with each user story.
- Rather than estimating that a user story will take 4 programmer days, 2 tester days, and 3 product owner days, it is better to sum those and say the story as a whole will take nine ideal days.

Concept of Project Scheduling - What is the root cause for late delivery of software?

After all the important elements are defined for a project, it is now time to connect all the elements. It means a network of all engineering tasks is created that will enable you to get the job on time. The responsibility for each task is assigned to make sure that it is done and adapt the network. The software project managers does this at the project level and on an individual level, software engineers themselves.

Project scheduling is important because there are many tasks running in parallel in a complex system and the result of each task performed has a very important effect on the work that is performed by other task. These inter-dependencies are very difficult to understand without project scheduling.

The basic reasons why software is delivered late are:
- Unrealistic deadline by someone outside the software group.
- Changing the requirements of customer and not reflecting them in schedule change.
- Underestimate of amount of effort and number of resources required for the job.
- Non considerable predictable or unpredictable risks.
- Technical difficulties that are left unseen.
- Human difficulties that are left unseen.
- Lack of communication or mis-communication among project staff.
- Project management is not able to judge that project is falling behind schedule.

The estimation and scheduling techniques when implemented under constraint of defined deadline gives the best estimate and if this best estimate indicates that the deadline is unrealistic, the project manager should be careful from undue pressure.

If the management demands that the deadline is unrealistic then following steps should be done:
- A detailed estimate is made and and estimated effort and duration is evaluated.
- Develop a software engineering strategy using incremental process model.
- Explain to the customer the reasons why the deadline is unrealistic.
- An incremental development strategy is explained and offered as an alternative.

Estimation Techniques - For Web Engineering Projects

Early estimation is required during planning even though there is a huge chance that these are proven wrong. Some uncertainty is unacceptable and some solid techniques and concrete procedures help reduce the inaccuracy of estimates.

Estimating techniques for web engineering projects adapt the agile process model. Along with the agile estimation approach, a modified function point (FP) measure can be used to develop an estimate for a web application. Roetzheim suggests for web application estimation, the information domain values while adapting function points are:

- Inputs include maintenance screen, input screen or form or each tab using a tab notebook.
- Outputs include static web page, dynamic web page script, each report whether web based or administrative in nature.
- Tables include logical tables in database, each XML object if XML is used to store data.
- Interfaces are logical files into our out of the system boundaries.
- Queries are a message oriented interface and they are externally published.

According to Mendes:
The best way to determine the volume of the web application is by :
- predictor variables that are associated with application like page count, function count, media count,
- web page characteristics like page complexity, linking and graphic complexity,
- media characteristics like media duration,
- functional characteristics like code length.

Empirical estimation models for:
- total project effort
- page authoring effort
- media authoring effort
- scripting effort
can be evaluated by using these measures.

Estimation technique for an Agile Development

In previous posts, we have discussed various methods of estimation such as lines of code and function point. These are typically used for most software projects. But when you consider a project of very short software duration(consider a project which last just a few weeks) and also where there can be changes in requirements during the timeline of the project, it is difficult to use the lines of code or function point method. In such cases, one of the possible estimation technique is called estimation for agile development.

In a typical agile project, requirements are captured as stories or user scenarios; a different estimation method can be used for such projects. Some of the steps that are to be followed in such an agile project are:

- The estimation of each of the user stories is done on a standalone basis. Suppose the overall project has ten different user stories, we would need to do, at the minimum ten separate rounds of estimation.

- Each user story is further sub-divided into functions and tasks. Typically, each task is a separate discrete engineering unit, the start and end of which can be tracked separately from other tasks.

- Each task is a lowest unit at which estimation is done; at the end of the activity all the tasks have estimates. The engineering team is thus expected to provide estimates for each individual tasks.

- All these estimates for a user story are sum to create the total estimate for each user story.

- At a higher level, the estimates of all the user stories are summed to create the overall estimate.

Automated Estimation Techniques and Tools - Functions and types of tools

Automated estimation techniques and tools allows the planner to estimate the cost and effort and to perform what-if analysis for important project variables such as delivery date or staffing. If applying different estimation tools on the same project data, variation in estimated results are encountered. Sometimes, the predicted values are different from the actual values. The output of estimation tools should be used as one data point from which estimates are derived.

The six functions performed by the automated estimation tools are:

- Sizing of project deliverable.
- Selecting project activities.
- Predicting staffing levels.
- Predicting software effort.
- Predicting software cost.
- Predicting software schedules.

These automated tools require an estimate of project size for example LOC and FP. They require qualitative project characteristics such as complexity, reliability, or business criticality. They also require description of the development staff and/or development environment.

- Tools like BYL (Before You Leap) and WICOMO (Wang Institute Cost Model) require the user to provide lines of code estimates and these estimates are categorized by programming language and type. These tools produces estimated elapsed project duration (in months), effort in staff-months, average staffing per month, average productivity in LOC/pm, and cost per month.
- SLIM is an automated costing system based on the Rayleigh-Putnam Model.
- ESTIMACS uses function point estimation method. It helps the planner to estimate system development effort, cost and staff, the risk and the hardware configuration.
- SPQR/20 developed by Software Productivity Research Inc. It has the user complete a simple set of multiple choice questions.

Estimation techniques - estimation using use cases

We have read about estimation techniques like problem and process based estimation techniques. There is another estimation approach that uses use cases which provide insight into software scope and requirements. However, it is somewhat difficult to develop an estimation technique using use cases.

- There is no standard format or style in which use cases can be described because there are many different formats and styles that a use case can use.
- The complexity of the functions are not addressed by the use cases.
- Complex behavior like interactions among many functions and features are not described by the use cases.
- Use cases are used to represent the user's view of the software.

Use case estimation technique for one person can require a lot of effort while use case estimation technique for some other person can be done in a day or two. According to Smith, use cases can be used for estimation but it is only possible and considered within the context of structural hierarchy that the use case describe.

- structural hierarchy can have not more than 10 use cases.
- each use case can have not more than 30 different scenarios.
- before using use case estimation, level within structural hierarchy is established, average length of each use case is computed, type of software is defined, rough architecture is considered.
- empirical data is used to establish lines of code or function point for each level.

Estimation techniques - Process based Estimation

Another technique that is used is estimating a project on the basis of estimating the base on the process that will be used. A process is decomposed into small tasks and effort that is required to fulfill each task is estimated. As apart of this process one is required to take the project scope and derive software functions from the scope. Now typically, for each function, there are a series of framework activities that must be performed. A 2*2 table would typically be constructed which maps these functions and the related framework activities.

Once you get the problem functions and the process activities, the table is filled by estimating the effort for each software activity for each software function. Once you are done with all the estimation, you have a complete table that forms an input for an estimation of the total cost. As a part of this step, you need to have values for the costing for the various activities. As an example, initial architectural and design activities are done by more senior and experienced people, with the costing for these resources being significantly more than the costing for future coding and testing.

Based on the above, we can generate a total cost. We can also generate the total cost through the lines of code and function point methods. Now, we have three methods of costing and can compare one against the other. If these are close to each other, then the estimates are reliable. If this is not so, then more investigation is required. This would require that the steps that have been taken to research and estimate through the lines of code, function point, or process based estimation would need to be re-examined in much more detail until possible errors are detected and estimates re-calculated.

Estimation techniques - Problem based Estimation

In software estimation, lines of code and function point metrics can be used in two ways:
- it can be used as an estimation variable that could size each element of the software.
- it can be used as baseline metrics that are collected from past projects and are used with the estimation variables to develop cost and effort.

Lines of code and function point are different techniques but there are some characteristics that are common. Project planning begins with scope of the software and software is decomposed into problem functions and are estimated individually and then lines of code and function point are estimated for each function.

Baseline metrics are applied to estimation variable and cost and effort is derived. It should be kept in mind when collecting productivity metrics for projects, one should be sure to establish a taxonomy of project types. This will enable to compute domain specific averages making estimation more accurate.

LOC and FP techniques differ in how decomposition is used. Consider a case when LOC is used, it is essential to use decomposition and that too to a fairly detailed level. In order to get a higher level of accuracy, it is necessary to have a high degree of partitioning.

Now considering the case of FP, the usage of decomposition is different. It is required to get the five information domain characteristics, and the complexity adjacent values. Once these are available, and using past data, an estimate can be generated.

Alongside, a project planner estimates a range of values using historical data; these are the optimistic, most likely, and pessimistic sizes for each function. Based on these, an expected value for the estimation variable can be calculated.

A general overview of software estimation techniques...

Few things should be kept in mind while the software project planner begins the project:
- how long will it take?
- how much effort is required?
- how many people are involved?
- what resources are required?
- what kind of risk is involved?
The statement of scope helps the planner develop estimates using one or more techniques that fall into two broad categories:
- decomposition
- empirical modeling.

Decomposition techniques require a delineation of major software functions followed by estimates of either:
- the number of lines of code.
- selected values within the information domain.
- number of use cases.
- number of person months required to implement each function.
- number of person months required for each software engineering activity.

Empirical techniques use empirically derived expressions for effort and time to predict these project quantities. Automated tools can be used to implement a specific empirical model.

By comparing and reconciling estimates derived using different techniques, the planner is more likely to derive an accurate estimate. Software project can never be an exact science but it is a combination of good historical data and systematic techniques that helps in improving estimation accuracy.