Sometime a client want you to estimate how much the budget will take and how long the app will be ready. Estimation might not be precise but it will be worth to see the capability of your team to solve the project. According to Boehm (2000) estimate software can be defined as a cone of certainty. you can estimate precisely when you are in the end of the project (and I guess it will become so clear since you already do the project).
As you can see in the first installment of the project your estimation will be 4x wrong or 1/4 better. For example, you estimate that the cost for your development is $1000. If you are in initial concept you might be spend $4000 (4x) or just only $250 (1/4x). The same technique can be applied in time, if you expect you need 40 days you might get 160 days or just 10 days. Interesting huh.
You can use the cone of estimation just like McConnell in his book (please see references). Or you can use Global eXtreme Programming technique to estimate the project. This post will discuss the basic,
The Art of Agile Estimation in GXP
Global eXtreme Programming is a software framework that you can use to adopt eXtreme Programming Agile method in global or distributed environment. If you don’t know about GXP you can download the publication here. The GXP estimation will take five step and I barely sure that you can follow it with an easy.
Step One- Get the user story
If you are using user story in your requirement gathering you are in a right way, but if you are using use case not to worry this method is just same. Writing down any requirements in user story and use case. just browse my post to know about how to create user story or read this book to learn about user story here
Step Two-Estimating The Effort
This is the main effort of the estimation. The estimation somewhat complex but you can do it easily/ I saw several team use COCOMO, FP, or even user story estimation. If you want to read more about the estimation model you can read and buy this book. Trust me is really valuable
Agile Estimating and Planning
Step Three-Having The Priority
You already estimate it now prioritize it.The common priority model is using MOSCOW model or rank model. MOSCOW model is good enough when you have really limited time to tackle many user story in a release.
MOSCOW = MUST , OUGHT , SHOULD, COULD, WON’T
The idea of the MOSCOW approaches are done by mapping the user story with the one of MOSCOW component.
Step Four-Measuring The Team Velocity
This step will measure the velocity. Team velocity can be measured if you have a solid team. It is imposibble to measure the velocity if your team is in dynamic shape (easy come and easy go). The formula to measure the velocity is simple. Just do as follows:
- Write down the performance on each project iteration. i.e. 20 stories for 2 weeks in project A.
- Find the best of three, the bad of three, and the average. write it down in your log book
- Calculating the average. The result should be like this; 20 stoies in the best condition, 15 stories in normal conidition, and 13,5 in bad condition
you can read a good book about the estimation in eXtreme Programming here
Step Five-Giving THe Realistic Estimation
Time to polish your estimation. Realistic estimation is done by measuring the good, the bad and normal conidition just like in ste four. It is mean that when you estimate something you should state about the worst case too. For example, when you can achive 2 months project in normal condition. It will be great if you tell the client about the possibility to deliver in a late one. You can estimate the lateness by measuring the teamm when in a bad condition
Having a question, just drop me an email or put your comment below. Thank you.