In this article, I’ll cover how a newly formed Scrum team can transition from estimating in days to estimating in points and velocity. In Waterfall projects, the cost of development is estimated in days using the following formula so that the estimated cost of the project can be provided upfront to the business to justify the ROI.

Project Cost = Number of days to implement the project x Cost of resources per day x Uncertainty

The demand for predictability of the cost is met by the development team as part of upfront project planning during the requirement analysis phase. Development teams are expected to provide a more accurate estimate as they go through various gates. At the beginning of a project the estimate may have a higher tolerance, but as teams approach the final gates, they are expected to provide a more accurate estimate with tighter tolerance level. This expectation causes the development team to spend more time to guess how they would approach the work before they start the development.

The issue with upfront estimation is that the actual development effort might be less or more than what the team had estimated during the planning phase because of the perceived complexity or unforeseen issues. When a team gets the forecast wrong, they are usually questioned about the method they have used and are asked to spend more time on upfront analysis to get their estimate right.

How often your team managed to deliver their work faster and were questioned for overestimating the work? Or how often the complexity of the work resulted in spending more time, that eroded confidence in your team’s true estimation ability.

When a team’s capability is questioned or undermined, they naturally adapt and adjust their practices to prevent it from happening again. Often the easiest solution to prevent either of these scenarios from happening is to overestimate the work and then delay the delivery to match the estimate. This resulting behavior and lack of recognition that a team velocity can change or fluctuate is a major downside of using a single unit of measurement like days.

In Agile, stories are estimated in points using a nonlinear numbering system like Fibonacci series (1, 2, 3, 5, 8, 13, 21, …).

The reason for using Fibonacci series is to highlight the uncertainty in large and complex estimation. If we use sequential linear numbers for evaluation such as the number of days, then we can’t quickly highlight the risk. Using nonlinear numbers also prevents development teams from spending hours over analyzing the risk to come up with an exact estimate.

One of the major benefits of using points when used in conjunction with the team velocity is that it empowers the development team to deliver the project sooner without casting doubts on their original estimation. When we use an Agile point system, the initially estimated story points don’t need to change if the team encounters unexpected complexity or happen to work faster because they have found better ways to burn down more points. The learning from each sprint is incorporated in the next estimation without questioning the validity of the previous sprints estimation points.

Let’s illustrate this with an example. Suppose we want to estimate a large size task that takes around 13 points to develop, but the team is uncertain about potential complexity. If the team use a linear sequential number, they can select 14 or 15 points. Whereas, if we use a nonlinear numbering sequence such as Fibonacci series, then the next number would be 21. This approach forces the team to make a choice, either selecting 21 points or stay with 13 points. More often, in this kind of situations, if the perceived risk were small the team would stick with the original number, and if the risk was high, then they need to think about breaking down the story or select 21 points to highlight the risk.

This straightforward and practical estimation method takes away the need and pressure from the development team to justify a number that by all account is just the best guess. The primary emphasis in Agile software delivery is on the team’s productivity and how fast they managed to burn the estimated points before the end of a sprint.

An empowered team can and will deliver better results.