Getting better at estimation work as a programmer is a a skill that most seem to seek out. There are some great tips on how to get more accurate estimates, none more so than here:
But how much time must we spend estimating tasks? We can all sit researching the code base, assessing the backlog items until we’re blue in the face but ultimately, you will never know how long it will take until its done. Spending a large amount of your time preparing to give an estimation seems a lot like waste, to me.
So why do we get hung up on it? A lot of us run a SCRUM process and at the end of our sprints we’re either all very happy, or very depressed. Our mood is dependant on whether we finished the work that we, ourselves, estimated we could do before we started the sprint. If we do everything on time – we estimated well. If we have stuff left to do – we estimated badly. So why would we want to feel depressed after a two week slog of producing (I hope) great work because of a speculative call I made at the beginning of this process? I think it is a much better thing to judge our work based on how good our work is – simple. But to do this we need to stop ourselves putting so much importance on our estimations – or at the very least prevent them from becoming a binding contract between ourselves and the business. After all, a certain agile principle does state:
“Working software is the primary measure of progress.”
I’ve been reading a fair bit recently on the idea of NoEstimates, which I believe can be attributed to Neil Killick. Read:
or check out #NoEstimates for a whole lot of discussion on this.
I tend to hear a lot that estimations are required otherwise we will not know we can deliver on time. This is fair, some people have clients and customers to keep happy. However, I have previously worked in a team that do not estimate their work, we ran a Cranked (www.crankedalliance.org) process. In this process, we did not fix the time of our iterations but the scope of them. By doing this, we can achieve some forecasting of work, without once having to guess how long a piece of work will take. All we did was take the range of time of our iterations (removing outliers) and multiplied by the number of work items a feature would require. Simple.
For example, say we needed to implement a login feature. This feature would require creating the back-end code, some form of UI and we need to make sure we restrict access to the application for non-logged-in users. That’s three pieces of work to me. The team’s average iterations take 2-3 days. So that equates to 6 to 9 days (3*[2 to 3 days]). Okay, its a simple example but the idea works. You keep you work items small and focussed and you ultimately don’t have waste any time estimating any more.
The beauty of removing this concern away from us programmers and techy folk is that we can just concentrate on making the product beautiful without spending our time or our emotional well-being on the concern of sticking to our estimations.
And this is just one thing you can do to help remove the waste in estimating – there is a whole bunch of material out there 🙂
Let’s start making the quality of our code and the quality of the products we create our primary concern, not our estimations!!