why is velocity so complicated?


Have you ever used velocity, Reader, and was it worth it?

This past week I did a live stream (if you missed it, it's now available on my YouTube channel). And I got some great questions, as always.

But one question that keeps coming back pretty much every time was around velocity.

I feel that I talked about this topic so much, but it is still unclear to many.

And, honestly, I don't know why.

It's like our rational thinking just rejects the idea or something.

Like if you saw a ghost, you most likely would try to find a logical explanation, before you would ever believe that ghosts exist.

A so it's the same with velocity.

The whole idea of velocity is NOT to equate it to time, like hours or days.

But over and over again, I see people saying "1 story point is about 1 day's worth of work".

So if in the end, you equate story points to hours, just estimate in hours! Why do you need story points at all? To make it sound "agile"?

1 story point is 1 story point, nothing else.

What would be the best way to explain story points so that we never can equate them to time?

And so I started thinking of metaphors and ideas...

One idea that came to mind was about reading books.

Say, you went to the store to browse some books. And maybe you're looking for something to take with you on your two week vacation by the beach.

You have three options in front of you that cover the same topic that you're interested in:

(I put the marker there for size comparison).

You only want to take a book that you'll be able to finish reading in 2 weeks, but also a book that's not too short either that you'd complete too early before the end of your vacation.

Which one do you pick?

Well, the answer is - it depends on your individual... velocity :)

So I'm looking at these books and evaluating how quickly I read overall. Then, I need to open up the books to see how small the font is and whether it has lots of images - that will impact the complexity.

I can confidently say, that the book on the left is short enough and I definitely can complete it within 2 weeks.

The middle book seems reasonable, but I'm not sure. It's about 1,5 or twice the size of the book on the left.

The book on the right is a definite No for me. It's at least 4 times bigger than the one on the left. And when I looked inside I could see that the font is pretty dense.

Since all the books are on the same topic, they would be interesting in the same way, so I don't need to account for the fact that it'll take me longer to read a boring book.

The last point that will help me make the decision is my capacity.

The time I need to complete each book doesn't change based on my capacity - the book-length and complexity is not impacted by that.

But how much I can read is impacted.

Say, I know that I will have a packed schedule of tourist visits during the day and will only have evenings to read.

So the book on the left it is then!

But let's imagine I have absolutely nothing to do except lie on the beach. Then I'll take the middle book.

I'd still not take the one of the right, though. I just know it's too big.

Now, you may be thinking about similar things when making a decision about which book to take.

A couple of questions for you:

  • Do you need to know EXACTLY how many pages each book has?
  • Do you need to measure the exact size of the font in each book to make the decision?
  • Do you need to calculate exactly how many hours you need to finish reading each book?
  • Do you need to know exactly how many hours you have during your vacation for reading?

I would assume - not really. And more importantly, you can't really be sure anyway.

Even the number of pages is not a very accurate metric here!

Sure, you can look at the end to see how many pages there are. But wouldn't you also need to look inside to check if all pages have text and how much text?

That would take ages to do...

And it may still not guarantee exactly how many hours it'll take you to read each book.

This is EXACTLY what we are trying to accomplish when using velocity in story points.

Think of story points as the size and complexity of reading the book.

You are not trying to evaluate how many hours it would take you to complete it, just evaluating each book in comparison to each other.

Then you think about your past experience reading books and how much you can usually get through in what period of time, to have a general idea of the estimation for each book.

Not in hours, because it's not like you'll be sitting in front of the book the whole time without eating, sleeping, or going to the bathroom.

Nonetheless, you're able to make a decision.

So for our example, I can say that the book on the left is a 1 point book, the book in the middle is 2 points, and the one on the right is a 5.

And the thing is, that books that may seem like completely different sizes, equal their estimates due to other factors.

For example, for me these two books are the same size:

Am I crazy? The book on the right is clearly at least 3 or 4 times bigger!

Well, it's actually full of images - there's not much to read.

So my estimation of the book will automatically go down.

What do you think of this metaphor?

When you think about story points, think about this book evaluation example.

Story points help us estimate items in relation to each other.

It saves us a lot of time because we don't need to calculate the absolute values (like number of pages, or hours).

We can use our past performance to make quick decisions.

If you want a bit more help around the concepts of velocity, check out my video on this topic called "Velocity is a made-up number".

Since it's relevant to the topic, I also wanted to address a comment I received on one of my videos.

(I may still make a video about it)

@mukohlovet5095 asks how to help a team meet up their Release Planning Schedule, especially for a team struggling with their velocity?

If we go back to what we discussed in this email, I'm not sure I know what "struggling with velocity" even means.

Velocity is just how much work a team can complete within a certain period of time based on the data collected previously.

Anyway, that's what I wanted to cover in this quick email.

Stay tuned for the new video coming out this week (hopefully, it may take a few extra days).

And also the Product Owner Guide is going to be fully launched shortly with some extra downloadables and Miro templates. I'll be running a time-limited promotion, so don't miss out on that one.

Daria Bagina

I help professionals and organizations build awesome teams with the help of Agile and Scrum practices. I provide highly actionable tools and systems that bring you results. Professional Scrum Trainer | Experienced Agile Coach

Read more from Daria Bagina

12-12-2024 Hey Reader, I've got a new video for you. Yes, I sent you an email last week about this topic already since I posted it in a blog post. BUT... I updated the text and included so much more information in it to give you even more actionable steps to take to improve your meetings. And I also have filmed a video for you 🎥. Writing an attendee story One of the things that I added a ton about is the attendee story, or really, how to write a better more useless agenda for your meetings. I...

12-12-2024 Hey Reader, "The are too many meetings is Scrum". Or so many people say. But in reality, whether you use Scrum or not, you probably have too many meetings. There are a few things that you can implement to immediately free up your calendar and focus on what's really important. To help you with that, I wrote up a blog post. In summary, I bring you 5 rules to follow to avoid useless meetings: A meeting can only happen if it has a clear purpose. No preparation means no meeting. The...

12-12-2024 Hey Reader, Today I wanted to talk to you about a topic that has been on my radar for the last several months. And the more I look into it, the more I want to discuss it. Luckily, I got a chance to deep-dive into this topic with Mark Metze during the recording of a podcast episode for Agile Within. The topic is "how much technical knowledge do you need to be a successful Scrum Master (or Agile Leader in general)". I'm sharing a part of that podcast with my answers to Mark's...