When estimating with a fresh team on a new project, is there a reason not to use default velocity for estimating?

Question

Generally when estimating using an Agile points system on an experienced project team, the points have meaning relative based on past experience - that take into account:

• understanding of the business domain
• skill and experience of the team
• obvious traps in the technical environment (service integrations and environment issues)

So based on the past velocity of the team - you can forecast how long a project is likely to take.

Now imagine a completely new team thrown into a new business problem domain, new technical environment, with unknown skill levels. You can estimate with points, but you have no velocity track record.

Now you can augment this lack of historic velocity with a 'default velocity' - with the caveats that the three factors above are unknown, and so your tolerance for delivery date is much higher.

But is there an agile reason not to do this?

My question is: When estimating with a fresh team on a new project, is there a reason not to use default velocity for estimating?

Answer 1

Yes there is a reason - because a default velocity is meaningless.

The velocity is the speed at which your team can progress tasks, but that measure is created by using the sped at which your team has completed tasks. That's the only way of calculating a velocity.

So by using a default one, you might as well stick your finger in the air and say "finished by Tuesday", or "107534 points per sprint".

You start off with a blank velocity and work out what it is as you go. By the end of the project you'll know what the velocity of your team is. Unfortunately, until the end of the project that velocity value will just be an estimate that gets progressively more accurate (ie you start off with a wildly wrong number, and it gets closer and closer to reality after each sprint)

Answer 2

I don't know what a default velocity is.

But...

You got to start somewhere.

New team on a new project. Everyone estimates to the best of their knowledge, and with short iterations (say 1-week sprints) by 3rd week you should have a vastly improved understanding of your velocity. First 2 weeks will be a mess.

Answer 3

In my opinion the velocity during the first sprints is meaningless, because the team is normally busy with other things in the so called Forming and Storming phase. Dealing with velocity from the beginning may frustrate the team members even more. The best time is to bring in velocity during the Norming Phase.

See: Tuckman's Stages of Group Development