You Should Stop Using Velocity

Ever since Agile was introduced as a way of thinking, many new terms, methods, and metrics have entered the industry. Most of them vanished before anyone even noticed them, but a few are here to stay. Unfortunately, some of those evergreen metrics and methods don’t bring anything to the table. One of them is velocity. Let me tell you why.

Let’s start at the very beginning. Velocity is a metric primarily for planning and estimating how much work a team can handle in future sprints. Velocity is usually expressed in story points, a made-up unit of measure. Velocity usually comes with a burndown chart, which is a visual representation of the work remaining over time.

There are several problems with using story points from both an Agile and Product Management perspective. I could talk for hours about the heritage of these problems. In short, I attribute this to deeply rooted Waterfall and process mindsets.

Problem 1: No One Understands What You’re Talking About

As IT people, especially in a Scrum and SAFe environment, we like to use our own terms constantly. This makes perfect sense when talking to peers who speak the same language and learned the same things during the same courses.

But we often tend to forget that the rest of the business doesn’t speak our language. Velocity and Burndown Charts are not things you’d find when you scroll through annual reports, but financial metrics and commonly used KPIs are. So, if you want to work with the business side of your organization, the least thing you should do is use other metric systems that they do not understand and can’t translate to their own.

Problem 2: It Doesn’t Tell You Anything

Velocity and Burndown Charts are terrible methods because they offer no predictive power, do not provide insights on why things go wrong, do not help you make decisions, and don’t tell you how to fix the process.

Problem 3: You Get What You Measure

I’ve seen this one so many times over the last couple of years. Velocity and burndown charts are introduced by a Scrum Master or an Agile Coach. And over time, you do see teams slow down. Why? Because if reliability is your core KPI, the easiest way to get there is by not promising anything, so that’s exactly what developers tend to do over time.

But let me remind you, your team is not there to be reliable or efficient. The sole reason why the team still exists is to maximize value. Which usually comes with a messy process and a team that is a pain in the ass to manage.

Don’t get me wrong. If you, along the way, find a way to both deliver great outcomes continuously and become efficient, then that’s good for you. Congratulations. But velocity, efficiency, and process should never become “the thing” in your organization.

No Velocity. Now What?

I’m a big fan of 37signals . I like most of the products they’ve developed including Hey and most recently the (re-)introduction of Campfire. Basecamp does not use Scrum, SAFe, or Kanban to develop products. They do have a rather unusual approach when it comes to software development called Shape Up.

Shape Up comes with a completely different type of estimation called an appetite. From my experience, appetites are a better way to keep the focus on the outcomes and impact within a certain period of time (like a cycle or a sprint). To start, you explicitly define how much of your time and resources a subject deserves. In other words: It starts with a number, and ends with design. Which forces you to think things through from a business case point of view before you start: “Is this a problem worth solving?”

It’s better to start from every perspective. You’re forced to look at a problem from a business point of view, and are therefore consequently forced to keep speaking the language of a business. Which means everyone knows what you’re talking about throughout an organization.

Next week's newsletter is, on many requests, fully dedicated to Shape Up. So stay tuned for more about appetites and the way of working that comes with it. Don’t want to wait another week? You can read the Shape Up book via the link below.

Shape Up Book: https://basecamp.com/shapeup