Estimating Team Project Velocity in an Agile Project, based on 3 factors
A daunting task of project management, during the project release planning stage, is estimating how long a project would take to complete, which heavily depends on how long it will take developers and testers to complete story points. Working out the iteration capacity is what is called team project velocity.
There are three ways in which you can estimate team project velocity, with historical data, through continuous iteration adjustment, and forward estimation.
Whether you are able to pre-determine velocity or not depends on how well you know your team. If you have historical data, and granted, you will need to have all variables consistent from previous projects when you go into this one, such as the same team composition, technology and nature of project, and whether the method of how the units of work were estimated previously remains the same. Regardless of which factor you choose, it's best to estimate velocity in terms of range rather than an absolute value.
Continuous Iteration Adjustment
When you don't have any historical information to lean on (and even if you do, sometimes it's better to start with new and more accurate data), you can plan your project so that the first one or two iterations, prior to providing the project stakeholders with a firmer project duration estimate. You can put in a few stories into initial two iterations, observe how the team progresses, which will not give you the benefit of understanding the team velocity, but also hone in on your story-board complex value estimation.
If you are able to hold off on giving an estimate and allow the project to commence it's first two iterations, it will yield long-term benefits for your project fore-casting later on.
In true agile spirit, you can continuously evaluate the team velocity per-iteration and adjust accordingly. Remember, it's best to estimate in a range as opposed to absolute value, so you can see from iteration one a certain range is associated for the velocity, and if the team maintains a continuous effort and result, you gain some consistency in your estimation. If the team struggles to maintain it's initial value, you may have over-estimated the velocity range, and so forth.
The final factor in project velocity estimation is Forward Estimation, where we don't have historical data, nor the afforded ability to run a few iterations to calibrate our velocity range estimation. This is the riskiest proposition of the three, according to Mike Cohn in Agile Planning and Estimating.
Estimating the number of hours worked involves working precisely how many hours of the day the resource can be devoted to this project. This is expressed as a percentage (i.e 70% of the work day).
You then multiply the the number of hours available each day(like 8 hours) by the number of people on the team. You then multiply that by the number of days in the iteration, and you will get your final number of hours available for the 10-day (two week) iteration.
You then expand the story points, fitting as many as you can whilst ensuring it doesn't exceed the total number of hours you just worked out for the 10-day iteration, breaking down stories into tasks and filling out the iteration assignment. As Cohn then suggestions, you add up the story points and then you can work out what the probably velocity of the team is. So, let's say we worked out 240 hours within the 10-day period as our capacity, we worked out story points that would fit in 221-hours, we work out the complex value of each point, we would get a value, let's say of 25.