Velocity for small projects

Question

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.

Answer 1

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.

Answer 2

Smaller iterations will allow you to get a better measure of velocity as they provide more data points. The tracking does not have to be elaborate a simple burn down chart will give a quick graphical look at velocity.

Answer 3

If you're doing a three month project with month-long sprints, you'll only be able to use your velocity calculation for two sprints. But if you're using two week sprints, you'll have five sprints where you can apply your velocity calculation. With shorter sprints you get more data points.

As a developer, I like to track my velocity on everything. It gives me some idea of how uncalibrated my time estimating skills are. I'm now able to apply my historical velocity to my new estimates, making those estimates somewhat more reasonable.

As a team member, I like to know how well my teammates estimate time. I've worked with people who consistently underestimate their time by a factor of five or more and it's important to know that in advance if you want to avoid unpleasant surprises.

So yes, I've found velocity to be important on any size project.

Answer 4

Using velocity for planning basically just depends on a minimal number of iterations to be valuable. But that's true for other feedback mechanisms, too - incorporating new learnings into the running project needs frequent checkpoints, which are provided by the end of iterations. So, for smaller projects, your iterations should be smaller, anyway (independtly of the number of intermittent releases). I once worked on a two week training project, where we used two-day iterations. Worked quite well.

Will using velocity provide value to you? Well, that's kind of hard to tell from here. On the one hand, if your estimation process already works well, it might not. On the other hand, perhaps it would work even better. Or it would work just as well, but take less effort. Also keep in mind that Scrum (as other processes) is a package where the different components support each other - so, although your current estimation process serves you well, it might work less well in a Scrum process, or compromise some other aspects of Scrum. And, not knowing what exactly to expect from a Scrum project, you might not even notice that it's the estimation process that's the problem.

So, taking the above into account, it might make sense to try velocity for some time and see how it works for you. You can always go back and try your old way again. Remember that "inspect and adapt" is an important part of Scrum. Just don't forget to inspect before you adapt.

It might also be a good idea to get someone on board who has some experience with Scrum. It's typically much easier for them to identify anti-patterns and come up with effective adaptions.