There is often debate as to whether to use ideal days or story points to estimate agile software projects. My personal preference is for story points.
Software estimation is the measurement of relative size and complexity, not duration.
Story points are a pure measure of the size of a feature. They do not state how long a particular feature will take to implement. The combined ability, or velocity, of the team determines how many points can be achieved in a development cycle, or sprint.
By working with size, rather than directly with duration, we can focus on expressing how much effort is involved in implementing a particular feature. This makes estimating a much quicker process and reduces the likelihood of an estimate being turned into a guarantee. Also, story points tend to belong to the whole team, whereas estimates in days or hours are often targeted towards the abilities of a particular person.
Knowing the relative size of a feature allows us to better determine its place in the release alongside other features. This gives us a forecast for a release that we can use to prioritise tasks and construct a release schedule.
During sprint planning, the team can then choose stories to implement in the sprint period (usually 2 or 4 weeks), based on business priorities. These stories can then be broken down into their constituent tasks and delegated to team members, or put into a task pool. By working in short iterations, it is much easier to determine the tasks required to develop a particular story and the estimated number of hours to complete each task, than if we were breaking down the entire project.
You don’t want to have to re-estimate because your initial estimate was wrong. If you estimate that you can complete 20 story points in a sprint and you only complete 15, you can assume you can complete 15 on the next sprint. If you estimate a story to take 5 days and it takes 10, then what about the other estimations on the board?
By sizing up a software project using story points, we get a better understanding of the complexity of a project and therefore determine a more realistic schedule that can adapt according to the progress of the team.
For more information on this topic, I highly recommend the book Agile Estimating and Planning by Mike Cohn.
Tim Ross - Software Developer 