1st assignment submitted to Professor Magne Jørgensen on 2010/02/14.

1. Estimation in Agile Project
By Ritesh Man Tamrakar
Date: 2010/02/14
Revision: 1.0
Abstract
Fundamental 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.
References
1.Mike Cohn, Agile Estimation and Planning (Prentice Hall PTR, 2005)
2.Henrik Kniberg, Scrum and XP from the Trenches, Free Online Edition (C4Media, Publisher of
InfoQ.com, 2007)

2. Estimation in Agile Project Revision 1.0
1Introduction
Estimation 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.
2Agile Project
Agile projects are characterized by delivering the value to the customer. Agile Manifesto clearly states
they value
•Individuals 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 for
•Work in short iterations
•Frequent delivery of working software with high priority features
•Welcome change from customer
•Continuous inspection and adapting to change
3Purpose of Estimation
In 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
2/6

3. Estimation in Agile Project Revision 1.0
•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.
4Size Estimation
First 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.
4.1Estimation Unit
There are two units used for estimation of User Stories. They are Story Point and Ideal Time.
4.1.1Story Point
Story 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.
4.1.2Ideal Time
Ideal 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
3/6

4. Estimation in Agile Project Revision 1.0
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.
4.2Estimation Technique
In agile project estimation process group of people get involved. There are different technique to come
up with estimation.
4.2.1Expert Opinion
It 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.
4.2.2Analogy
It 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.
4.2.3Break down the Story
If 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.
4.2.4Planning Poker
In 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
4/6

5. Estimation in Agile Project Revision 1.0
estimation converses.
? card is used if user story scope is not clear. Break card is used to ask for break.
5Velocity Estimation
After 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.
5.1Estimation Technique
In 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.
5.1.1Calculated Based on History
If 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.
5.1.2Iteration Run
Another 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.
5.1.3Calculated Based on Available Man­days & Focus Factor
If 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.
5/6

6. Estimation in Agile Project Revision 1.0
6Re­Estimate
As 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.
6/6