Jeff Sutherland, one of the fathers of the scrum methodology, has a post about how to use velocity and story points to get estimates.
Basically, developers are apparently hopeless at estimating the time required to complete tasks, so people should use points instead of hours, which will allow accurate velocity tracking and therefore predictions about what can be done.
Having been in a project where this was done (we had to account for time down to the nearest 15 minutes of each day) – this is the quickest way to lower morale and to waste time.
As a vendor, you win a project based (in part) on a quoted cost. You’ll be delivering a certain set of features for a particular cost, plus or minus a bit.
The client doesn’t care how hard it is, and the time investment taken to track the velocity is significant – it’s time that the developers could use to finish features.
Developers definitely don’t want to fill out reports on precisely how much time things took them – they just want to build things.
Given that you’re probably working within a fixed cost (unless you’re on a pure time and materials project), then I would expect that your developers could give estimates for each feature, and you could work on an ‘overs and unders’ approach – it should average out to be about right. This of course relies on you having a good team of competent developers (ie, good people) – the lynch pin of any methodology.
My alternative to velocity and story points: talk to your team, talk to the client. Set expectations about what can be done. Don’t surprise anyone.
This has actually worked, and doesn’t involve any new concepts or terminology.