CSC/ECE 517 Fall 2010/ch6 6c sg: Difference between revisions

Latest revision as of 06:04, 18 November 2010

Estimation in Agile Projects

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.(4) The features are tested in their entirety for eg. "find the average grades of a student over entire semester" and not "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.

Units of Agile Estimation

Use of User stories in estimation

A user story is a short description of something that the customer will do when they use the application/software,focused on the value or result they get from doing this thing.User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them.

What is size estimation

In Agile estimation, the first and foremost thing that is done is estimating the size.While estimating the size of a user story one has to take into account all activities need to complete the story right from design and coding to testing and documentation.

What is velocity estimation

Velocity estimation talks about how fast the user story can be completed.5 Velocity is measured in terms of story points and ideal days.It is basically the total story points or ideal days completed in an iteration.The number of iterations required to complete a project can be obtained by dividing the total story points by velocity.Story points will be explained later.Velocity stabilizes and provides tremendous basis for improving the accuracy in project planning.

Story point

Story point gives the relative measure between stories.6Estimating in story points is typically faster because it is relative.It is a simple number which tells you how hard or easy a story is.A story point can be explained using relative terms like "small,medium, large" or using powers of two or Fibonacci series. e.g 2 Story Point User Story is twice as big as 1 Story Point Story.

Ideal time

As the name suggests, ideal time is the time required to complete a story without any interruption and everything that was needed was available.Advantage of ideal time vs elapsed time is that it is easier to estimate in ideal time.For example, a user story will take 24 hours ideal for completion. But if the developer puts 6 man hours every day then the total elapsed time is 4 days.

Layers in Agile Estimation

The 3 significant layers in Agile estimation and planning are 7

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.(8)
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

Different estimation techniques based on size are as follows:

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 and 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.(9) 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 start to 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.

Different Estimation techniques for velocity

Different estimation techniques based on velocity are as follows:10

Use of history

In here, use of historic data is made. Basically compare the current story with the one that has been completed before and get the relative velocity. For eg. if "x" story was complete in 2 days then since "y" story has all the factors and requirements doubled it will take 4 days to complete. But this method can only be used only if the same set of team has worked on both the projects and have made use of same technology.

Iteration run

Observe the velocity during an iteration run and estimate accordingly.

Making use of available man days and focus factor

This technique is used when there is no previous Historic record of any project to refer to. First we go about calculating the man hours required and then according to the given focus factor one can get the correct velocity.For eg. there are 10 team members each working for 10 days then the total man days is 10 x 10 = 100. But according to the focus factor the ideal productive time is say 70% and hence the actual value turns out to be 70% of hundred which is 70 days.

Re-Estimate

With time there is extra information available for a particular story.If the original understanding of the story was flawed then after getting a better insight into the story one can re-estimate.Hence, the new schedule will be more accurate and after updating all the stories their might be an effective increase in the velocity of the team.

@@ Line 1: / Line 1: @@
-= Introduction =
+== Estimation in Agile Projects ==
+__TOC__
+== 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: [http://agilemanifesto.org/ 1]
@@ Line 11: / Line 14: @@
 *Responding to change over following a plan.
-= Why do estimation =
+== Why do estimation ==
-Planning is a very important aspect even for Agile projects. According to Stellman & Greene [http://www.stellman-greene.com/aspm/images/ch03.pdf 2] , estimation can also be called as “Black Art”. What it means is that, 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.
+Planning is a very important aspect even for Agile projects. According to Stellman & Greene [http://www.stellman-greene.com/aspm/images/ch03.pdf 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 ===
+[[Image:Agile Model sg.jpg|right]]
+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 [http://en.wikipedia.org/wiki/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.[http://www.itsadeliverything.com/articles/agile_project_estimating.htm (4) ]The features are tested in their entirety for eg. "find the average grades of a student over entire semester" and not "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.
+== Units of Agile Estimation ==
+=== Use of User stories in estimation ===
+A user story is a short description of something that the customer will do when they use the application/software,focused on the value or result they get from doing this thing.User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them.
+=== What is size estimation ===
+In Agile estimation, the first and foremost thing that is done is estimating the size.While estimating the size of a user story one has to take into account all activities need to complete the story right from design and coding to testing and documentation.
+=== What is velocity estimation ===
+Velocity  estimation talks about how fast the user story can be completed.[http://www.versionone.com/Agile101/Velocity.asp 5] Velocity is measured in terms of story points and ideal days.It is basically the total story points or ideal days completed in an iteration.The number of iterations required to complete a project can be obtained by dividing the total story points by velocity.Story points will be explained later.Velocity stabilizes and provides tremendous basis for improving the accuracy in project planning.
+=== Story point ===
+Story point gives the relative measure between stories.[http://agilefaq.net/2007/11/13/what-is-a-story-point/ 6]Estimating in story points is typically faster because it is relative.It is a simple number which tells you how hard or easy a story is.A story point can be explained using relative terms like "small,medium, large" or using powers of two or Fibonacci series. e.g  2 Story Point User Story is twice as big as 1 Story Point Story.
+=== Ideal time ===
+As the name suggests, ideal time is the time required to complete a story without any interruption and everything that was needed was available.Advantage of ideal time vs elapsed time is that it is easier to estimate in ideal time.For example, a user story will take 24 hours ideal for completion. But  if the developer puts 6 man hours every day then the total elapsed time is 4 days.
+== Layers in Agile Estimation ==
-= Traditional vs Agile approach =
+The 3 significant layers in Agile estimation and planning are [http://www.mountaingoatsoftware.com/system/presentation/file/53/SDWest2007_AEP.pdf 7]
-= Layers in Agile Estimation =
+[[Image:Layers.jpg|right]]
-Thus, it helps in initial project planning. The 3 significant layers in Agile estimation and planning are
 === 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.
@@ Line 30: / Line 59: @@
 Daily planning involves inspection of daily progress and planning  for removing the obstacles faced in the process if any.
-= Cone of Uncertainty =
+== 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.
+*Greater the uncertainty , greater is the range.[http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/ (8)]
 *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”.
-= Units of Agile Estimation =
+== Different Estimation techniques for size ==
-= Different Estimation techniques for size =
+Different estimation techniques based on size are as follows:
 === 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.
-=== Analogy ===
+=== 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.
@@ Line 47: / Line 76: @@
 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.
+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 and 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.
+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.[http://www.mountaingoatsoftware.com/system/hidden_asset/file/15/aep_sample.pdf (9)] 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.
+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 start to 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 =
+== Different Estimation techniques for velocity ==
+Different estimation techniques based on velocity are as follows:[http://www.slideshare.net/ritesh.tamrakar/estimation-in-agile-project 10 ]
+=== Use of history ===
+In here, use of historic data is made. Basically compare the current story with the one that has been completed before and get the relative velocity. For eg. if "x"  story was complete in 2 days then since "y" story has all the factors and requirements doubled it will take 4 days to complete. But this method can only be used only if the same set of team has worked on both the projects and have made use of same technology.
+=== Iteration run ===
+Observe the velocity during an iteration run and estimate accordingly.
+=== Making use of available man days and focus factor ===
+This technique is used when there is no previous Historic record of any project to refer to. First we go about calculating the man hours required and then according to the given focus factor one can get the correct velocity.For eg. there are 10 team members each working for 10 days then the total man days is 10 x 10 = 100. But according to the focus factor the ideal productive time is say 70% and hence the actual value turns out to be 70% of hundred which is 70 days.
+=== Re-Estimate ===
+With time there is extra information available for a particular story.If the original understanding of the story was flawed then after getting a better insight into the story one can re-estimate.Hence, the new schedule will be more accurate and after updating all the stories their might be an effective increase in the velocity of the team.
+== External Links ==
+*[http://www.drdobbs.com/architecture-and-design/223100694 Dr. Dobbs, Estimation on Agile Projects ]
+*[http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development Wikipedia ]
+*[http://publicationslist.org/data/a.abran/ref-2068/pres-1061.pdf Improving Estimations in Agile Projects: Issues and Avenues]
+*[http://www.stellman-greene.com/aspm/images/ch03.pdf Applied Software Project Management]
+*[http://www.zdnetasia.com/comparing-traditional-and-agile-project-management-estimation-techniques-62202850.htm Comparing traditional and Agile Estimation techniques]
+*[http://www.itsadeliverything.com/articles/agile_project_estimating.htm Agile project estimation]
+== References ==
 *[http://agilemanifesto.org/ (1) Manifesto for Agile Software Development]
+*[http://www.stellman-greene.com/aspm/images/ch03.pdf (2) Applied Software Project Management]
+*[http://en.wikipedia.org/wiki/Work_breakdown_structure (3) Work breakdown Structure]
+*[http://www.itsadeliverything.com/articles/agile_project_estimating.htm (4) Agile Project Estimating ]
+*[http://www.versionone.com/Agile101/Velocity.asp (5) Velocity Estimation in Agile ]
+*[http://agilefaq.net/2007/11/13/what-is-a-story-point/ (6) Explaining a story point ]
+*[http://www.mountaingoatsoftware.com/system/presentation/file/53/SDWest2007_AEP.pdf (7) Agile Estimation and planning by Mike Cohn, Mountaingoat Software ]
+*[http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/ (8) Agile Estimation and Cone of Uncertainty ]
+*[http://www.mountaingoatsoftware.com/system/hidden_asset/file/15/aep_sample.pdf (9) Techniques for Estimating , Mike Cohn]
+*[http://www.slideshare.net/ritesh.tamrakar/estimation-in-agile-project (10) Estimation in Agile Project,Ritesh Tamarkar]

CSC/ECE 517 Fall 2010/ch6 6c sg: Difference between revisions

Latest revision as of 06:04, 18 November 2010

Estimation in Agile Projects

Contents

Introduction

Why do estimation

Traditional vs Agile approach

Estimation in Traditional project management

Estimation in Agile project management

Units of Agile Estimation

Use of User stories in estimation

What is size estimation

What is velocity estimation

Story point

Ideal time

Layers in Agile Estimation

Release planning

Iteration planning

Daily planning

Cone of Uncertainty

Different Estimation techniques for size

Expert’s opinion

Using Analogy

Disaggregation

Planning Poker

Different Estimation techniques for velocity

Use of history

Iteration run

Making use of available man days and focus factor

Re-Estimate

External Links

References

Navigation menu

CSC/ECE 517 Fall 2010/ch6 6c sg: Difference between revisions

Latest revision as of 06:04, 18 November 2010

Estimation in Agile Projects

Introduction

Why do estimation

Traditional vs Agile approach

Estimation in Traditional project management

Estimation in Agile project management

Units of Agile Estimation

Use of User stories in estimation

What is size estimation

What is velocity estimation

Story point

Ideal time

Layers in Agile Estimation

Release planning

Iteration planning

Daily planning

Cone of Uncertainty

Different Estimation techniques for size

Expert’s opinion

Using Analogy

Disaggregation

Planning Poker

Different Estimation techniques for velocity

Use of history

Iteration run

Making use of available man days and focus factor

Re-Estimate

External Links

References

Navigation menu

Search