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.
Recommended by LinkedIn
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.
Data to Value 🎯 with Data Science ✨️ & Responsible AI ⚖️ specialized in AI, Generative AI and Smart Search 🔎⚡️Trainer 💡Speaker 📢 Data Scientist 🧮 Business Analyst 🎯
9moI am eager to hear more about Shape Up. Within the field of software development within AI we are already using hypothesis as a way to describe an epic from the point of what value can be added by implementing this. And now we use Scrum, story points, t-shirt sizes and velocity as base, but upon that we define added value in a metric that describes the desired and expected outcome. The motivation to start working on it. Curious to see whether shape up is similar to what we are doing right now when developing AI products. Thanks Bob Riethorst
Digital Product Management - Helping companies towards Product Excellence | From project to product mindset
9moLooking forward to the post on Shape Up. I used it at my previous company and found it very helpful to align stakeholders and using longer ‘sprint’ provides a less hurried feeling with the team which definitely has its advantages. I would suggest a nuance on point 2; I think velocity and burndown charts are great tools to support a team internally with planning, improving estimating work and breaking work to be done up in small increments that can be worked on together. It becomes tricky when these metrics are used outside of the team and used to ‘steer’ a team.