CSC/ECE 517 Fall 2010/ch6 6c sg

Introduction

Agile software development is a conceptual framework for undertaking software engineering projects. Agile methods try to overcome the weakness found in Classic software development methodologies such as the waterfall model by using an iterative and incremental development approach. Most of the agile methods try to minimize the risk involved by developing the software in smaller time frames also known as iterations. Each iteration lasts for around one – four weeks. The characteristics of Agile manifesto published in 2001, by a bunch of software engineers can be summarized as follows: 1

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan.

Why do estimation

Planning is a very important aspect even for Agile projects. According to Stellman & Greene 2 , estimation can also be called as “Black Art”. What it means is that estimation is highly subjective; the time required to finish a certain task varies from person to person. A certain individual might take a day to do a task that might only take a few hours of another’s time. Any estimate that is not close to the actual time required is a bad estimate. But a good formal estimation of cost and schedule improves the accuracy of the results and increases the likelihood of the project being delivered on time.

Traditional vs Agile approach

Estimation in Traditional project management

Transition between the estimation techniques is often considered as the toughest part when organizations switch or migrate from traditional to Agile project management.In the traditional approach, the main objective is broken down into several tasks by the team. It is also known as Work breakdown structure 3. After that the experts predict the time required for each individual task.Project activities are then allocated and project team members start working on them.As the work progresses people realize that the initial estimate was incorrect.In the traditional waterfall model approach,there would be no looking back and the developers will deliver the product regardless of its quality(which is bound to be bad).

Estimation in Agile project management

Agile project management involves team work, collaboration and most important of all,process adaptability throughout the life cycle of the project.Estimation in Agile project management is typically feature based unlike task based in the previous approach.The features are tested in their entirety for eg. "find the average grades of a student over entire semester" over "calculate average" task.Also the estimate focuses more on relative size i.e. explaining things on a "small, medium or large" scale and not on providing the absolute time in hours or days. Estimation in Agile projects is an iterative process. Many experts talk of the planning onion i.e planning by day at the center, expanding out to planning at iteration level and then release level planning.Hence, the team incorporates in the plan what is learned from every iteration which also includes feedback from the stake holders thus creating self correcting and self regulating plans.The team also tries to improve the product as well as working methods in each successive cycle.

Layers in Agile Estimation

The 3 significant layers in Agile estimation and planning are 4

Release planning

Estimation of velocity is required and total feature size is expected. Usually to estimate the size of the products one needs to estimate the set of User stories that have been prioritized into next release. One needs to produce 2 estimates for each story, viz.

• The 50% estimate - This is the estimate in ideal days whereby the estimator feels confident that this estimate for completion of the story (design, develop, test, document) is equally likely to be under as over. This could also be thought as average estimate.

• The 90% estimate – This is the estimate in ideal days whereby the estimator feels 90% confident that the story will be completed (in other words that 90 times out of 100 thus story can be done in that ideal number of days). This is also known as the worst- case estimate.

Iteration planning

Here, estimation of velocity and size of each feature is performed. When the iteration is to be planned, the Product Manager and the Development leads can agree a theme for the iteration/sprint and can select the candidate stories from the estimated backlog that initially fit the available velocity of the team and that make the most sense to tackle together. Then in the iteration planning meeting these are presented to the team as a whole in order to get a next level down estimate. This involves the team breaking down the user stories into tasks and then estimating the tasks in ideal hours (for reference, and ideal day has 8 ideal hours).

Daily planning

Daily planning involves inspection of daily progress and planning for removing the obstacles faced in the process if any.

Cone of Uncertainty

• We need to give ranged estimates which reflect the amount of uncertainty in the information on which the estimates are based on.
• Greater the uncertainty , greater is the range.
• With progress in the project , the amount of uncertainty goes on reducing and hence the range of estimates goes on decreasing i.e you tighten your range as the project progresses.
• According to Barry Boehm this known as the “cone of uncertainty”.

Different Estimation techniques for size

Expert’s opinion

The Expert’s opinion is the simplest and fastest of all techniques. While using this technique, an expert on that topic is asked how long the project will take or how big the project will be. The suggestion or judgment given by the expert depends on the historic data or previous projects(if available) his or her intuition or gut feelings and experience. In Agile projects , we make use of some user-valued functionality like user stories. For implementing this kind of functionality more than one person is required. Hence, we need experts who can do evaluation across all disciplines. According to a source there is only 60-70% probability that the estimate given will correct in this case.

Using Analogy

This is the technique for relative estimation(involves comparison between two stories). For example , if a user story is twice the size of some other story then the estimate is doubled for this story. Statistics say that relative estimate works better than Expert’s opinion. One has to understand that is no specific benchmark or a standard with which the comparison is done. Instead each story is compared with assortment of ones which have already been estimated. This is also known as triangulation where one story is compared with multiple others.

Disaggregation

Disaggregation refers to splitting a large story which takes unusually large amount of days into smaller stories which take less days which are then much easier to estimate. If in a particular project most of the stories has range for say 2-4 days then for estimating one story which requires say 50 days is a tedious task. There is not only a problem with comparison since not many stories of comparable size are available to compare the given story with but also chances of the estimation being correct decrease.

Planning Poker

Planning Poker is touted as the best of all four methods which is used often by teams to perform estimation. In here, we find a combination of the previous three viz. expert opinion, analogy anf disaggregation as well as a more reliable estimate than them. All the team members secretly propose an estimate for the user story in question. This technique is a consensus based technique and might take several rounds for the estimates of all the members to converge. It is expected that each member decides individually and is not swayed by other member’s estimate. This technique is similar to Delphi. This methodology was first described by James Grenning in year 2002 and later popularized by Mike Cohn in his book “Agile Estimation and Planning”. Here, every estimator is given a deck of cards. The cards might have numbers from Fibonacci series say 1,2,3,5,8,13,21.. or power of two say 1,2,4,8,16… The moderator explains the story to the team and asks for their opinion or if they have any questions. After all the questions are answered, each estimator privately selects a card representing his/her estimate. All the cards and shown afterwards so that all participants can view each others estimate. In the first try, the estimates vary significantly but as the discussion progresses the opinions startto converge. Planning Poker works more effectively than other techniques because here the those who will do the tasks , estimate the task also justification is sought for the estimates.

References

• (1) Manifesto for Agile Software Development
• (2) Applied Software Project Management
• (3) Work breakdown Structure
• (4) Agile Estimation and planning by Mike Cohn, Mountaingoat Software