Do not spend time estimating by points, build history from short iteration, categorise development victories simply and use them for metrics.

gistfile1.txt

* Do not assign points ahead of time.

* Run weekly interations.

* In retro, gather all of the completed tickets:

(1) Assign a weight to them - Trivial, Medium, Significant.
(2) Record which dev completed them, any other visibility metric required, etc..
(3) Write a journal entry that indicates a velocity based on a number Trivials|Mediums|Significants.

This differs from pointing up front in a number of ways.

It lets you assign weight to bugs, tasks, etc. that aren't usually pointed.
It doesn't mean lengthy estimation meetings.
It doesn't try to get estimation right, before the task begins.

I used to do something similar to that in the early days at envato.

We used http://www.mountaingoatsoftware.com/blog/estimating-with-tee-shirt-sizes for the weighting. We still estimated the tshirt size, but then also tracked the actual tshirt size (ie was this task done in hours, days, weeks)

Interesting.

Yeh, we recently had to do some sort of up front estimation just to tell the business how long a new project might take, so that approach would work then.