The scenario is this. Your company has just started with Scrum. You are now in one of the first refinement meetings ever (some call them grooming) and you are trying to estimate the size of the user stories. You might have read my previous post about size, not time (read it here), and kind of think you understand the theory. But actually, you are probably so used to estimating time that you constantly fall back to this thinking, even if you try not to.

You are not alone. Everybody does this. It is a shift in thinking you have to go through, and you just don’t do that overnight. So here is a few things you can do to make it happen.

Understanding the story

Begin with making sure that you all know what the story is about, what you have to do to complete it.

It is not enough to have a story that says, “Add login to admin pages”. How much work is that? There’s no way you can estimate this because you just don’t know how much work there really is to complete the story.

Start with finding the building blocks. Walk through the scenario. Describe it. Because, if you can’t explain what you are going to do, you probably don’t know.

“So, I enter the password. The system writes out asterisks instead of the letters. Then it looks it up to see if it is the correct one. Now, that means we have to have them in the database. Ok, new table. And it has to be stored in a secure way. Ok, one-way encryption.

But wait. How do we get the password into the database from the beginning? Well, we have to let the user create a new profile and enter a password. Oh, and it has to be strong enough, our system should not be easy to hack.”

Now, I think you can see that this actually is a lot of things to do. And I think you also see that it actually is many stories included in one. So, by just understanding the work and finding out everything there is to do, you realise that you have to break it up into smaller stories. This is way too much to do in one step.

So now we have the following stories:

• As a user of the system I want to create a user profile with name and password so that I can prove that I am who I say that I am.
  Steps to complete the story:
  • Encrypt password, one-way algorithm
  • Create database
  • Store password in database
    
• As the system owner I want to make sure that the password is strong enough so it is hard to hack, so we can trust the security of the system.
  Steps to complete the story:
  • Display rules to user so she knows how to create a valid password
  • Validate during input, show save button only when strong enough
    
• As a user of the system I want to log in with my username and password so that I can get access to the functionality.
  Steps to complete the story:
  • Password should be obfuscated (show asterisks instead of letters)
  • Encrypt password to be able to compare with the database.
  • If passwords don’t match, show error message.
  • If password matches, open the next page.

Oh, and don’t forget to write the steps in the description of the story or you will forget. Ask me how I know…

With this level of information, you have a much greater chance of putting an accurate number on the amount of work you have to do. And you have to keep analysing until everybody has the same view of the required work.

Time to estimate

Now it’s time for planning poker. For this you need a deck of planning poker cards. You can buy them, print them yourself or use an app on your phone. Just search scrum poker.

Everybody pulls out their cards. Or phone. Each one looks at the story and tries to put a number on how big (much work) the story is. This is tricky, because there is no scale, there is no right or wrong. How big is an eight? What is a five? It is all up to you to say what you think.

Nobody shows their card until everybody is done, so you don’t skew the estimates of the others.

It will probably be a disaster the firsts time. But that’s ok. This is the first step to get a consensus of what numbers to use. It is a process of discovery. Every team has to create their own baseline.

The team then presents their chosen numbers, for instance: 5, 8, 13, 8, 8.

There is quite a big gap between 5 and 13. That tells you that you are not agreeing on either the amount of work or the size scale. So you talk about it. Did the person who said 5 forget about something? Or is the person who said 13 just feeling that this is right?

First of all, you agree that everybody has understood the story, what to do. So the person who said five actually hasn’t forgotten anything. Then you agree on the size. My guess is that everybody will lands on eight. Or maybe you think that 13 was the more appropriate size for it.

Now you have taken the first step to create the baseline for your team. Keep doing this and after a few refinements you will find that you start getting more and more in harmony.

And this is when the real benefit of estimation kicks in, because when someone chooses a different number, you know that there is more to talk about. This will probably uncover things you didn’t know about the story.

Also, when you now have a baseline for your points, you can easily see when a story is too big. You know that you can max handle a story of, say 13 or 20 points within a sprint. Everything above that is a marker that you have to break up the story.

— Cheers!