Sam Gimbel

Tech, Beer, and Strange Thoughts.

Measuring Personal Velocity

Every team has a different way for measuring the speed at which code is shipped. Some do so according to strict agile scrum principles, some create their own processes, but the focus is clear: teams should know their velocity. It's a prerequisite for shipping frequently and effectively.

The Problem

Oddly enough, most people don't measure their own personal velocity, which leads to an important question: how can we be sure of our personal contribution to our team? It makes it difficult to determine how we work best when we're not exactly sure how we work in the first place.

Naturally I decided to run an experiment on myself to see how this would work.

The Experiment

I started a new job at DigitalOcean in August, which comes with a new set of routines and lots of new stuff to learn, making this endeavor especially timely. At DO we use Trello to organize ourselves at a team level, so I decided to use it as my personal velocity measurement tool as well.

I built two boards for this purpose:

  1. Sam's To-Dos - where all my current tasks are listed.
  2. Sam's Archived To-Dos - a board I use for analyzing the task load of previous time periods.

My To-Dos board is set up to collect tasks from a task backlog using list headers like these:
Trello Board Headers

As tasks come in, I put them either in Do Soon or Do Later. That's the only triage I can handle at this point.

The Cadence

Every velocity measurement needs a cadence that defines the period over which work is done. For me, this is a single day. Ideally, individual velocity gets measured within the team cadence so each teammate has a chance to adjust their velocity without throwing off the whole iteration.

My cadence proceeds as follows:

  1. End of Day - Reorganize "Do Later" and "Do Soon." Then pull tasks into the next day's list.
  2. Beginning of Next Day - Add or remove tasks from today's list based on overnight changes. Archive yesterday's list.

Rinse, repeat.

The Analysis

My goal through all of this is to collect data to support a better understanding of the work I do on a daily basis. By diving into the archived task list I'm able to glean the following:

  1. I perform more total tasks mid-week.
  2. The tasks I perform at the end of the week take significantly more time (spec writing, data analysis, feature research) than those I perform on Mondays.

This is interesting. But what would be more interesting is being able to see at a glance what types of tasks I complete, how long they take, and how I contribute to the broader team velocity. I hope to have solved all those problems next week.