This article discusses estimation techniques for teams that are adopting Scrum. The authors recommend to use story points during the release planning phase, but initially to switch to hours to estimate tasks during the sprint planning. Then the team will gradually move to using story points to estimate complete stories that members will commit for in next sprint.

This short presentation explains why software metrics are not the panacea that we thought they might be 20 years ago. This is why moving from a predictive model to a reactive approach is the only rational course.

Mike Cohn wrote an interesting post where he discusses he allows or even encourages to estimate with story points as large as 20, 40, and 100. He explains that they are useful when you need first and not necessarily precise estimate of the general size of a new project being considered.

Agile estimating and planning in a Scrum project will not prevent your boss from asking: “Will you make the date?”  This video explains how to use Scrum and the “Cone of Uncertainty” to provide an answer like: “60% probability.”

Your team has adopted the relative story point estimation and you are now ready to jump into your first planning poker session. Where do you start? What is a 1-point story? What is a 3-point story? What is a 13-point story? Your team is looking to you and this process is almost as new to you as it is to them.

This blog post explains why for Scrum it is better to drop the time based approach to estimating and specifically the focus on an individual.

This article ties a rather abstract and developer centered concept, the story points, to the financial side of business. Making this connection is essential for management.

This blog post is about how to improve software project estimations by breaking tasks into sizes no larger than one productive day.

“Estimating With Use Case Points” describes the process to measure the size of an application modeled with UML, using use case points.