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?

  • What is your "default velocity"? How are you generating this? For the first sprint, you do need to pull some number of story points into the sprint. However, you don't know what that number is until after your first sprint is finished (and it will likely vary for the first few sprints before settling to some roughly consistent value, ideally). Does this question on how many story points to bring into the first sprint help you at all?
    – Thomas Owens
    Commented Aug 25, 2015 at 11:38
  • 2
    Wrong question. Better ask: is there any reason to believe any estimation you make (by whatever methodology) will be accurate?
    – Doc Brown
    Commented Aug 25, 2015 at 12:16

3 Answers 3


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)


I don't know what a default velocity is.


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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.