Skip to main content

How do we get better at estimating?

Last post 06:34 pm March 2, 2020 by Suz Maria
7 replies
08:06 pm February 24, 2020

Our team wants to get better at estimating, and we thought to measure how long our stories are taking compared to our original estimates. However, all of the research I have done says that is the wrong approach because it drives bad behaviors. Many people then point to the burn down chart as the solution. I am not sure why.

The bottom line of what I am asking is how do we get better at estimating?  


10:26 pm February 24, 2020

we thought to measure how long our stories are taking compared to our original estimates. However, all of the research I have done says that is the wrong approach because it drives bad behaviors. 

Suz, unsure what bad behaviors you are referring to.

In my experience, the main way to get better at estimation is to review past estimation accuracy, and adjust estimation practices as needed.


11:03 pm February 24, 2020

What research and bad behaviors are you referring to? I'm not aware of any way to get better at estimating than to compare your actuals to your estimates. I would say that there are a few things to be aware of, though, such as how much time you spend capturing actuals and identifying reasons for differences.

Alternatively, questions like these are when I like to bring up the idea of "no estimates". If you're working on the most valuable work next, why even bother spending time to estimate it? Slice it into valuable pieces that feel right for a Sprint and focus on delivery. Don't worry about estimating or capturing actuals or comparing actuals to estimate and invest that time in refinement and delivery.


01:39 pm February 25, 2020

It will take time, at least 3 Sprints.

As a team look at the estimates that we accurate and those that we not, identify what happened, this should be done during the Sprint Retro or Review.

Look for commonality between the upcoming work and the past and estimate accordingly.  Look for complexity and possibilities where the story may run into trouble, Spike this part where possible.

Aim your targets for your next Sprint low e.g. 50% of points you gave in the previous Sprint. Start from there, if you have time before end of Sprint then pull in another item.


01:51 pm February 25, 2020

The bottom line of what I am asking is how do we get better at estimating? 

From empiricism ,by delivering the releasable increment each sprint. If you not able to deliver or deliver much more than planned then this gives opportunity to inspect & adapt your workflow which includes estimations. 


03:40 pm February 25, 2020

Estimating goes hand in hand with the flow of work through the team.  So it's useful to capture your cycle time as a metric (days between starting and finishing).  This should give you an insight into how often you complete work.  If you're struggling with estimating i imagine this is going to be quite high (i.e. above 1-2 days).

Then, I would suggest to break your stories into smaller ones before starting - it's easier to estimate the work that can be completed in a day or less and gets the team a morale boost as more items move into the 'done' column on your scrum board.  It also builds confidence in your ability to estimate at a low level.

A good technique on a physical board is to flag story health using colours for how long something has been in progress

  • 1-2 days - Green
  • 3-6 days - Amber
  • 7-10 days - Red
  • 10+ - Black

This will give your team a daily reminder of getting things finished and they should be identifying actions to take to clear long-lived stories (swarm to complete, break down into smaller tasks).

There are some good advanced forecasting tools (e.g. monte carlo simulation) that can be used based on your teams historic throughput to give you a better understanding of how confident you are in delivering in a timeframe.

 


10:40 pm February 25, 2020

The bottom line of what I am asking is how do we get better at estimating?  

Practice.  Lots of practice.  I know it sounds cliche but it is true.  You can only get better by doing it. But just as you do when you practice a musical instrument, you identify areas where you struggle and then focus on those to improve.  If you don't look back at how your estimates compared the what actually happened you have no way of improving. BUT AND I CAN NOT EMPHASIZE THIS ENOUGH, you do not compare your estimates to the actual time it took you to do the work. You analyze your estimates and then identify what you discovered while doing the work to understand what was missing when you made the estimate.  This will help you learn what kind of information to seek before estimating in the future.  Estimates improve based upon your understanding of the problem.  They do not improve based on the time it actually took you to do the work.  

You get better at estimating by analyzing what information you uncovered after the estimate that would have changed your original estimate.  Don't fall into the trap of equating an estimate to the hours it took.  


06:34 pm March 2, 2020

Thank you guys so much for all of your input! This was very helpful & I now have a lot to move forward with!


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.