Estimation In Agile Project

Estimation In Agile Project

• 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