Menu
The Agile Approach to Estimation Agile methodologies/frameworks such as Scrum use story points based on past team velocity to estimate the required effort for completing user stories in a team's product backlog.
Why estimating Agile projects can be more challenging. Traditional project management methods look at estimating in terms of “bottom-up.” You spend time upfront making the schedule, planning out the tasks and deliverables, and then you break down each one and estimate hours and costs starting from the end.
There are three levels of estimation in Agile: Proposal/Project Level – performed during the initial phases of a project. Release Level – plans the release of features bundled to provide frequent and rapid delivery. Sprint Level – planning of the tasks associated with the completion of individual stories in a sprint.
Based on past experience, the team's average velocity is 20 story points per two-week iteration. Dividing 200 story points by a velocity of 20, we can estimate that the project needs 10 iterations. Given that each iteration is two weeks, the estimate of duration is twenty weeks (10 iterations X 2 weeks per iteration).
When working on fixed price software development projects, I frequently find myself having to estimate the total number of hours a project will take after the price is set, but before the work is started (or VERY early on in the development). Unfortunately, these types of projects are best developed using an iterative/agile method, which means that we don’t (and really can’t) do a complete up-front design.
In a typical scenario, we would have a contract that has X features and Y dollars. After contracting, the engineering department would then need to estimate the number of hours required to complete the X features. There are several possible reasons to need this information up front, including:
• The Y dollars translates to Z hours available, so we have to make sure that time(X)<=Z, perhaps by reducing the scope of X.
• The delivery date is set, and so we have to assign the appropriate resources to meet that date.
Kelly Waters has an interesting take on estimating agile here: http://www.agile-software-development.com/2009/04/agile-estimating.html Unfortunately, these are estimations of difficulty, using a points system, and do not translate to hours.
It seems to me that we need to be able to do one of two things:
• Obtain contracts that have a huge amount of flexibility in them to accommodate an agile development process.
• Figure out how to provide reasonably accurate up-front estimates for features that have not yet been designed.
The first option is of course not an option in most cases. Does anyone have any advice/guidance on how to generate up-front estimates in an agile development scenario?
Alternatively, does anyone see another option for solving our problem through some other process change?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With