Measuring and Estimating Personal Velocity

Name: Measuring and Estimating Personal Velocity
Type: Process
Status: final
Version: 2008-03-28

Gist: to improve on estimating how long a given task will take. To give a well grounded answer to the question: "When will this be finished?"
Note: although this process aims at personal velocity, it can be adapted towards team velocity. But mind entry condition E1, every team member will have to fulfill it.

velocity DEFINED AS the number of task-points done per day.

Entry Conditions:
E1: You must be willing to take notes of all your tasks and review them regularily, i. e. once a week.

Process:
S1: for every task you get or generate for yourself, do a rough estimate on its complexity. Simply give points ('gummi bears'), use Fibonacci's numbers for that, i. e. 1, 2, 3, 5, 8, 13, 21, 34, ... (each number is the sum of the two preceeding ones). "If task A was worth 5 points, Task B is a bit more complex, so I will give an 8."
Note: It is not important to estimate for example the hours you'll probably need. A relative meter is sufficient.
Note: For me, this takes 5 seconds longer than just jotting down a task. With about 30 tasks/week this adds up to whopping 2,5 minutes this substracts from my weekly work time.

S2: whenever you finish the task, just mark it 'done'. No need to recalculate your original estimate.
Note: This works because of a levelling effect over time and the number of tasks. See Notes below.

S3: Regularily (I go for once a week), sum the points of all tasks you finished since last time (e. g. the past 7 days). Do it at least a couple of weeks to get credible results.
Note: I do it all the time because I found that my velocity changes with the projects I work on. It takes 3 minutes per week.

S4: Divide the sum by the number of days you actually worked on tasks, so that holidays, etc. are not factored in. The result is your velocity, Gummi Bears Done per Day.
Note: you can decide to factor in holidays and the like, but then you will need a much more data in order to come up with useful answers.

S5: Whenever you are asked the magic question "When will this be finished?", do the rough estimate of S1 on 'this'. Divide it by your velocity. The result is the time you will need, in days. Don't forget to think about when you will start to do the task before answering...
Note: I use the average velocity of the last 5 weeks, to take changing velocities into account. Maybe after a year I find that it is good enough to use the year's average velocity.

Notes:
The steady estimation process S1 will level out a couple of unwanted effects:
- you will have good days and bad days
- you will have to estimate rather small AND rather large tasks
- one day, you will finish that monster task you estimated with 55 gummi bears, and this will boost this weeks sum.
- your always optimistic (or pessimistic) with your estimates
- tasks sometimes will have subtasks, that both appear in your task list side-by-side. 'this is not a problem unless you do a complete work breakdown

To give you a hint, tasks in my list range from 'Call Andy' to 'Write a new requirements management plan for Project A'.

I misuse MS Outlook's® Task-Details for keep track of the estimates. I don't care if the field says ' x hours', for me it's just 'x'