Complexity is a direct indicator of software quality and costs: if the complexity for any code is high, the quality of that code will be lower and it will cost more to manage it. Complexity measurements can be used to estimate development and test activities and to decide where refactoring is needed to improve quality and prevent problems.
Estimations are used by agile teams and product owners for prioritizing work and to plan releases of products. They can be done on different levels and in various ways.
The results of software estimation are important for stakeholders to take care of team allocation and budgeting. A widely prevalent technique to estimate in Agile has been Planning Poker, which is a consensus based. Does this way of estimating take too much time? Are there other methods which can be employed by experienced practitioners?
In a recent thread on the Scrum Development mailing list, Paul Battison asked whether his team should re-estimate completed stories after the sprint is done, so as to have the team's velocity reflect the actual effort that went into completing the stories.
The age old problem of software "estimation" has generated some interesting discussion lately in the agile community. J.B. Rainsberger, Arlo Belshee, Josh Kerievsky, David Anderson, and others ask the question "Are estimates really needed at all?"
One of the great things about working as a consultant is the ability to try out many different ideas and adapting your personal favorite process to include things that work. This article gives the details about user story estimation techniques that Jay Fields has found effective.
Joel Spolsky recently posted an article about Evidence Based Scheduling. The post focuses on managing and identifying good estimates, in turn allowing the project manager to forecast the probability of delivering on a given date, adding a new method of measurement to the agile project manager's toolbox. InfoQ investigates the theory behind the practice, and its implementation in FogBugz 6.0.