Yes, you can (and do) estimate Scrum projects. [Note "Scrum" is an English word, not an acronym or abbereviation. It should not be in all-capitals.]

You estimate a Scrum project this way.

1. Write down the backlog.

2. Break the backlog into sprints.

3. Prioritize the sprints from most valuable to least valuable.

4. Provide this prioritized list of sprints to the customer.

They are free to stop work at any time, since each sprint is useful and the first sprint is the most useful and important part of the system.

That s the estimate. It s theirs to manage.

For a given budget you know how much iterations can be done. The Product Owner should then prioritize the work to get the most value of the product backlog. This is how Agile works, fixed time and team size with variable scope (Agile is about scope management). And once the team velocity is known, you can forecast how much work (in points) can be done (# of sprints x velocity = size of the work that can be achieved).

Often, customer don t get it and wants "everything they think they need at a given time" (i.e. fixed scope). In this situation, you end up doing some kind of upfront analysis to brake down everything into small enough items to estimate them. Once this work has been done, you can forecast how much sprints you ll need by guessing on the velocity (# of sprints = total size / velocity). This is a very common situation for people with a waterfall background and will often lead to inaccurate end date (fixed scope and team size with variable time) because you can t really guess the velocity and the start of a project is the worst moment to do estimates.

In both cases, you ll need the velocity. The problem is that the velocity is actually 1) unknown before the team start to work and 2) will vary over time.

To solve 1), you could estimate guess the velocity as discussed in the second situation but this isn t very "Agile". Ideally, you should instead get the team start working to measure the actual velocity (which will be likely inaccurate during early iterations). An intermediary scenario is to give a first very rough estimate and to come back to the customer after a few iterations with a more precise one, once you ve gathered more knowledge about the project and reduce the uncertainty.

To solve 2), I track measured velocity over time and use the highest and lowest velocity and the average velocity of the last 3 sprints as work hypothesis. This allows me to do optimistic, pessimistic and realistic forecasts (respectively).

Absolutely, in scrum you fix cost and time. Then you let the features vary. So you can tell the customer it will be done on XX/XX/XXXX at a cost of $YYY.YY. It is up to them to then prioritize the features they want to ensure the most important ones get done under those constraints.

Yes and No. I believe that Scrum is a great approach in getting the owner involved in the planning of the sprints.

So in the case of estimation, it would be difficult to say "we ll get the project done in 30 days". Instead, the owner will have an expectation on what will get done say in the first and second given week, and a perception of what will get done in 30 days.

In my opinion, this is more valuable than giving an estimate of 30 days and then being lucky, or way off the mark.

Also, you ll have a WAY better estimation of what will be done in the near future. Another great thing about Scrum is that you can tailor your deployment to possible alter or remove items to have a more usable product after 30 days, than potentially something completely unusable using waterfall.

It depends on what you want to predict.

You can promise that a n-week sprint takes exactly n weeks and m sprints take n*m weeks. Therefore schedule estimation is easy. Cost/effort estimation is also easy, given a certain team size and project duration. What you cannot reliably promise is what features eventually get delivered and what don t.

There are four main control variables for a project: scope, cost/effort, schedule, quality. You can choose which variables are the drivers (i.e. fixed) for your project and which are not. You cannot have them all as drivers at the same time at least one variable needs to be kept free to allow for balancing the project.

With traditional waterfall you have fixed scope (the spec) and usually a fixed schedule (target date). You can balance the project by increasing cost/effort (e.g. adding more people, working overtime) or taking shortcuts in quality. These balancing factors do not behave linearly and you get problems in other areas if you push them too far.

With agile including Scrum you have fixed schedule (iterations or sprints) and fixed quality level (definition of done). Cost/effort is proportional to how many people you have in the team. Scope is the main balancing factor. It has the nice property of behaving quite linearly: increases or decreases in scope do not cause hugely non-linear changes in the other drivers. The key to success is feature prioritization to get the maximum value out of the scope you can deliver.

As Steve McConnell says in Software Estimation, whenever you need to provide an estimate:

1. Count
2. If you can t count, then compute
3. If you can t compute, then judge

"Expert judging" or reckoning is a last resource. Try counting real things and/or referring to historical data to compute a meaningful figure.

This is applicable regardless of the method you use, be it Scrum or whatever else.