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 adapting to requirement changes and delivering high quality product in iterative process which results into high level costumer satisfaction. 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 form of user stories. To check 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 roadblocks during the development. Product backlogs stores a list of to be implemented user stories. Sprint backlogs is used to store users stories in case if certain stories can not be implemented during sprint due to some impediments.

Strengths of agile software development[1]

Adaptive approach

The adaptive approach of agile development helps to minimize conflicts 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 interactions among team members rather that following traditional processes. In addition to that different tools are used which helps to spot the strengths of individual and use it to produce high quality software. The everyday stand-up meetings (also called as scrums) allow developers to interact and get help if there are roadblocks present.

Working Software over documentation

Agile methodology, emphasizes on the working software rather than documentation as it leads to produce enhanced versions of product at each iteration. Users stories can be used as alternative to the documentation as they are written for different features that we are supporting in the end product. Hence less time is invested in developing documents for each feature. Users stories are also used by testers to write manual or automation test cases at the same time as development. In traditional methods, we have to first create requirement document, design document and then test case document and waste lot of time in maintaining the documents.

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. The involvement of customers avails better understanding of requirement to the developers and clarifies lot of gaps. In some cases, end users involves in final testing. For example, lets say some product requires the end user to be registered to use it. While product testing, testers can simulate dummy users and test be it may happen that some time we can not simulate user environment completely, in these situation, we can involve group of actual users and test the working. These kind of flexibility is not available with the traditional development models.

Purpose of estimation

Estimation is essential factor of any development process. The failure or success of end product dependents on 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/iteration 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 work items. Size estimation can be done in two ways such as assigning story points and ideal time.

Based on story points

In each iteration of the development phase, either developed new user stories or get backlogged users stories in to the consideration. each user story is then assigned some number called as story point. These points gives high level work estimate for that sprint. Based on understanding of the user story, story points are assigned which indicates the how much work is requirement for this item. 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. As an example user story with 10 points is five times the user story having 2 points. 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 story points typically is faster

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 on 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 it puts constraints on development time. Moreover, due to this approach each one will start focusing on only their work rather than thinking as a teamwork which deviates from the basic agile teamwork approach. In other words, estimating size should be done in the team rather than individual to avoid the fallacies and biased opinion.

Why Ideal Time Approach :

Ideal days are easier to explain outside the team
Ideal days are easier to estimate at first
It give flexibility for developer to adjust their work hours.

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. Velocity tells us that how much we can complete in one sprint. This estimate is useful for next iteration plannings. This shows that velocity of the project is directly proportional to the good size estimation and understanding of the story.

As an example team A has completed 25 points in there first sprint then while planning for sprint II that team can easily find out how many user stories worth total of 20-25 points can be considered. Now as per the planning for sprint 2, team selects user stories worth 22 points. However due to some unexpected obstacle, at the end of the sprint, team A could complete only 17 points. In this case, unimplemented user stories are pushed back to backlog to consider in later sprints. For planning of sprint III, team A will definetly learn from its past and plan accordingly. It is always a good idea to keep some buffer for unexpected events.

Estimation techniques

The three most common techniques for estimating are

Expert opinion

In this technique, experts opinion can be considered to estimate how long some feature will take time to complete. Often this is useful if the team members are new to certain technology. Though this approach is simple and quick, its is not suitable for agile development as the estimates are decided based on user stories and not tasks. This can be used in traditional development model where the estimation is tasked based. One more disadvantage of this technique is sometimes its really hard to find as right person with desired expertise hence may involve some delay in planning and estimation process.

Analogy

This technique involves comparing users story for size estimation. Every new story gets compared with previously estimated user stories to find approximate estimation about that story. In other words, if new user story U1 has complexity,risk and efforts twice the user story U2 then the size of the story U1 is approximately twice the size of U2.

Disaggregation

Sometimes users stories can be very complex hence needs to be broken in to smaller task or stories. This process is called as disaggregation. The normal range of the story is recommended as two to five days. Bigger stories are not only difficult to estimate but also there are very less stories available to compare to, which limits the usage of Analogy techniques. Smaller users stories on the other hand can be estimated very well. However, we should not too far in splitting up the stories as number of small stories increases, it has to go through lot of estimation efforts. If possible really small related stories can be merged in to one good size story.

Planning Poker

Planning poker combines above three approaches in playful manner. The main participant are programmers, tester and other related members from development team. At the benigging of the poker, each member given deck of card with 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100 numbers on it. To estimate uses stories, each member select number from card and show it to the team. This number indicate the worthiness of that user story from that member's perspective. If the opinion about the story are diversified then team members discuss these type of users stories and mitigate the differences. As an example consider 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 13. 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 13 points where X did not anticipate these issues. During discussion of that work item, X will know more things about the system.

Planning poker can be played at two different times, first at the beginning of every sprint to estimate the items to deliver at the end and second, during the estimation of new stories based on on-going development.

Re-estimation

Re-estimation is mostly done in the last phase of each sprint but it is not mandatory. An ideal agile project will never required re-estimation, however this intangible. In practice, we have to follow this approach at some point of the time. Reasons for re-estimation :

When relative size changes

In this scenario, lets say the velocity of is estimated as 11 and during development, team member realized that some of the users stories are more complex that they though hence will take more point and more time hence could not complete in the present sprint. Due to this, the estimated velocity will more that 11 which is not achievable in that sprint. In such scenario, the re-estimation is required.

For partially completed stories

Re-estimation is required when only part of the user story can be completed by team. In this case, the story needs to be divided in smaller task and re-estimation for the newly created tasks should be done.

Estimation in Agile vs traditional Models

Agile methodology has incremental approach to handle any software development process however most of the traditional development model does not follow this approach. Traditional approach miserably fails in project where the requirement are frequently changing. Hence choosing the right development process is a backbone of any product design.

The above diagram depicts the differences between agile methodology and traditional SDLC models. In both models, at the start of project, requirement analysis and feasibility study is done. Based on that, traditional approach focuses on creating requirement documents while on the other hand, agile methodology creates number of possible user stories. These users stories can be a good source of information about certain requirement hence no need to have separate documentation. Next step is for effort estimation, where traditional system follows Man hours(bound to actual calender) while agile approach follows ideal man time [Refer section 3.2].

Based on the selected user stories the system design is developed. Where the traditional model creates the entire systems design at the beginning based on gathered requirements. Single requirement change may impact design in large scale. Traditional method does not allow any changes once requirement and design are fixed while agile method is adaptable to changes. In agile, planning and estimation for testing is also done at the same time and can be adaptable, while in traditional methodology, test palling is done at the beginning of the development.