I currently learning about scrum and want to learn from experienced professionals in the subject.
Is velocity relevant for project that take 3 month (and usually have 2-3 intermediate deliveries to customer) ?
I think it's not enough time to make a statistic relevant. Is it worth to record velocity per developer across the project to get enough depth for statistic ?
Another question is velocity really so important for small projects?
We have a lot of experience in our field and our estimation are quit accurate. The only problems we had was related to risks factor that sometimes hit you, but we know our risk and know how to handle it, i don't sure that scrum will help with the hardware problem on customer board.
I do see a lot of logic in other parts like small iteration, contiguous integration having product/project management to be very close to development process and i think that we are doing a lot of things by scrum already without knowing it.
So the bottom line i don't see if scrum as whole concept is fit my needs, but i do see that i can use a lot of concepts (i really liked the backlog) to make our development process better.
Actually it's rather discussion than question, but SO is not designed for this so if it's not appropriate I'm apologies.
So, to split your question into two parts:
1) Is Velocity worthwhile in a 3-month project? Yes, I think it is. I've worked on teams where most projects were 2-6 months in length. We had one-week iterations, but I know teams that are as short as 3-days. However, there is a movement in the agile community towards a more Kanaban pull-type system where specific iterations aren't as necessary. I'd say start with iterations and then reevaluate
2) So I need velocity when we have good estimates? Probably not, given you are on shorter projects. But when something is 20 hours, and it takes you 10 days because you could only work on it 2 hours a day, then you basically need to calculate velocity using something different anyway.
I'd highly recomment the XP and Scrum Development mailing lists.