STORY POINTS ARE not EQUAL TO ESTIMATED TIME!

This is probably one of the harder concepts to grasp in Scrum. We keep repeating that story points is the size of the story, not the time it takes to develop it. And yet, this question is often asked:
“But I am much slower, so how can I set the same point as you?”

Stop it! You are still thinking of time!

Look, if you are building a Lego model, and it contains 20 pieces, no matter how fast or slow you are, it is still 20 pieces. The size of the model doesn’t change. Now move this thinking over to a user story. They all have a finite number of things that has to be done to finish it.

Example time. First, we have to add a page for the user to enter the address, and of course add some validation to the input. Then we have to store it in the database. Double check if it already exist, and of course we have to handle if that situation occurs. And so on.

Now, does this change if you are a junior or a senior developer? Does it magically appear extra stuff to do if you are slower? Right! It doesn’t. It is the exact same work you have to do to complete the story.

This is what you are estimating.

Now, this forces us to understand the story on a technical level. We just can’t look at it and throw out a number that feels right. Well, if you are seasoned developer that has done this a thousand times before, you just know. But honestly, how many of us are at that level?

We have to look at the story and find the functionality we have to add. We have to understand what is expected of us. And if we don’t do that, we have to find out. And that means looking at how the system is implemented today. No, we’re not talking about the code, we only want to know that we have to get data from the database, not how the data is fetched. But we have to know that there is a database and that it stores the data we need. We need to find the building blocks for the story.

Or put in another way, we construct the architecture.

This has a number of advantages.

It forces everybody to learn the system on a higher level.
How is the data stored?
What layers are in the system that we have to address?
What does the error handling look like?
We hammer out the architecture before we start coding. It is hard to think of architecture and code details at the same time. Well, maybe not for you, but think of your colleagues that aren’t coding super heroes yet. We’re breaking up the work in two separate steps so we can focus fully on each.
When we get to writing the tasks, we actually have something to break down. I mean, how many times have you seen a story with the following tasks: analysis, development, unit tests? That’s not tasks! It is just a general description of the development process.
And when you actually have tasks that says something of what you are going to do, then you can give them a proper estimate too. I mean, how can you estimate the time for “development” if you don’t know what you are going to do? Well, you can’t!

I think that the major issue of this approach is that many think it wastes time. We’d rather sit at our keyboard coding, not spend times in meetings. This way does take more time than just guessing, and it does make you do intellectual work.

Scrum is a way to stop doing unstructured ad hoc development. But we have to start doing things differently and not just continue as we used to before and only say that we do scrum because we have a daily standup. This is one way of adding structure to the development process. And it goes hand in hand with the rest of the process. For instance the gradual discovery of details along the way from one liner stories to finished product. Read about it here in my previous blog post “Different Stages of Scrum“

Cheers!!

Like it? Share it!