Whether I’m trying to estimate how long it will take to do a house project or a software development project, estimation is a whole lot easier if you’ve done a similar task to the task you’re trying to estimate. Once you have a baseline, you not only have gained skills in accomplishing that task, you can use the data from that first “iteration” to help you estimate the time it will take to do similar tasks.
In Chris McMahon’s recent tip, How Agile estimation works, he talks about assigning points for user stories. He gives an example of adjusting over time based on the accuracy of the estimations for each iteration. Early in the development cycle, it may be more difficult to accurately estimate what it will take to deliver the stories. Over time, the team will become more experienced and will have a better idea of what they can actually accomplish with each iteration so their estimations will become more accurate.
Lyssa Adkins, in her new book, Coaching Agile Teams, also makes this point when she describes one of the differences between traditional project management beliefs versus agile beliefs. In traditional project management, “the plan gets more accurate over time as we flesh out the project through phases of activity: requirements, design, development, testing, and so on.” This is replaced with the agile belief, “a plan gets more accurate over time because it is constantly revised and trued up to the team’s actual performance.”
Mike Cohn also spoke about this not too long ago at a Denver Agile User Group meeting. You can read about it on our blog: Mike Cohn on estimating software in Agile environments.