velocity

Day 8 of 30. So far, I'm successfully producing one blog post per day, often 500-1000 words of hopefully coherent text, mostly themed around a mix of tech and work culture and leadership and learning.

Where is it going? What direction is this headed in? I've decided, in true NaNoWriMo spirit, to not bother answering those questions just yet. In the early stages of a project or learning journey, quantity can have a quality all its own - you just have to put in the work to try things out, to make mistakes, to build one to throw away.

But if there is a direction: I enjoy writing as a form of thinking in the open. I've practiced it elsewhere in the past, and something about the chaos and stress of the pandemic years tore that habit into tiny little shreds. Now that life feels a bit more settled, with the benefit of time and distance, I'd love to reintroduce that habit into my life. Definitely not every day - I can't sustain that long-term - but maybe whenever I have something worth the effort to share.

And the threshold for "worth the effort" is, in my experience, a lot lower than most people think (or fear) it is. I hope this month's experiment helps me find that threshold, and that it gets me back to writing as a semi-regular part of my life.

In Modern Agile Organisations, product teams worry a lot about velocity. How fast is the team working? How much are they getting done per unit time? Often there's an attempt to quantify this velocity in burndown charts and story points and other such metrics. Some teams even get into frameworks like 3-point estimation. There are fibonacci and squares and other scales for estimating task size. The renowned Joel Spolsky at one point suggested building estimation models for each person on your team.

If you talk to a physicist, they'll let you know a secret about velocity: it has both a magnitude and a direction.

If you're completing 5 zillion story points per increment, and no users are around to hear it, does it matter?

If your burndown chart looks like you'll make release, but you have no idea how to measure if that release is successful, does the magnitude of your velocity matter? Are you pointing that magnitude in the right direction? How will you know?

If your team is at 100% capacity, maximum magnitude, but you notice the direction is off - even a bit - how will you make time to adjust?

Don't get me wrong. It is important to estimate your time, or at least try. People will ask you for estimates, so that they can plan with (or around) you, so that they can communicate to stakeholders and users, so that they can meet contractual deadlines. Time estimates are part of how you avoid pushing your team at 110% capacity.

But they can also measure the wrong thing. What if, instead of story points per sprint, we measured movement on key metrics per hours worked? Or response time to unexpected incidents? (Hello, DORA.) Or sustainability of your workflow: how happy and engaged is your team? How much do they believe their work is making a difference? Or user satisfaction?

And what if you're early on in product development, and many of your tasks are still exploratory, and you haven't yet landed on your key metrics? It's easy to gain the illusion of control with estimates: you have a number! But maybe you have no reason to believe that number. Why did you spend time coming up with it?

If you start measuring velocity, and you forget about the direction component, what you'll probably get is more magnitude. You get what you measure, especially if you tie it to incentives. Just make sure you're not cycling off the road really, really fast.