CSC/ECE 517 Fall 2010/ch6 6c PK
Estimation in Agile projects
Introduction
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.
Above diagram depict typical model of Agile software development. Agile development life cycle is divided in number of iterations called as sprints. The approximate duration is 2-4 weeks for each sprint. Each sprint includes planning, development, testing and acceptance for feature deliverable. These features are represented in the for of user stories. To ensure status of sprint, daily scrum meeting are conducted where team members share the status of user story they are working on and if there are any roadblock during the development.
Strengths of agile software development
- Adaptive approach - 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.
- Individual and interaction - The agile software development model values each individual in team and iteration among team members rather that following traditional processes and tools which helps to spot the strengths of individual and use it to produce high quality software.
- Working Software - Agile methodology, emphasizes on the working software rather than documentation as it leads to produce enhanced versions of product at each iteration. Customer collaboration is an important part in agile as compared to traditional software development model.
- Collaboration with customers - In this, all the parties involved are always working to achieve same goal. In case of negotiation based approach, customer and actual development team may face gap in the requirements and end product.
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.
Purpose of estimation
Estimation is essential factor of any development process. The failure or success of end product is dependent of the estimation and planning of the development process. In the agile development includes release planning, iteration/sprint planning and everyday scrums. To do these planning, different estimations are required. One of the most important building block of agile software development is interaction between all the involving parties such as developers, testers, management and stockholder. Release meeting, sprint/interation planning and daily scrum plays an important role in estimation for development process. 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 it is always recommended to communicate the constrains to customer and get more clarification.
Estimation of size
Size estimation can be done by assigning point to user stories and by estimating the time required to complete the tasks. Size estimation helps to understand what everyone feels about or notice about items.
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.
 |
 |
Figure 1 shows how the users stories can be analyzed based on complexities, doubts and efforts while Figure 2 shows relative points assigned to them. User story 1 and 2 has same story points assigned. Though in user story 1 has more complexity and doubts than users story 2, it has comparatively less efforts. On the other hand user story 2 has less complexity and doubts but more efforts hence the over all size estimation is same for them. On the contrary, user story 3 has more complexity, efforts and doubts hence story points are higher than rest of the two.
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.
Why User Story points Apporach :
- Story points help drive cross-functional behavior
- Story point estimates do not decay
- Story points are a pure measure of size
- Estimating in story points typically is faster
- Ideal days are different from developers to developers
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.
Why Ideal Time Apporach :
- Ideal days are easier to explain outside the team
- Ideal days are easier to estimate at first
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.
Estimation techniques
The three most common techniques for estimating are
- Expert opinion
- Analogy
- Disaggregation
Re-estimation
Agile vs traditional Model
References
- Software Development process [1]