CSC/ECE 517 Fall 2010/ch6 6c VP

Estimation in Agile Projects is calculated approximation of result and approach to result in agile projects which can be used even if complete and certain data is not available at the start of the project.

What is agile project methodology?

While computer software has become a driving force for the modern world, software development itself is not a perfect process[1]. Today, software development has gained pace and needs to become more flexible. To meet the needs of today’s customers, a new software development methodology called Agile Software Development[2] has come into existence. Agile methodologies is a completely different approach compared to the traditional software development methodologies. Agile means quick and active. Agile methodology is based on iterative development, where whole team collaborates to decide on requirements and solution to solve a particular problem. Agile project management is an application of these Agile software development ideas into project management.

Open source project 'Expertiza' is a very good example of agile methodology application. Every group work on some part of currently working 'Expertiza' project to add more features, to make it more enhance or to correct functionality. They work on it around 2 to 4 weeks and add that functionality in existing project. After every such iteration we get working model which can be used in real life where as there is scope to decide on new features or more corrections which can cause more number of similar iterations. This process can be referred as agile method.

How agile projects are different from projects

As discussed earlier agile methodology is totally different than traditional software development methodologies. This is due to the fact that unlike traditional techniques, agile process works in iterations, each of which are of a short time frame and do not involve long term planning. Iteration period differs from team to team and all project participants view themselves as one team to achieve the goal[3]. In agile process, the stages are also slightly different from that of the traditional processes like Waterfall Model. The 5 stages that are described in the agile development methodologies can be defined as follows

• Envision[4]: This is the phase where the team visualizes the requirements through a data sheet. This is analogous to use case list in UML.

• Speculate[5]: This phase is to provide a general direction of the project and begin the planning phase. Though it is similar to that of waterfall model, the plan is broken down into short iterations based on the features.

• Explore[6]: This phase acts as an execution phase in the life cycle. The distribution of work, technical practices, team development are all done during this phase. This is different from the Implementation phase of the waterfall model as it focuses on the complete dynamics of the project.

• Adapt: In this phase, all the corrections and changes that are to be made are applied to the project. This can be analogous to the testing phase in waterfall model. The major difference here is that the results of this phase are sent to the re-planning of the next iteration.

• Close: The objective of this phase is incorporate the learning of this iteration or project into next iteration or passing it on to the next project team.

Coming back to 'Expertiza' example which can also be done in traditional way where we can decide on all features we want in 'Expertiza' and then plan how can we get them done in single iteration. But here we had to know all requirements at the beginning of planning which is not realistic approach. This is where agile process differs from traditional approach.

In case of an Agile approach, the entire work is divided into iterations. Consider that there is a task which is to be completed within 3 weeks. The requirements that are available are listed and the Envision phase is done. Next there is a series of iterations each having the Speculate-Explore-Adapt phases. After every Adapt phase, new changes or fixes are added to the Speculate phase of the next iteration. After these iterations are done the final Close phase is reached. These steps are explained further with the help of the figure below:

Purpose of estimations

Consider a student appearing for paper test where during test he comes to know that there are 20 minutes left and he has to cover 20 more subjective questions. He approximates that he can give 1 minute for each remaining question whereas in another approach for same situation he looks upon how much marks each question carried, which questions carried more marks and how much time those questions may take to complete. Accordingly he concentrates on fewer questions but completes them correctly. Later approach may take some time from 20 minutes but still it will work better towards achieving good marks in test. This example signifies how estimations are important.

Before starting project the very obvious questions that arises is 'How long will it take to complete this?' which is not so easy to answer. One might give a range saying 'It may take around 10 months to 2 years'. Anyone listening to this starts expecting it close to 10 months but do not take into consideration of range up to 2 years. This consideration may cause problems if this estimation do not turn right. This is the major reason projects need to be estimated to reduce uncertainty[7]. All further processes including planning, design, scheduling rely on these estimation which may turn unchangeable.

Estimation is critical step of any software development project irrespective of its size specially in agile processes where duration of iteration is very small compared to traditional processes. Planning plays a prominent role in deciding on the investments, availability of the resources and customer values. In any case, good estimation leads to good planning. Estimation of cost and schedule is the deciding factor when it comes to whether a particular feature has to be implemented in an iteration.

There are 3 types of planning namely: Release planning, Iteration planning and Daily planning.

Release planning

Both size and velocity estimations are helpful for release planning phase. The estimation of the capability of a team to deliver the product in the given time is called Velocity. This velocity combined with the total feature size, which is another estimate of project will help in deciding the release date.

Iteration planning

The major focus of iteration planning phase is to decide on the features that are to be selected for the current iteration and which one’s are to be moved to the next iterations. This phase of planning helps the product owners to prioritize the features and redesign the scope of the project if required.

Daily planning

Traditional methods decide on scope and delivers all features together whereas agile projects deliver in units of features. These features are described as user stories and user stories has business values for customers. This phase is mainly used to track the progress of these user stories.

Estimation in agile projects

Agile process separates estimation of size from estimation of duration. Initially, estimation of size is done and it is followed by estimation of duration. Both these estimations are done at 'user story' level.

Size Estimation

The size of a particular user story is determined after considering all the activities that are needed to be done to complete that user story. These activities include all the phases like Envision, Speculate, Explore and Adapt.When the user story is completed, one can assume that a part of the feature to the customer is completed. As with any estimation technique, size estimates has certain units which are as follows:

Estimation units

1. Story point - Story point is a random measure used by team to rate each user story and they are actually of no physical significance. This unit signifies the efforts required to complete the user story. As its unit do not give any significant meaning sometimes it is referred as bucks or points. This point system is a relative scale. It has no effect of any variance in time or team size and hence this unit is consistent among different person and time. After few estimations when team gets stable story points, estimation of further user stories becomes fast and easy.

Example, If one user story carries 3 story points other will get 5 points as in comparison current user story will take more time for test.

2. Ideal time - This is absolute scale to measure estimation. The ideal time is the actual time needed to complete a user story in an ideal case i.e., without considering any interrupts. Generally ideal time gets calculated in days or hours. It is practically observed that the actual elapse time is greater than the ideal time. Due to its absolute nature is it easy to understand this measure for person outside the team but meaning of ideal time may vary from person to person.

Example, Even if there are 2 user stories to be estimated, each user story will get ideal time independent of each other say 3 days and 5 days respectively.

Velocity Estimation

Velocity is the term which is used to describe the estimation of the capability of the team to deliver. Total story points or ideal days completed in an iteration is referred as velocity. It helps us to determine the scope of each iteration and total duration of the project. The equation to find the total number of iterations to complete the project is given by the total number of story points divided by the velocity. Here, the length of each iteration is fixed and hence the total duration of the project can be calculated by multiplying the duration of each individual iteration by the total number of iterations to complete all user stories defined in a project.

Estimation techniques

The best estimate for any work can be given by person who is actually going to work on it. Hence unlike traditional estimation techniques where one or few teammates get to involve in estimation, agile processes believe on estimation done by the entire team itself.

Techniques for Size Estimation

The different techniques that can be used to carry out size estimations are given as follows[8]:

1. Expert opinion: As the name explains, these are the judgments of the experts in that particular fields. One of the teammate explains the user story to expert and then they discuss about it at length. All the doubts and clarifications are done and then depending on the experience and expertise of the expert, the estimate is provided. This type of estimate, though, is very less useful in agile methodology as a single person’s estimation does not get considered as valid.

2. Analogy: The estimates are provided upon comparisons between different user stories. Though it is a bit difficult initially for the first few user stories, it works fine for all other user stories where the only work is to compare with previous user story estimates. This method is favorable for user story estimation

3. Break down the story: This estimate works when user stories are too big to get an estimate directly. In that case, the story can be broken into small user stories, called as tasks and estimates can be calculated for each of these tasks to evaluate points for one big user story.

this also makes tracking easier during iteration.

4. Planning poker[9]: This is an easy method of estimation developed by Mike Cohn. It is a group activity either done at either the iteration planning phase or the release planning phase. Each member of the team carries a deck of 13 cards. These cards have 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, break on them. The high priority user stories are sorted listing highest priority user story at the beginning and the lowest priority story at the end. After he/she explains the scope of that user story, each participant puts the estimation card facing down. After everyone gets some estimation, these cards are revealed. If the estimation given by everyone is same then it is recorded. In case where there is a high difference in the estimations, then each teammate explains their estimation and the reason for that score. They resolve the differences and start the process all over again. This process is continued till all estimates comes to close estimation. The ? card is used if scope is not clear and participant cant estimate the time.The break card is used to ask for break.

Techniques for Velocity Estimation

1. Calculated based on history: Empirical data of same team can be useful in calculating velocity. Either average or range between maximum and minimum can be considered. The limitations with this technique is that the project has different set of team or if its project with completely new technology then this method will not be useful at all

2. Iteration run: Observes actual iteration. During the beginning of the project, teams provide at the beginning team provides some time developing obvious user stories observing team velocity. This observed velocity can be used for further estimation.

3. Calculated based on available man-days and focus factor: Initially calculates the number of man-days available for an iteration. This is calculated multiplying total number of members working in that iteration with number of working hours for each member.Consider only productive time. In order to remove unproductive time use focus factor. Focus factor is a metric to decide how much each person can focus on given task. So if we consider 70% as the focus factor, then it shows total ideal days in iteration is 70% of total man-days which is estimated velocity.

Re-estimation

As the user story progresses further, the team comes to know more about the exact data and implementation details. There could be a difference between the estimated size of the user story and the observed complexity. If the difference between these two is large enough, then it is required to re-estimate the size of user story. Also while updating a particular user story estimates, all the other user stories that may be affected due to this or the stories that are similar to this can also be updated. Correct re-estimations makes schedules more accurate.

When not to re-estimate

Care must be taken by the team in re-estimating. One must not re-estimate solely because the progress is not as rapid as they have expected it to be. The team can leave most of these inaccuracies to the velocity estimate.

When to re-estimate

During the project, there may be situations where there may be a user story that has not been completed in the iteration that it is supposed to complete in. Consider that the unfinished portion of the story is not done in the next iteration, in that case the remaining story is re-estimated, based on the knowledge about the project that the team already have[10].

Advantages of agile size estimation

Agile software development is the new norm in companies as it has many advantages over the traditional waterfall model. Estimation is an important aspect in agile development and its advantages in a company can be listed as follows:

• All the estimates are done by all the members of the team. So it is more like the team estimating their own work and doing their planning by themselves.

• The major concentration of these estimates is on delivering values and establishing trust between business and project teams.

• These estimates informs the business about all incoming changes.

• Using the size estimations reduces overall risk in project.

Disadvantages of agile size estimation

Though the size estimation is advantageous, there are some problems or disadvantages of it. These can be enlisted as follows:

• As the estimation is done by the entire team this task needs a lot of horizontal communication. In teams where the size is relatively small, this is an easy task to achieve. But in teams where there is a large group working on a project, it makes it difficult to do this estimation[11].

• Switching from the traditional method of development to the agile development is a time taking process.

• This development methodologies requires high level of customer involvement.

• In certain projects where there is a static requirement set, the agile development is almost equivalent to that of the traditional methods. Shifting to Agile for such projects would not cause any advantage.

References

1. Tsun Chow, Dac-Buu Cao, A survey study of critical success factors in agile software projects, v.80 n.6, June 2008 [doi>10.1016/j.jss.2007.08.020]
2. Agile Development
3. Agile Project Management
4. Envision Phase
5. Speculate Phase
6. Steps in Agile Development
7. Agile Estimation by Alex Young
8. Ritesh Man Tamrakar, Estimation in Agile Project, February 2010
9. Planning Poker
10. Mike Cohn, Agile Estimating and Planning,2005
11. The Agile Debate