For those of you who are already familiar with what Agile Software Development is but have had difficulty on pinpointing how to give estimate this blog is for you. PMI's bible the Project Management Body of Knowledge (PMBOK) defines a project as a temporary endeavor taken to create a unique product, service or result. Further it explains that temporary means that a project has a definite beginning and end. Agile is somehow perceived as a methodology which forgoes the temporary nature in favor of perpetuity, but this is not the case. In a pure agile paradigm it can be perpetual, but in reality all good things must come to an end.
It is well understood that agile projects undergo the same phases of the Software Development Lifecycle, but a much smaller scale. Each Scrum is a definitive endeavor. Project estimation is a function of scope, time and budget. But what if the scope is not known?
Most custom software projects do not start out in a vacuum. Generally a client has a set of features that are known and yes, a set that is not. We can only work with what we know.
Think of each Sprint as a separate waterfall project, and a "project" as a collection of Sprints. Before Agile, this would have been called phased work. Large software projects were broken down into phases; each phase can implement a new set of functionality or build on previous phases. For example Phase one could include a database change that is not used by current functionality and the business logic is added in phase two. Sprints can be done in any order without affecting the effort required to perform the sprint. Some sprints will require sequencing, but this too does not affect effort.
Start the estimation with a list of known features. Do your estimate based on Waterfall. Here is where it starts to get tricky. Figure out the probability that other features will be required and guess at the scope of these features. Past experience with projects with similar features is indispensable in achieving an accurate estimate. Add these wish list items to your original estimate. When you have the effort in days, add 15 minutes for each team member per scrum frequency. For instance, if you do a daily scrum with four team members, add one hour per day to the original estimate.
Probability of adding a feature determines the probability of going out of scope, over time, and/or over budget. The waterfall estimation itself is not free from risk. Thinking of your agile projects as phased waterfall projects should improve the results of your estimates - it may not be perfect, but it is an improvement.