English 中文(简体)
How do you estimate an agile project up front? [closed]
原标题:

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?

问题回答

I think every client wants to have at least an estimate of how much the implementation of a given number of feature will cost him. I don t agree with people that say that if your using agile than you can t do this. Agile can be adapted to the real world where clients want to know how much money they re gonna spend on a project, or at least have a rough idea.

So, there are at least two documented ways you can do this and both are described in the "Agile Estimating and Planning" book by Mike Cohn that i strongly advise everyone to read.

  • Before your project even starts do the exercise of breaking down your stories in tasks and estimate each home in hours. Do the budget math with those estimates. Keep in mind that these estimates will only be used to reach the estimate time/budget. When the project starts the team should be responsible for estimating and creating the tasks like normal.

  • Use historical data. If the same team has worked before on a project with similar technology then you can use the past team velocity to estimate the project cost.

Again, for more details on how to do this read the referenced book.

Big Upfront Estimation is just Big Upfront Design with $$$ attached

You don t, that would go completely against the entire paradigm of agile.

Agile can be about Fixed Costs

What you can do is set a date and then work torwards it in iterations/sprints and let the product owner(s) decided what is important to get done by that date. In this way a Sprint of 1 or 2 weeks is a Fixed Cost the same way it would be in an Big Up Front Design would be, it is just a smaller fixed cost.

The entire premise behind agile methodologies is to do away with arbitrary deadlines and the death march that they become because change is not accounted for in the contracts and deadlines. SCRUM works, is a great starting point to build a methodology on, read about it and do what it says at least as a starting point.

Short Sprints with customer feedback and approvals

Give you a starting point to refine your future estimations upon, and helps you gain trust from the product owner and customer very quickly, because they see their most important concerns delivered in a very short amount of time.

Fixed price in Agile gives you a number of iterations you can run for a given team size. The point of Agile is then to maximize the value you can get during these iterations. Agile is about scope management.

So, you actually shouldn t do upfront estimations. This would mean fixed scope which is the just the opposite of Agile or anti-Agile if you prefer.

Agile doesn t work like this, you need a new kind of contract, as pointed out in another answer. See for example 10 Agile Contracts and/or google.

Instead of aiming for a contract for the "entire" project, you should create a contract that just runs for a month or two.

Set some very low goals, perhaps only two or three features.

Explain to the client this is a discovery phase of the project. Without this phase you cannot give them an estimate for the entire scope. It would be in no ones interest to give them an inaccurate estimate.

The client benefits in the following ways:

  • Lower upfront cost (only a fraction of the total price). If things go tits up there is a limit on their financial exposure (sensible given that most software projects fail).
  • Have working software within a couple of months that may immediately solve some of their problems
  • Have working software to provoke thought/conversation about requirements
  • Client will discover more about what they actually want
  • Client gets to see how well you work. If they don t like it they can look elsewhere.

"you don t, that would go completely against the entire paradigm of agile": I think this is quite incorrect. Agile is common sense based and nobody would invest in project if they had no idea how much it would roughly cost: they understand they may have to cut scope to meet deadlines or increase budget and/or extend deadlines to deliver the whole scope. On my company projects, we estimate projects by comparing their size and are also estimating epics using poker planning. Using the cone of uncertainty, and without trading off quality, we are about maximum 50% off on our estimates prior to starting the first sprint compared to the reality. And we will improve as we build up our Agile expertise (on accuracy and time to get first estimates). You can t expect marketing to sponsor projects for 3 sprints (so up to 3 months) to have an idea of how much it would cost.

If you estimate the backlog items in story points (which is discussed in the Kelly Waters article you link to) then the question becomes how many story points do you expect your team to deliver in a sprint. If your team has been working together before, then you should be able to take a guess at this (perhaps with upper and lower bounds to indicate a confidence range).

If the team haven t worked together before, then you can take a few well-understood stories and break them down into detailed tasks. This will give you a man-hours number and you can compare this against your story point estimates to try and predict your velocity. Again, a confidence range of upper and lower values is probably appropriate.

Let s suppose your user stories add up to 150 points, and you predict that your team can deliver 15-20 story points per month, then the work will take 7.5 - 10 months (through simple division).

The advantage of this approach is that you can measure the team s actual velocity, and compare it to the plan. Re-estimating you timelines should also be pretty easy, e.g. if you discover after a couple of sprints that the team s velocity is actually only 10 story points per month, then you can easily predict what your revised timelines will be.

Do bear in mind that team velocity does fluctuate for a number of reasons. It is typically lower at the start of a project when the team is still forming. Also the team is most likely concentrating on infrastructure concerns at this point rather than delivering functionality.





相关问题
Kanban/Scrum Boards [closed]

I m curious as to what other people use for physical Kanban/Scrum boards in their companies. I appreciate that because of sensitive business information you may not be able to provide a photo of the ...

How do you estimate an agile project up front? [closed]

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 ...

How would you use AGILE here? [closed]

I am a big proponent of agile, but a friend of mine (who doesn t know agile yet - hes a managerial type ^^) asked me how I would go about planning and developing a complex distributed project, with a ...

What is Object-Oriented Methodology? [closed]

I have been looking at different programming methodologies: Scrum, waterfall, spiral but someone told about one called Object-Oriented. Now as far as I know that s a paradigm and not a methodology. ...

Scrum and Project estimated time [closed]

IF the client asks me for a estimated time for completion for the whole project can this be given using Scrum? Using for instance the (dreaded) waterfall methodology I will have a technical spec to ...

热门标签