Most common mistakes in scrum ceremonies 2/7: estimating stories

Written by , in category Agile & Scrum

1 April 2013

effort vs accuracy

Spending too much effort in estimating stories

People have the tendency to spend too much effort on estimating the incoming work. Having some basics skills available, like high/low showdown, deal and slide and planning poker will help the team to make well educated estimates they feel comfortable with. These techniques are also designed to maximize the return on investment of your time when it comes to accuracy of the estimates. All the time spent on estimating work is time you can’t really produce value for your stakeholders, so it is important to keep that effort /accuracy balance right.

Letting one person do the estimates

Since estimating work is keeping us from doing real valuable work, let’s dedicate one person to do all estimates. Sounds like a good way to cut costs, right? It is also a sure way to estimation and motivation hell! Not only will this cause your estimates to be less accurate, because of the simple fact that this one person is not going to do all of this work by himself, no matter how well you know your team, as studies have proven over and over, it is next to impossible to estimate work that someone else will be doing. Next to this simple fact, you also have the reality of not getting a real commitment from your team again. If the event arises that the sprint goal will not be met because of underestimation, team members will be quick to point a finger at the person who did the estimation, stating that it wasn’t their estimate to begin with. So instead of spending thousands of euros on bogus team building events to boost morale and motivation, give the entire team the chance to estimate the work they will have to do as a team.

Trying to estimate using time

Look, let’s face the fact that we as humans are extremely bad at predicting the future. And daily life is becoming so crowded and rushed that it’s hard for us to stay focused. If you would look at what you plan to do during the day and how much of your working day you actually get to spend on the things you planned, what would be the ratio for you? Think about it, I can wait for a couple of seconds. Alright if you are close to 100%, you are either lying to yourself or you are a personal time management guru. Most people end up spending around 30%-60% of their time working on actual “planned work”. And this ratio can drastically change from day to day. Think about the situation at home when you planned a lot of things after work and 1 of your kids gets ill. I can assure you that this causes a lot of unplanned work to arise.

So instead of trying to keep all these interruptions in mind when estimating, use relative estimating and story points which will help you to decouple the effort it takes to finish a piece of work from the time it will take to actually finish that piece of work. Let’s look back at the example of the sick kid. Let’s say that you planned on doing the dishes and that you let it pile up a bit. So relative to taking out the trash, doing to the dishes would be 8 household points for instance. If your kids are fine and are playing by themselves doing the dishes might take you half an hour to finish.

When trying to do the dishes with a kid that demands your attention every 3 minutes because they don’t feel well, they need to blow their nose, they want some soup, … this will probably take you at least an hour. But the effort stays the same, it’s the same amount of work, the same complexity of work and the same uncertainty level. The only thing that changed is the time it took you to finish the task under different circumstances. Coming back to scrum, let’s calculate the time it takes to finish something based on the team’s velocity and the relative point estimate of the story. This way we are using the knowledge from the metrics we have to help us predict the future. So in a way we are using the past to predict the future. Sounds logical no?

Not using the right scale

Wether it is the Fibonacci row or something similar, the bigger the stories/epics are the higher the uncertainty and the bigger the margin of error on your estimates. This is also linked to the first pitfall described above, it is of no use to start discussing wether a story is 40 or 41 story points. We all know it’s 42 anyway 😉 Instead of relying on some magic formula, let’s use the science of statistics to our advantage and make the gaps between possible estimate values bigger the higher we go. The most commonly used sequence of values is based on the Fibonacci row: 0-1-2-3-5-8-13-20-40-100-… If you can only estimate using these values, you will certainly spend less time arguing about the estimates because this approach will help people ease their minds that it still is just an estimate. It will also incorporate the higher uncertainty of the bigger stories /epics.

Estimating each story separate

How do we measure distance right now? Depending on your country you will use different units to express the distance measured, but we will all use absolute unit right? Wrong, at some point scientist agreed to the convention that this certain unit of length would be called a meter. And from then on we measure everything relatively to that arbitrary unit of measurement. So if we don’t even measure absolutely, why should we even try to estimate absolutely? Every single project wether it’s a software project, a household project or a charity fundraiser, you will have a certain number of different work items. Use all of the items to help you improve your estimates of a single item while saving time on going through the nitty gritty details of each item. And when you finished some items, you know how it felt to work on them and to get them finished. Use this newly acquired insight to help you estimate new work.

The reCAPTCHA verification period has expired. Please reload the page.

Never miss an article again!

Relevant information about Agile and scrum by the best
Updates on our amazing public events
Max 2 times per month