CSC/ECE 517 Fall 2010/ch6 6c PK

Estimation in Agile projects

Introduction to Agile software development

Software development process or life cycle is a commonly used term in today's rapidly developing software industries. There are different models are available which are used to enforce the structural development of software products. Agile software development methodology is one of the commonly followed practices in project management which takes iterative approach for software development in contrast to plan-based or traditional methods. It mainly focuses on the adapting to requirement changes and delivering in high quality product in iterative work-process. In traditional models such as waterfall model, the project requirements are collected at the beginning of the projects and later implemented. The main problem with this approach is if the customer requirements changes in the middle of development. This may cause lot of rework and impact the planning and deliverable. The adaptive approach of agile development helps to minimize the conflict between requirement and end product. Changing requirements can be easily accommodated in development life cycle as each iteration involves estimation,planning,development and testing. In other words, Agile software development follows an iterative approach where each iteration is mini waterfall.

In this chapter, we will explain the purpose of estimates in agile software development first, later we will discuss estimation techniques and re-estimation and how these are different in other software development processes.

Estimation in Agile Model

estimation in Agile In the agile development estimation plays an important role. sometimes it happens that the requirement for particular sprint are not clear in that case estimation can be difficult. Short span estimation and feedback based estimations are helpful to improve the accuracy of the estimation. Also the it is always recommended to communicate the constrains to customer and get more clarification.

Estimation techniques

Estimation of size

Based on story points In each iteration of the development phase, requirements are called as user stories. The size if the user story is represented by story point.Based on the understanding of the user story, story points are assigned which indicate the how much work is requirement for this work item. These points gives high level work estimate for that sprint. Team collectively decides the points for each work item as 1,2,3,5,8 rather than assigning points independently. These story points are relative and does not have definite formula to calculate it. for example 10 point story 5 times the 2 points story. Story points indicates the complexity of user story, development efforts and risk involves in the development.

There two ways followed in size estimation of the user story. In the first method, select the smallest user story that will be address in that iteration and assign it one point. In the other method select the midsized story and assign approximately size value and then assign points to all the other stories relative to first selected story.

Based on Ideal time In software development, each team member not necessary work on one story for 8 hours per days. Some time is spent in reading email, attending meeting and personal time out. The ideal time is nothing but the time taken to develop, test and accept the user story. As an example, 8 hours of each day can be split as 6 hours for working and story and 2 hours for involving in related activities. The ideal time is not bounded to clock and calender. It is always recommended to estimate Ideal time for each user story rather than for each individual working on it. For example if A,B and C are working in one user story and if we estimates that, A will work for 3 Ideal days, B will work for 1 Ideal day and C will work for 2 Ideal day. The disadvantage of this approach is that each one will start focusing on their work rather than thinking as a team work which deviates from the basic agile team work approach.

For example X and Y are two team members and X think that task A is of worth 3 point while Y thinks that same task is of point 10. The these kind of diverse user stories are discussed in depth to understand why each of them think that way. Sometimes it may happened that Y may think that the work item involves some complexities and some unknown issues hence gave 10 points where X did not anticipate these issues. During discussion of that work item, X will know more things about the system.

In other words, estimating size should be done in the team rather than individual to avoid the fallacies and biased opinion high level estimation.

estimating velocity

Velocity plays vital role in estimation. Velocity is expresses in terms of number of story points delivered in iteration/sprints. For example if certain team delivered 25 points in one iteration then the velocity is 25 for that iteration.

References

• Software Development process [1]