— April 19, 2011 —
By Tobin Harris
Engine Room Apps is a service company that creates mobile solutions for it’s lovely clients. We have 10-20 projects at any time, and like to measure how fast we’re getting through them; how fast we’re delivering useful stuff to our clients.
We call this measurement our velocity.
Here’s our velocity over the last 3.5 months (we’re 19 days into April)
The velocity indicates how much stuff we’re delivering to our clients. In ERA, “stuff” usually means “features for smartphone apps”. We also track internal projects as part of our velocity too.
Why measure velocity?
Measuring velocity brings many benefits:
Reflection: We know when we get faster or slower, so we can ask the more important question of why? This allows us to reflect and improve.
Targets: We can set ourselves some targets and measure ourselves against them.
Not About Finances: Financial targets are great, but our productivity is not always aligned to our financial success. For example, when we invest in projects, we don’t necessarily make money from them straight away, so we still want to know if we’re being productive outside of our bottom line.
Change Indicators: When the environment changes, we can see if it allows us to get through more or less work. Team growth, training, time of year, holidays and type of projects undertaken can all trigger changes in velocity.
There are more important things than velocity
Despite the fact we measure our velocity, it’s not our key driver. Above all, we want to kick out quality work. Measuring speed is a useful thing, but it’s also dangerous to give it too much importance.
Measuring quality is a separate blog post I think :)
Constant visibility
Our velocity is no secret. We’re currently making this information constantly visible to the team via the information radiator, along with our company-wide work queue.
Everyone is encouraged to chip-in on the current state of projects, so that we can self-correct (this idea is based on the lean term: Kaizen culture)
How To Calculate Your Speed
The principle in calculating velocity is pretty simple. When we sell a project, we do so by giving it a cost in points. These points represent how much work the project needs us to deliver.
Some rough examples:
- A small-ish app like iSight Test might be 10-20 points in size.
- A big app like ASDA Price Guarantee might be 40-50 points in size.
- A full solution like the AllBabble social network might be 100+ points in size (for both the app and related back-end stuff).
So, as we progress through the project, we deliver working features to our clients. Just like a project has a value in points, so do the features. As clients accept those features as being complete, we know we’ve delivered X points in Y months. This lets us calculate how much stuff we’re doing over time.
