Estimating software projects has been a challenge for a long time. Estimating in hours is frequently inaccurate and requires a lot of upfront work before engineers are comfortable even giving an estimate. Design work and requirement details are needed and it usually yields mediocre or poor results.
Agile recommends a different approach referred to as “relative sizing”. Teams size User Stories in Story Points, typically a Fibonacci sequence or T-shirts sizes. The idea is to size a user story relative to other stories they’ve completed in the past. This means avoiding the natural desire to relate it to time, which is a difficult hurdle to get past. It is designed to be quick and not involve over thinking. It is also designed to use a team consensus. It’s very important that the team sizes and not eager management or Product Owners that provide or influence the size. Overtime the accuracy will get better as the team learns and adjusts.
As a team completes a Sprint, the total number of points they completed is considered velocity. This will also get more consistent over time. The team will learn from taking on under-sized and over-sized stories. Sprints that carry-over unfinished stories into the next Sprint means their estimate was too aggressive or they undersized the work. With retrospectives and practice, the team will take that information into the next Sprint and start to hone their ability to size and predict velocity with better accuracy. Then the business can predict outcomes better because they can use average velocity of the team to determine what they will get and when.
Work-Agile 