Estimation in Agile ProjectBy Ritesh Man TamrakarDate: 2010/02/14Revision: 1.0

AbstractFundamental approach of Agile Project execution is totally different than traditional project. Agile project wants to deliver high value features in frequent release done after fixed iteration cycle. For Agile Project's planning there is need of relative size estimation of each stories of the project. It is purely estimation of size. Story points is mostly used for it. It does not contains time information. For scheduling, there is another estimation need called Velocity. Estimation of size and velocity help for prediction of schedule. They are also used in iteration and release planning to decide which user stories to put in that iteration.Different technique can be used for estimation. Mostly analogy is used for estimation of size. For estimation of velocity, run of an iteration is more preferred.

ReferencesMike Cohn, Agile Estimation and Planning (Prentice Hall PTR, 2005)

Henrik Kniberg, Scrum and XP from the Trenches, Free Online Edition (C4Media, Publisher of InfoQ.com, 2007)

IntroductionEstimation is never easy and always considered to be some kind of art. Estimation done in traditional phase based project are mostly proved to be widely varied when measured in actual implementation. Agile projects have different value system and approach in project management so is its estimation process. Agile projects are found to be more successful in delivering value to its customer.This report presents estimation in the context of agile project. It briefly covers agile project characteristics and its estimation need. It explains estimation of size and velocity in detail.Agile ProjectAgile projects are characterized by delivering the value to the customer. Agile Manifesto clearly states they valueIndividuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Above value system motivates Agile projects forWork in short iterations

Frequent delivery of working software with high priority features

Welcome change from customer

Continuous inspection and adapting to change

Purpose of EstimationIn start of every project, someone has to decide about viability of a project. The basis of that go/no go decision is based on estimation of cost and schedule. Agile project's initial rough estimation serves the same purpose. It also help in initial project planning.In Agile project, as there has to be continuous adaptation to change, there are many layers of planning. They are Release Planning: Plan for release date and features in the release

Iteration Planning: Plan for features put in the iteration

Daily Planning: Inspection of daily progress and Plan for removing impediments

For Release Planning, estimation of delivery capability of the team is need. In agile term it is known as Velocity. Estimated Velocity and estimated total feature size helps to predict the actual time required for delivery of the features so it helps to fix the release date.In Iteration Planning, estimation of velocity and size of each feature is used to decide to pick feature for implementation in the iteration. It also helps product owner to prioritize among feature and some time change the scope of the feature to meet the time line.In Daily Planning, changed task level remaining hours estimate helps track the progress of the project.Size EstimationFirst thing one has to do in estimation of agile project is estimating the size. Unlike traditional project, agile project delivers in the unit of feature. Mostly feature are described as User Stories. Each User Story has some business value for the customer. In planning, selection of User Stories for particular iteration or release depends on its size.While estimating size of any User Story, one has to take account of all the activity need to be done to complete the User Story. Complete means User Story is designed, coded, tested and documented. When User Story is said done, it is in the ready state of delivery to the customer.Estimation UnitThere are two units used for estimation of User Stories. They are Story Point and Ideal Time.Story PointStory Point is simply a relative scale to measure the size of an User Story. It does not have any physical significance. 2 Story Point User Story is twice as big as 1 Story Point Story, thats all. Since unit name does not have any particular meaning, some time it is referred as bucks, points, Gummi Bears.Estimating using Story Point is faster, drives cross-functional discussions and consistent among different person and time. It is pure measure of size.Ideal TimeIdeal Time is time required to complete an User Story if there is no interference during work. Ideal Time is totally devoted to do the work. If an User Story is estimated to take 1 Ideal Day then that User Story requires 1 full day work time. Time required of email checking, meetings and design discussion should not be counted. In reality those extra work exists so actual elapsed time to complete the User Story will be more than Ideal Time.Estimating using Ideal Time is easier to understand for person outside of the team and easier to start estimating. It also has draw back as there could be pressure to match ideal time with calendar time. Meaning of Ideal Time between different person could be different.For simplicity, sometime 1 Story Point is considered equivalent to 1 Ideal Day.Estimation TechniqueIn agile project estimation process group of people get involved. There are different technique to come up with estimation.Expert OpinionIt is based on gut feel or intuition of an expert. One explains the User Story to an expert. Then the expert clarifies issues by asking question. Then the expert provides the estimate according to his/her experience in past or gut feel. It is very fast approach.It is very less useful in context of agile project as in agile project estimation need to be done for user stories which require cross functional work. So single expert's estimation will be less valid.AnalogyIt is based on comparison between user stories. It is difficult to come up for few initial stories. But after few estimate all other user stories are just comparing with estimated stories and assign the estimate. Comparing is more easier than defining exact size of the user story. Story Point also favors this technique.Break down the StoryIf user stories are very big and estimating it gives less value then estimation can be done by breaking down the stories into small stories. Stories with 2-8 days estimate is more valuable than single big story with 100 days estimate. Many stories with small estimate also makes tracking much easier.Planning PokerIn actual estimation mixture of all of the above technique are used. Mike Cohn has developed a simple game to make estimation easy and fun. It is called Planning Poker.It is group activity usually done during iteration or release planning. Deck of card with 13 cards each are distributed to participants. Cards have 0, , 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Break got printed.Product owner selects high priority user story and explains its scope to the group. Each participants does estimate for the user story and put his/her size estimate using card facing down. After everyone come up with estimate card, those cards are revealed. If everyone has same estimate then that estimate is recorded. If there is high difference, each estimator explains their estimation and Product owner clarifies if there is some misunderstanding. After this same process is repeated until all members estimation converses. ? card is used if user story scope is not clear. Break card is used to ask for break.Velocity EstimationAfter doing size estimation, another estimation needed is how fast team can complete those user stories in an iteration. There is special term for it is Velocity. Velocity is total story point or ideal days completed in an iteration. Velocity helps to find out stories that could be done in an iteration. Total story points divided by velocity gives number iterations need to complete the project. Iteration are of fixed length so multiplying duration per iteration by number of iterations gives total duration of the project. Estimation TechniqueIn starting of a project estimated velocity is important. After some iterations, observed velocity it self can be used. There are different approach for velocity estimation.Calculated Based on HistoryIf the team has done similar project before one can use velocity of previous project as estimate for new project. There will be varying velocity in single project. So one can use average of those velocity or use minimum and maximum as range for velocity estimate.This technique has some limitation of application. If the new project has different set of team or new project is working on totally new technology then historical velocity has very less use.Iteration RunAnother way of estimating is to observe the actual iteration. During the starting of the project there will be some time to finalize the project requirement and such. During that time obvious stories could be developed and velocity of the team observed. This observed velocity can be used for estimating velocity.Calculated Based on Available Man-days & Focus FactorIf there is no previous project and can not run iteration before then there is only one choice is to compute the velocity from available man-days and focus factor.In this technique, first available man-days of the team is calculated. If there are 4 full time person working on 10 days iteration then available man-days is 40 man-days. To convert it to Ideal Days we have to remove unproductive time from it. For this use use focus factor. Focus Factor shows how much one can focus on given task. By default, for starting one can choose as 70%. So total ideal days in an iteration is 70% of 40 man-days. It is 28. So estimated velocity is 28.Re-EstimateAs project progresses one gets exact data on how difficult or easy to complete the user story. If relative complexity is different than expected then one has to re-estimate the size of the user stories. While re-estimating one can update all other similar user stories. If one can do re-estimate correctly derived schedule will be more accurate. Re-estimation is not to be done to only the increase the velocity of the team. If one increase the value of completed user stories to higher the velocity and correspondingly increase all the remaining stories as well then remaining total story point also increase. So there will be on effect of increased velocity. Same number of iteration will remain.If only completed user stories value is increased then whole size estimation will be inconsistent so calculated remaining iterations comes incorrect value.Estimation in Agile ProjectRevision 1.0/