

Ask HN: How to get better at task estimation and discipline? - Fr0styMatt

I&#x27;m currently taking stock of my own weaknesses as a developer and one of the areas I&#x27;ve constantly had trouble with (that I think has hurt me professionally) is in estimating how long it will take me to complete a task.<p>I&#x27;ve never quite been sure how to overcome this and would love to hear from some developers on how they&#x27;ve tackled this problem in themselves and from managers on what you really expect from your devs in this area.<p>I know this is a multi-faceted issue; for me personally I think there&#x27;s a few things at play:<p>- I can be easily distracted, which I tend not to account for in my estimates (which assume that fascinating time-holes like HN and Stack Overflow don&#x27;t exist!).  I know I need to work on this.<p>- When I think about it, despite being a dev for many years now, I don&#x27;t really have a trove of historical data to evaluate my own performance against.<p>- I still have this mental roadblock that estimating often just feels like &#x27;guessing&#x27; and I&#x27;m just really uncomfortable doing it.  It feels more like trying to set myself a deadline and then compress the work into it, rather than actually determining how long the work will take.<p>- I feel pressured to give best-case estimates, especially when we&#x27;re doing them in a Scrum where more senior devs disagree.<p>I really want to be a developer that can be trusted and relied upon and I think that my under-estimating is one thing that hurts me with regards to this.<p>So, fellow HN&#x27;ers, how have you tackled this?
======
edoceo
+1 to smaller tasks. You gotta break it down.

I've also stopped estimating. When the tasks are kinda vague and open the
estimates are just wrong.

I've been trying to follow patterns in the Toyota Production System and those
from Personal Kanban (books). If I do happen to estimate (oh, that's like 2
days) its less of a deal, I'm just blocked till done.

Try to keep the team either full (3wip) with 1 blocker. That's what a moving
pipe looks like to me.

------
UK-AL
In scrum you are traditionally not meant to give time based estimates(it
doesn't work). You use story points. Humans are bad at time estimates,
everyone is.

Using story points, you measure how complex a story is, rather than time. A
small spelling change, vs massive re-architecture. You do things in general
abstract terms, rather than hard deadline, where you get fired if you don't
meet it.

A added advantage of story points is that is abstract, it doesn't care if you
6 hours out. So you don't feel pressured to lower it.

You then look at previous sprints and see how many large/small tasks you can
complete in a sprint.

A lot companies try to use time estimates to increase productivity, and get
developers commit to releasing by a certain date. It doesn't work, it leads to
rushed buggy code.

Its sounds like company is one that doesn't really understand agile/scrum, and
is trying to use estimates as a whip to get you to work faster.

Companies need to stop using time estimates as a whip, and focus more on
methods that are actually generally accurate, and provide useful information
for planning.

~~~
Fr0styMatt
We'd tend to do that for stories, yes; take an overall story and assign it a
number of story points. We'd then try and make time estimates for each of the
story's subtasks, which is where I would have trouble. Time was a bit like a
currency - "We have X number of hours available in this sprint, the sprint is
big enough when we've 'spent' all those hours on estimates".

My experience actually matches what you're saying, in that there was always
much better discussion around the number of story points and I never felt like
my story point estimates were guesses. If there were any disagreements over
story points, we'd at least be able to discuss it concretely ("here's why I
think this task is more complex / more simple").

For what it's worth, before I was gone our process was moving more towards a
velocity focus, where story points were getting more importance than time
estimates. Generally Scrum was a new thing for our company and our group was
one of the first to use it; I don't think they were using estimates as a whip,
at least not intending to. However the business still needed/wanted concrete
dates that the group had to commit to.

~~~
UK-AL
At our company, story point method is very accurate, so most of the tasks are
completed at the end of sprint except maybe 1 or 2 at the end(out of 30) which
normally caused by something outside of our control.

At previous companies I used time based 'guess' methods, which were all over
the place most of the time. I don't think i've ever been at a company that
could actually get it right.

Honestly this way of estimating really suits my team. I don't want go back to
a company that picks time based estimates out of thin air then expects you to
meet them. I was really bad at that, but so is everyone else.

We don't expect to developers to have committed to complete stories mid-sprint
or anything. But we have generally come to expect all items to be completed at
the end of sprint, simply because our capacity planning is very good at the
moment. Everyones happy with estimates at the moment. We do slight adjustments
based on previous velocities. When we don't complete stories at the end of the
sprint, we change the capacity for next sprint rather than blame developers.

It's a lot more collaborative, rather than a hostile blame game.

------
osivertsson
Split work into small enough tasks that they are all max 1 day if at all
possible, meaning that everybody on the team knows what should be done and can
just "go-go-go". Much easier to estimate.

Always remind yourself and your team about any work ouside the core
functionality being implemented. Database migrations, deployment costs,
documentation needs, unit- and functional tests (both updates and new),
technical debt that needs to be fixed now, and if there are other risks like
hitting resource limits or missing performance targets.

Keep track of actual outcome vs estimate. What was the main reason it took
longer? Best done if working close to co-workers on tasks, making progress or
lack of it associated with the team and not individuals, where it could easily
become a blame game.

Be aware of how much distractions you have from doing actual development.
Meetings, urgent bug fixes or help with other problems in production, customer
contact, supporting sales, etc.

------
rachelandrew
I wrote up last month how I became good at estimating time.

[http://rachelandrew.co.uk/archives/2014/06/20/how-to-
become-...](http://rachelandrew.co.uk/archives/2014/06/20/how-to-become-good-
at-estimating-time/)

TL:DR you need to start tracking your time and noting when your estimates were
incorrect. Fairly quickly you get to a point where you can see the places you
tend to make a poor estimate and adjust them.

------
vellum
[http://www.joelonsoftware.com/items/2007/10/26.html](http://www.joelonsoftware.com/items/2007/10/26.html)

